Have you ever had to move apartments? If you have, then you know that before you moved, you had to choose the right apartment, in the right neighborhood. Imagine now that you went from one neighborhood to another, looking for the right one, with a van carrying all your furniture. This excess baggage, while you are still testing the waters, is only going to hinder you.

Infrastructure overhead

I once walked into a recently revamped web app for some adjustments. I found out it uses Nx and a monorepo for two projects: the web and the mobile version. The requirement was to turn it into a responsive app, so there was going to be one project. I was shocked to find out no other developers were working on it.

Whoever built the project first either had his heart in the right place, believing that it would one day grow into 100 projects with 500 developers, or he or she simply used the only tool they knew how to use: a hammer. With only two years in its lifetime, it was already four versions behind Angular and uses a legacy NodeJs version. The efforts spent on adopting Nx should have been spent on keeping the app up-to-date.

Technical debt, the baggage

The problem with starting MVPs with a large overhead is how fast it builds up technical debt. During the initial stages of the project, which may last 3 to 5 years, they are touched by many different developers at different times, without any line of communication. The business is still testing the market, and change requests are frequent. There is nothing in the setup that would stop one developer from disregarding an existing library and installing a new one. Nothing.

Some businesses opt into the mindset of ship now, build later. There is nothing wrong with that mindset because it gives priority to what the business needs at the moment. The only problem is that shipping becomes harder and slower, just like driving a van full of furniture all around town, up the hill, and into the moon.

What to do about it

Every startup has its own story. There are generally some tips I have gathered through working with some of these stories, but they are not necessarily rules.

Reduce dependency

The shortest, most optimistic time to build and ship an MVP in my experience was one year. Within one year, new versions are rolled out, issues are uncovered, and almost all libraries have a breaking change. Reduce the amount of maintenance by reducing dependencies.

Delay

Delay infrastructural decisions if you can, and make stubs and abstractions for later, but wait until you really need them. Start with multirepo. Be prepared to revamp when you validate your idea.

Slow down

Some businesses (notably 37signals) adopt a healthier mindset of going slowly and building steadily. This might not suit a lot of other businesses, which need to test the waters first, but you could always opt into it when you are ready.