Many software startups start with a junior programmer or two due to lack of money to afford a senior programmer or an architect. This has negative mid-term and long-term effect on the project.
High-quality architecture is very important and is not something you can’t just slap onto a system at a later stage of development.
But We’re Just Testing an Idea!
Yeah, I understand that many startups start with an MVP these days. Given the low budgets many startups have, having an architect develop an MVP would be prohibitively expensive. And that’s the reason many startups hire a cheap junior programmer to develop their MVP.
But you don’t really have to have an architect develop the MVP. You could still have a junior programmer doing most of the work, but you still need an architect to make long-term decisions like picking the technology stack and oversee the development.
Making Proper Early Decisions
Juniors often make poor decisions when it comes to the technology stack. They pick a stack they’re familiar with and most juniors only know a single stack. That stack might be far from what a project needs.
And since technology stacks are very hard and expensive to replace once a system is in production, a poor choice will have a negative impact on the pace and quality of development down the road.
I’ve personally inherited systems based on completely inadequate technology stacks regarding the programming language, the framework, and the database. When I was building an experienced team for that project later on, it was almost impossible to find strong programmers experienced with those crappy stacks or even willing to deal with them. It resulted in a lot of development overhead that cost a lot of money to the business.
Actually, consider yourself lucky if you end up with a good junior programmer building the initial version of your system. In that case, even if their stack of choice sucks, at least the code they write will be somewhat decent. But many businesses end up hiring mediocre programmers that completely mess up the technical side of the project that ends up costing a lot of money to fix once you can afford an architect with senior programmers.
MVPs Are Not Prototypes
An important distinction between MVPs and prototypes is that prototypes are supposed to be thrown away and the system is supposed to be rewritten from scratch. And often on a different technology stack.
Prototypes are often developed in technology stacks that are good for rapid development. There are even different frameworks based on the same underlying components where one framework is good for quick prototyping and the other is good for long-term development.
But MVPs are not prototypes. MVPs are not supposed to end up in the trash. Especially when they’re successful.
And that means that whatever the technology decisions are made by a junior programmer when building the MVP will stay with the system until senior programmers spend a lot of time and money to replace. That slows down the growth after the MVP has got initial traction.
Consider a Different Payment Setup
At the very start of your project, you don’t really need a full-time architect. Especially if you can’t afford them.
But you still need an architect in one way or another. You should really consider having at least a part-time architect to oversee the general direction of the system architecture.
If you can’t even afford a part-time architect, consider an equity-based payment setup. These days, many startups have a business advisor who gets some equity in return for their advice. You could apply the same approach to get yourself a technical advisor as well.