Owning code is an entrepreneur’s nightmare. This is why.
You have a revolutionary idea, which will change lives and have a huge impact on our future. Or maybe you just have a great idea for a profit-making platform that will simply make people’s lives a bit more relaxed and comfortable, while bringing you and the investors nice profits.
Whichever it is, I bet you have already heard multiple times that most startups fail (what an encouraging thing to hear and read everywhere! 🙄 ). Please keep reading, as this article is not about these numbers, it is just to give context and reasoning for what follows.
According to CB Insights, almost 30% of failures are due to running out of cash, 23% are because of not having the right team, and 19% just get outcompeted [link]. So basically it is all about time ⏰ and money 💷.
These statistics are not meant to discourage anyone, but rather to focus on what should be looked into and avoided as soon as possible, so that these statistics do not apply to us.
CODING IS NOT WELCOME ⛔
One of the main actions that can contribute to the death of a startup is immediate hiring of engineers and implementation of all aspects of the business.
Even though your code will be tailor-made, it will still be code. And code actually costs a lot; cost of engineers that create it (engineers are one of the most expensive resources of your startup), cost of hiring these engineers (recruiters, commissions, accounting, legal work, monitoring platforms), cost of benefits and contributions, extra payment for working overtime to deliver the platform on time (if it’s an hour/day based contract, or expected bonuses and treats on the employees’ side, if it is a full-time employee), cost of hosting the system on the cloud, DevOps related costs, support and maintenance costs and much much more.
In reality, every line of code that is written in your organisation — will most likely contribute to its death rather than to its success, simply because of the large financial and human cost of writing that line. (time and money)
It is simple math — not only do you drastically increase the costs of creating and maintaining your product, thus creating a very strong and costly financial dependency, but you are also creating a human dependency that you need to manage. We all want to hire rockstar ninja engineers, and it takes a lot of time and money to do so. And after you manage to assemble a team, it is possible that not all of them will be as performant and experienced as you expected, especially if you are a non-tech entrepreneur looking to build an initial team.
What if your team makes the wrong technological choices and decides to go with ‘what is hot’ instead of what is right, thus taking you on a ~6–10 months R&D journey that yields no actual usable product?
What happens if the engineer is not as performant as you initially thought, and now you are stuck with them and can’t fire them since they have all the knowledge, and without them you can’t move forward? What if your team / tech lead quits, and all their employees — follow them and leave as well?
In all scenarios described above, you are stuck with a lot of code (that cost you a fortune to create), without the slightest idea what to do with it, and even more costs upcoming for trying to save the situation and hire another engineer to fix this (who will most likely say “I can’t work with this since this is bad and undocumented and quite legacy, etc etc etc so I have to rewrite this thing (or at least most of it)”.
They might be right or wrong, but regardless of that — you are stuck and your investors are really not happy with the prospect of spending even more money on engineering at this stage.
Who will take responsibility for the old code (and the new one after that)? Nobody. Since it is your employees that built it, it is completely your ownership and responsibility. Do not expect to receive any refunds, consideration or anything of a kind. Do expect to throw all that code (or big chunks of it) to the bin at some point.
And here we are, lost both time and money, as well as the trust and respect of our partners and investors.
“But we can’t create new products without code!” — you are most likely right. But the market today is full of ready-to-use solutions that will (on most occasions) cover at least 80% of your needs, leaving a very small part to be developed and maintained in-house (that is the revolutionary part of your idea, that no-one else has implemented before).
The trick is to treat it like Lego. You need an experienced architect to assemble the pieces in a reusable, readable and decoupled way, but you not necessarily need to build the blocks themselves.
The painter metaphor
Painters — paint. They do not create the canvas, the initial colours, the brush or the lights used in the room where they paint. They do not build the house with their bare hands, the house in which they will be creating their art. It is very unlikely to spot a painter in the woods, hunting for a meal, just so they have the energy to start painting.
The painter might create their own unique colour with a special texture by mixing some basic colours and adding some additional ingredients to the paint, but that is as far as it goes. Otherwise, the picture would never get painted, as the painter will most likely be killed by a wild animal (or die of age) before getting to the actual painting part.
Same principle should be applied to your company and the way you handle your code.
Real life example
Let’s say that you are a very hot fintech startup, coming to disrupt the personal banking market. There are many aspects to your business, these include legal and your personal KYC (know your customer) requirements and documents validation. In addition to the compliance requirements for KYC, you also need to validate each transaction made via your platform to make sure it is not fraudulent. On top of it, you need to support international markets, so your platform has to be translated to several languages. A customer support team is also required to be present, with a live chatting capabilities and ticket-raising functionality. You also need to see some dashboards that demonstrate various business metrics, financial data, conversion rates, A/B tests and more. And in order to manage the whole shebang, you need a functional and comfortable admin panel (with users management, user permissions, tracking, monitoring, etc).
This sounds like a lot of work, but actually — at least 90% of everything mentioned above can be added to your system without writing it by yourself, rather just by integrating with the right service providers, and using the right open-source libraries.
Paying various service providers every month can be cheap in the beginning, but will grow as you scale. That being said, it will most likely never reach the figures of hiring and employing one senior engineer on a full-time basis. And I am certain that by using external service providers, you will save yourself much more than the cost of one senior engineer. Potentially, you could save employees of the following disciplines — Software Engineers, DevOps, DBAs, IT Specialists, some Customer Success Managers, Fraud Analysts and more. You will save the time that it takes to hire all these specialists, the time it takes them to do their job, and as a cherry on top — their employment costs and hiring commissions.
Going with an external service provider has even more benefits; This is not a wedding, and you can actually change service providers in the future. Continuous research and market comparison can always save you some money and help you negotiate better deals with existing and new service providers. In addition, if you have the right architecture in place, then switching one service provider for another will not be a problem, as it is a good practice to isolate the in-depth tech implementation details from the business unit itself, and the part it plays in the general business flow. This does, however, make the initial architecture very important.
In addition to saving costs and time, it is common practice to include a SLA (service layer availability) clause in the contract, so the SAAS provider will be responsible for any downtimes and errors that happen, refunding or compensating you partially or fully for such errors on their side. This means that there is someone that takes responsibility, and not everything is on your shoulders.
I would like to finish by saying that you should always question every “Let’s implement X” sentence that you hear or think.
Should we really? Is this requirement really that unique, that nobody has done it before, and learned from real-life mistakes with this piece?
On many occasions, the answer will be ‘No’, and that’s when you need to properly research the market, compare the pricing models, and build the right architecture to use external SAAS solutions.
When the answer is ‘Yes’, it means that you are a pioneer. Being a pioneer, you will learn a lot on your journey with your codebase, and that is awesome. And still, your engineers will most likely use various open-source frameworks to build the unique piece of code that you need, so the same principle of reusability, research and architecture applies.
Happy building 🏗
And thank you for reading 👌
The author, Lev, is an experienced fullstack software engineer and the director (and consultant) of Metamindz, a tech company working with entrepreneurs and startups on all aspects of transforming an idea (or a company) to a fully functional, efficient and lean operation, in a modern, efficient and affordable way. All aspects are covered; Software Architecture, Planning and Implementation, Hiring, R&D Structure, Working Methodology and more.
