Do you know what every software startup entrepreneur dreams of after they validate the market? Software that does not break with scale and is adaptable to change.

It is then that they realize that their glorious Proof of Concept (POC), built with sticks and rubber bands (that worked so far), breaks with load and snaps when extended! Services go down frequently, and the lead time to onboard new customers increases. Every new customer will come with their “small” change list to adapt the software for their business flows/needs.

The entrepreneur then realizes that they have reached that much-coveted point — build serious software which can be relied upon. But they frequently don’t know what it takes to build such software. The approach of building with sticks and rubber bands does not help anymore. They need something reliable and extensible. They need proper software engineering.

Enter software architects turned consultants who know what it takes to build reliable, extensible, and performant software but find it very hard to convince their customers to walk that path. Why? Because it is always hard to unlearn bad practices. Even more so if said bad practice has worked before. They miss that building POCs is very different from building robust software that can be extended and scaled easily. Even when their needs have evolved, continuing with the POC approach is precisely why their current software is hard to change, unreliable, and takes more effort (cost) to maintain.

I am not arguing that every startup should build software this way. No. Validating your idea for solving a business problem requires a rapid turnaround time without worrying much about long-term implications. But, once you are sure that your solution indeed works (customers are paying, and you are growing), you have to start replacing the sticks and rubber bands with reliable blocks. This needs sound development practices and readiness to invest in building a good team.

The development practices that got you here will not take you to the next level.

“I want awesome software but I want it quick, without going through the pain and slowness of building the right team and practices.”

is similar to saying,

“I want a long healthy life. But I don’t want to work out and make healthy food choices every day.”

Here is what I think it takes to build good software:

1. Invest in building a good engineering team: Building complex software (anything that solves an end-user problem at scale requires complex software) is a social process. Meaning, that the engineering team should work cohesively and in lockstep with the business. Invest in building a good engineering team instead of thinking of them as a bunch of replaceable hands attached to heads that can write code.
2. Design evolves: Breaking down the whole system into multiple services, once, in the beginning, and creating neat documents that the developers “just follow” is not how robust software is built. Every service will evolve based on the group’s understanding of the problem it is trying to solve. Overall system design evolves with the development of different services and the scale. It is vital that the whole team understands this and pitches in regularly to make the components simple to maintain, clear by continuous refactoring, and reliable by automated testing.
3. You get what you pay for Building good software is not cheap. There is this old adage “If you pay peanuts, you get monkeys”. I feel this is apt for software developers. I don’t literally believe in 10x developers. But, there are good developers who can avoid problems entirely instead of solving them efficiently which makes them a lot more valuable than 1x. They don’t come for peanuts because of the law of demand and supply.

In summary, if you find yourself unable to evolve a system with predictability, focus on the team that is building it instead of the product that got built. And remember that building good software is cheaper only in the long run.

Disclaimer: This post is based on my observations and analysis of a recent software consulting engagement I did. All these are my personal thoughts and do not represent anyone / any entity whatsoever.