You see it all the time, a business coach who doesn’t actually know how to grow a business, a financial advisor who can’t manage their own finances, a real estate agent who never bought their own home…Well how about an app developer that has never built their own app?
Moonward has an interesting take on software development, you see we aren’t your traditional agency built on an opportunistic mindset with nothing but scale in mind. We began with our own app in a small town in New Zealand. That one app gained some traction, but it did something more important. It introduced us to a lot of businesses that wanted their own apps. We had the skills, and the market had the demand. We became the app guys. And since then we’ve been servicing businesses, start-ups and enterprises across New Zealand, Australia and the USA. Having grown from a one-man-band to now 20 in-house app design and app developers here in Brisbane, Queensland. Despite our growth, one major thing hasn’t, we fucking love making software and we love practicing what we preach.
I’ve learnt in software that the best products are the ones that scratch their own itch. A few weeks back, we decided to leverage our skills and finally solve one of my biggest bugbears in the business; systemising how we get feedback from our clients. Historically, we’ve tried to implement a magnitude of different ways feedback is received from our clients. We’ve tried spreadsheets, whatsapp groups, slack channels and a range of software tools. All of which either do half the job, create more work for our team or simply make no sense.
So what’s the solution? When it comes to providing beta feedback for Mobile Apps by far the best feedback tool is the native TestFlight feedback sharing. For those that don’t know, Testflight is an iOS product that allows us to privately release our beta versions of app to our clients without it going onto the public app store. Within the app they have a feature that enables users to share bugs, issues or changes by simply screenshotting the device, the only problem…It’s for iOS only and 90% of our clients have their products built in iOS and Android. Plus even if Android had a similar solution, we’ll have feedback going into two completely different systems, not ideal when you’re trying to make life easier for your development team. So here it is, an opportunity to scratch our own itch, make life easier for our clients and our in-house development team.
We’ll go into more depth regarding our scope in the coming weeks. I just wanted to touch a little more on the actual software development side. It’s been about 18 months since our team actively built our own internal product. And we’ve been fortunate enough to learn sooooo much about the process. Over the coming months we’re going to be building out our new software product, exactly the same as one of our clients, using the same processes, the same methodologies and the same technology. BUT we’re going to enforce a few key principles along the way to maximise our efficiency and speed to market!
The number one rule we have for this project is to avoid bloat. We’ve developed over 100 software products in the past few years, and the number one killer to all project momentum is bloat. When we build a software product we work off two key pillars to success #1 collaboration and #2 momentum. For a software product to be built efficiently and effectively, it needs to be done so with momentum. This momentum starts from ideation all the way through to design, development and deployment. Without a doubt you’re going to hit speed bumps along the way, but the quicker you’re able to navigate those speed bumps, the quicker the development team is able to make progress. Project bloat usually comes in two forms:
Scope Bloat: This is a complete killer. For some reason, people are obsessed with adding as many features as possible into their software products, but what most people fail to realise is that adding features to a software product isn’t linear. For example: if one feature is going to take our development 3 days, 2 features won’t equal 6 days. New features compound on top of each other, and the more you have the more complex everything becomes. Additional features mean additional design, additional project management, additional development, additional testing, additional CI/CD etc.
We’ll be avoiding scope bloat like the plague and we’ll do this by simply saying no to additional features (More on this soon). We’ve identified our key fundamental features for V1 and anything additional to this is added to a roadmap for future development.
Tech Bloat: Scope bloat and tech bloat usually come hand in hand. When you look at a product code base, it’s very similar to the health and wellbeing of a human body. Shit in = Shit out. As a software team we’re extremely conscious of what code we’re writing, code quality, file size, naming conventions and frameworks. Similar to how a professional athlete has immense control over their nutrition, our team of engineers have immense control over what code is written. In order for us to have longevity with our code base we must restrict ourselves to writing any bloated code (No Junk Food). Bloated code occurs when features and functions are poorly written or over engineered due to complex scope requirements. The easiest way to avoid this? Keep your project scope bloat free.
With Software as a Service (SaaS) being a hugely powerful business model these days most people suggest starting with the end in mind. By saying this people often start with financial projects, billing options, project pricing, enterprise plans etc. We’re starting with non of this…Is our plan to eventually offer this service out to the general population? Absolutely! Do we need to build an elaborate billing system when we have no product and no features? Absolutely not!
The great thing about this software product is that it’s solving our own internal problems. We’re our own client and have users ready and waiting to start using the product today. With this in mind, we’re confident that once we’ve built, tested and validated the product, the rest will fall into place. However, focussing on the commercialisation and scale of the product at this point in time would simply be a waste of our time. We’re better focussing on completing our minimalistic product design and getting the ball rolling with our feature development.
Don’t get me wrong, we absolutely love our clients. We love working with them, collaborating with them and seeing their ideas come to life. However, so far we’ve asked none of them for feature ideas, feedback or requests. Why? We don’t want to over complicate things. Based on our previous experiences we know that this product will help our internal team and clients. However, now isn’t the time to get new feature ideas, requests or feedback. That time will come but for now we need to build our V1.
The amazing thing about software development is that we can always make tweaks and changes in the future. No features are set in stone and just because we don’t need it now doesn’t mean we won’t develop it in the future. To ensure we’re focussed on developing our key features, we’re comfortable saying no to feedback and new ideas at this point in the process. We’re dedicated to building less features, less code and less bloat.
Over the coming weeks, I’ll continue to provide you with project updates so you can stay on follow us along on the journey and who knows you might be using our software product in a few months time!
Our first step is scope and design….stay tuned!
.svg)
.svg){kind=logo}
