As the CEO of a tech business I often have people come to me and say ‘I’ve got a great idea for software – can you build it?’ Whether they’re in the corporate space or aviation or entertainment, the one thing they have in common is that they usually are great ideas, with the potential to grow with massive user bases – so why don’t they always pan out? When you put a bunch of smart, entrepreneurial people in a room with software developers you’d think that a great product is bound to come out of it. But there is a distinct difference between building an app and building a sustainable software solution that can grow into a successful business venture.
We’ve seen entrepreneurs and established companies alike underestimate the complexities of application development, particularly for products aiming for large scale deployments. I’ll discuss below some of the mistakes I’ve seen in my time in the market, and put in my two cents on how to ensure not only that your application works, but also that the business around it can grow and find success.
1. Build the Application for Scale
Where entrepreneurs or companies have big dreams for their application, they need to keep a few things in mind. First, like any startup, the product itself needs to meet a certain standard – without an application that works and works well, you can’t possibly succeed. But what sometimes gets overlooked is that the application doesn’t just need to work brilliantly for the first few customers or the presentation to the CEO. It needs to work if and when you achieve growth with hundreds or even millions of users, and this is something that needs to be architected into the solution from the start. Things like scalability, security, and running costs can be improved as you grow, but the architecture of the solution needs to allow space for these and consider their impact over larger numbers. For example, a quick and cheap technical fix that works great for a small application can become hugely problematic and expensive at scale.
Now, in our office I pride myself on being the dumbest guy in the room, so I’m the last person you should be taking advice from on technical or methodology approaches. Our team has the expertise and experience to ask the right questions to challenge you as the product or business owner to plan your solution with the end result in mind. They’ve written a couple of interesting pieces related to this here. But what I would say is that as a product owner you not only have your future customers as stakeholders, but you also have prospective investors. These investors will of course want to examine the potential revenue stream, but they also don’t want to buy into a lemon that exposes them to paying for a lot of technical debt – or worse still – significant risk in areas of performance, security and privacy.
2. Build for Success, but Prepare for Failure
So the application needs to be built with success and growth in mind. But from a business perspective, it’s important to have a healthy dose of pessimism. I’ve seen many cases where the owners of the solution reach for the stars, and are always looking for the most positive outcome – 100 users in the first week, 1000 the next, and by the end of the year 100 million people on the system with $700M of revenue coming in. While they’ve got a great plan for rapid world domination, they’ve also got to understand that may not arise. It’s essential that you have a plan for how to sustain the venture financially if success doesn’t come as quickly as you thought (at the end of the day, a business has got to be able to afford to operate going forward) and it may take more than just an initial lump sum investment to grow it out to reach your goals. A good question to ask is if your business case won’t stand up at a bank, why assume it will for other investors?
Market research is also critical here – does the market really need this application? Are there existing solutions? If not, why hasn’t anyone already done this? Even large corporations we’ve worked with have occasionally failed to assess the market properly for an application, leaving them with a fantastic product that nonetheless struggles to coax users away from an incumbent solution.
I might be biased, but this is where a good technology partner is highly beneficial. An outsourced dev shop will build (what they think) you asked for – no questions asked. Using a technology partner with the right architectural and analytical expertise will feed insights into your product strategy to help prioritise features and their relative maturity to build the application’s value in a way that aligns to how you want to grow your business.
3. Respect your Goals with the Level of Investment You Make
In technology (as in many things) you get what you pay for. If you want to make an application to service a $100M business, it’s naive to think you can get away with spending $50K on development. While any graduate developer can code a basic app, it takes a lot to create a scalable, robust software that can service a huge user base and handle large amounts of money. As I said above, something of this level needs solid architecture and technical plans. Unfortunately, we’ve seen some entrepreneurs or companies skip this part entirely to save on cash, going straight to development with little idea of what they want or need technically. It usually ends with them coming back to someone like us to fix it up.
A proof of concept, of course, does have its place – a bare bones solution to begin with can be effective for convincing certain stakeholders, particularly if there are elements of real innovation that need to be demonstrated. But it’s worth paying slightly more to create a structure you can reuse later to build the house properly, than to start with a pile of stones you’ll need to get rid of when you’re ready to build for real. Reuse is a powerful factor in technology, and can save you a lot of time and money in the long run.
For the most part our conversations with customers are around Minimum Viable Product (MVP). The debate often centres around the richness of the features being made available. Our role is to get the balance right between form and function, and we’ll always advocate to build an application with great functionality, rock solid security and future-proof design. I came across the below MVP image in my social feeds recently, and I think it really captures the ‘whole of product’ approach that needs to be taken. As the dumbest guy in the room, I’ll have great pleasure in introducing you to my team who can tell you more!