Why startups fail in outsourcing software development

As architect, CTO and founder at four outsourced software development companies — I have architected, managed and troubleshooted hundreds of software products, most of them undertaken by small businesses and startups. And though I have tried to be pragmatic and deliver the best possible solutions, still there are a lot of failures like —

  • Product could not be completed, as start-up ran out of funds
  • Product was created, but did not get expected traction
  • Product was well received, but could not scale to broader audience
  • Product had to be abandoned, due to disagreement with developer

Many of these failures are avoidable. So, if you are a startup trying to outsource your software development, please take it as a perspective from across the table. Much of this is applicable for in-house teams also.


Mistake 1 — Trying to do too much too soon

Many startups start thinking about how to support 10,000 concurrent users from day one. It is very very hard to get that many users — and if you actually do, then congratulations, because you are already on the road to build a V2 of your product. But till you do not have clear visibility into the number of users, it is much better to not spend that time or effort. Instead build a proof of concept.

Similarly, many customers are so focused on the user interface that they think it is a make or break thing. The reality is, that I have yet to see a startup that failed due to bad UI. Remember the first UI of Paytm? It didn’t even look professional but still we used it because of the great discounts it offered.

No market need (42%) and ran out of cash (19%) are the top reasons of startup failure — Fortune

So you need to find out about your business model with minimal software. Obviously, the product needs to be functional and usable — but no point in trying to get the perfect user experience. It is the value you are trying to provide through your product that wins. But this is so common that I rate this as Mistake #1. Many times, I have even advised startups NOT to build software if their business can work using spreadsheets.

Couple of years ago, I worked with a travel startup, and the founder wanted the absolutely best in user experience, and though we suggested a simpler solution, his view was that it was a business blocker. He finally built the experience, but the business model did not work out. Till then, he had spent so much that there was no cash left to try another business model.

Mistake 2 — Fixing costs and scope

Software development is inherently risky, and hence many startups insist on fixed cost projects, trying to protect their downside. However, this almost never achieves the desired outcome. Why?

Because the same risk is carried by the software development partner too. You might feel that being a specialist they know about the various possibilities, in some ways all software is unique. So the software developers protect themselves from the risk by fixing the scope and charging you for any change requests.

Many companies like the idea of writing a contract that fixes scope and price because they think it lowers their risk. The mirage says that their financial obligation is fixed at the price of the deal. If they don’t get satisfactory software, then it won’t cost them.
In my independent days, I always advised clients to avoid this mirage, it works fine in theory — but practice bites a big chunk out of its strengths. — Martin Fowler

The problem is that startup software products almost never work out with a fixed scope — your vision changes as the product evolves, many times your ideas are not correctly interpreted and feedback from customer also requires changes.

So either you end up paying a lot for the changes, or there is disagreement whether the change is part of fixed scope. Keep in mind that a services business only earns revenue based on the time spent. Even if you are able to leverage your remaining payments to get the software developer to agree, they are likely to cut corners or as it happens sometimes, they will book their loss and quit the project midway, leaving you with unfinished product and lost opportunity.

So, do all the diligence needed to select your software development partner. But once you have chosen a development partner, your best bet is to trust them and pay them for their time. That ways you are much more likely to end up with a working product. Best way is to discuss your budget with the software developer and see what could be possible within that budget.

To eat my own dog food— I have outsourced work to freelancers and other smaller software development companies without fixed costs. Admittedly, there is a bit of fear but the results have worked out quite well. The costs overshoot many times — because there are ambiguities between what you think as a business, and what a software developer thinks. And rather than arguing about what should have been thought — you get a product that can be actually used.

Mistake 3 — Not choosing the right technology

The founders or their technical leadership of startups typically choose the technology for their product in one of the following ways.

  • Some people choose on the basis of their comfort — what they might have used in their past career
  • Others choose on the basis of perception. You have heard that Ruby makes prototypes quickly, so you make your first version using Ruby.
  • Yet others choose the latest technology or framework. This often happens with a technical founder.

All of these methods do not help you much. No matter how closely you know it, the technology changes very fast and without hands-on knowledge, you would not be able to help speed up the product. Similarly, fast prototyping should be done using a ready platform, like WooCommerce for e-commerce or SocialEngine for online communities.

Of course, if you have an existing team experienced on a certain technology or the availability of developers is more on a certain technology, that is a much better reason to go for it. But the choice should be driven by your business goals, not your bias.

Recently we developed an automated system for downloading US patents bulk data and indexing it in ElasticSearch. We chose to develop the system using AWS Lambda, and the customer wanted us to write the functions in Node. However, soon we discovered that the better open source libraries for parsing US Patents data were written in Java, so we changed track and delivered the solution used Java within budget. This would not have been possible without support from the startup customer, who trusted us to make the right choice.

Mistake 4 — Being agile in process, not spirit

Agile, with all its shortcomings has certainly reduced failures — by reducing the huge costs that used to go down the drain in documenting big requirement specifications and design documents.

However, most of the agile practices just remain as procedure, the scrum meetings and the sprints. The soul of agile is incremental and verifiable functionality. So at the end of a sprint (or two weeks), you should always insist on a product demo where you mark the functionality working in that demo against the complete functionality that you would like to see in the product. Regular demos keeps your software development partner on their toes and avoids costly mistakes.

However, what I have experienced is that most startups do not put the necessary focus in these demos till the estimated cost (or fixed cost) is surpassed and then they suddenly run into panic, trying to wrestle with their software developer on how that happened. The reason is viewing the software as a one big chunk that you have to pay for. Instead, view it as something you own after every sprint.

What should you do if the product is not progressing as per your budget? Try to work with your software developer to push out an integrated product with lesser functionality. Of course, sometimes what will happen is that while your sprints have gone well, delivering the end product seems to be an endless cycle — this is also because due diligence for a sprint is not done as you would do for an end product. Make sure your software developer fixes the errors of a previous sprint before moving to new functionality, and if that also takes very long, you may need to think of cutting your losses.

Mistake 5 — Less effort in requirements

It is well known by software researchers that a defect caught during testing stage takes about 5x more effort to fix than a defect caught during requirements stage.

However, it has been my experience that many startups neglect documenting requirements as the founders are focusing more on business execution. Instead they rely on discussion on their ideas, and even if there ideas are documented to some extent by the software developer — they approve it without fully realising the implications. And the negative cases, the handling that should happen when things don’t go according to expected flow are rarely thought through.

It is perfectly fine to just think at a high level for the complete product. However, when the implementation is started for some use cases, those specific use cases need to be documented well. Many times, even screenshots don’t fully capture the complexity of a use case. If possible, also build a mockup version without any functionality. You can also use the mockup version for getting customer or investor feedback.

We were developing a simple mobile app for a 2FA authentication provider, and the specification was quite clear — the user launches the mobile app, provides a phone number, receives an SMS and then logs in. But once the first version was done, there came several edge cases — like what should happen if the SMS was not received, or when mobile screen is locked between the process and many more. The application actually took 30% more than estimated because of various edge cases.

Mistake 6 — Building transactions not relationships

Remember that your development team is looking to engage emotionally in what they do. So regularly providing your development team insights about the business context and developing relationships with them is the key to success.

In my experience, it takes several months for the development partners to understand the business you are trying to build. They think more from a product specification perspective, and that is where a thinking mismatch happens. So, if your timelines are shorter than that, the best way is to keep viewing the product with them and explaining how the features work towards the business model.

However, most of the interaction between startups and their development partners remains limited to status updates. So the relationship never really develops to the point where developers start thinking of themselves as part of your business.

One of our customers delivers behavioral training mobile apps for young adults with functioning challenges typically caused by ADHD and Autism. He has always taken care to engage and educate the developers on business context, carefully taking their suggestions and appreciating their work. The result is that the same developers are much more motivated and have delivered significantly better results than the other products they have worked on.

Mistake 7— Not planning for support

Once your software development is complete, many startups naturally close the project in order to save on costs. This is a big mistake as software is a dynamic entity. There will always be bugs that are not discovered yet or your customers may want some changes. There are two ways to go about it.

First is, to hire an in-house developer if you are already seeing some traction on your product, and arrange for a knowledge transfer from your software developer. If you have been a reasonable customer and are ready to pay for the handoff time, this should be smooth.

Second way is to have a support contract with your software developer. Of course, some of this spend may not be as efficient because your developer will not be doing full speed development. However, this has a big advantage too — technical knowledge of your product is retained and any small changes or fixes you need will be done much faster.

In Hindsight

Startup founders have a difficult job, they have a hundred things to balance— the investors, business execution, software development, customers and more. Every startup has its own unique challenges and will have to decide how much time and money to put into software development to avoid the same mistakes.

Deciding how much is too much is perhaps the most difficult decision. Avoiding fixed costs, choosing technology and building relationships are mindset issues, which you can tackle by realising that there is really no difference in outsourcing software and your own team other than trust. Putting efforts in requirements and verifying each sprint are the ones that require solid effort on your part as founders.

Have you as a startup made similar or different mistakes in hindsight, while outsourcing software development?