Startups, MVPs and the Illusion of "Doing It Right"

Posted by Neil Ludlow on Wednesday, 18th June 2025

Time to read: 5 minutes

I often come across projects that have changed hands, started by one team, then inherited by another, only for the new team to realize the code isn't fit for purpose. So the new team rewrites it from scratch.

It's more common than you might think. Either because products evolve, requirements shift, or because what made sense at the beginning often doesn't match what's needed six months or two years later.

Or, another reason that rewrites can happen is that a new team starts working on the projects and they either don't want to work on other people's code, or they take one look at the code and suggest a rewrite.

That's why I believe early stage startups need to be careful when deciding how "properly" to build their product from day one.

It is one thing to have funding and/or customers, then pouring cement into your foundations. In that case you have the means to do the project as properly as you want. But even then, who's to say what course your product will take in the future.

Then, it's another thing to have your idea without having any funding, money or customers and wanting to be overly "proper" from day zero. Your product can easily change purpose in the process of making the MVP. And even if the product gets built and you're happy with it, the extra time and effort doing things the proper way won't matter in less than 24 months when someone else wants to rebuild it from scratch.

I recently had a conversation about early-stage startups and whether everything should be built “properly" from day one.

Here's the scenario...

• You're building a new product.
• You have no funding.
• You have no customers.
• You have one developer.
• You need to ship an MVP to figure out if it will be useful to anyone (even you).

In that situation, is it worth spending time building everything the way a small team at a proper company might? In many cases, probably not.

What am I not talking about?

• Anyone with funding.
• Anyone who is coding their own side project in their own time and doesn't need the money.
• Anyone with customers.
• Anyone with employees.

At this stage, your job isn't to build the perfect product, it's to build the right one. And you don't get there through polish, you get there by shipping something testable and learning fast. Trial and error.

Of course, this doesn't mean you should be reckless. But it does mean your priorities should be speed, feedback, and adaptability. Write code that's easy to rewrite. Sketch out structure that can grow if needed, but don't over-engineer on day one. A lightweight skeleton with rough edges is usually more valuable than a pristine but brittle architecture.

And here's the kicker... even if you build things "properly", there's a good chance you'll end up rewriting it anyway. Your product will change. Your customers will surprise you. And the code that felt rock solid in Month 1 might be dragging you down by Month 12.

So what should you aim for?

• Build fast. Learn faster.
• Write code that's easy to throw away. Because you will.
• Leave clues for "future you". Comments, TODOs, and notes about what you'd refactor if this thing catches on.
• Choose flexibility over perfection. Every time.

Now, I can hear the pushbacks... "Isn't this why so many projects fail? Because the code wasn't built properly and had to be rewritten?"

Here's the thing, needing a rewrite isn't always a sign of failure, it's a sign of progress. It means you've learned enough about your product and your users to know what really needs to be built. The real failure is spending months building a pristine system for the wrong problem.

I have also seen projects that have been too rigid, too difficult and time-consuming to change to adapt to the problem you're fixing. In this case persevering with inflexible code may be more time-consuming and ultimately only delaying the inevitable rewrite. I have been too slow to identify this in the past, perhaps the reason for this article.

Finally, take Netflix. I don't know for sure, but I assume the DVD mailing software they once used is long gone. They started at the very beginning in one direction, then pivoted. Their business changed. And from reading about their early days, it sounds like their very first product was very far from perfect, even for the time. So even with funding and a team of developers, they still had to launch something to get the income and customer base that would eventually grow to become the giant they are today. But, the point is, they were not obsessed with "doing things right" and being very "proper" at the start, and even if they had been, that code is nowhere to be found today.

What to look for in a developer or CTO at this stage?

At this very early stage, I'd suggest you should be looking for...

• Not someone obsessed with best practices, but someone who understands the stakes.
• Someone who knows how to build to learn.
• Someone who knows which shortcuts to take, and which not to.
• Someone who's honest about hacks and tech debt.
• Someone who knows when to say "we'll fix this later, if it's worth fixing".
• Perhaps, someone with experience of doing this before.

At this point, before you've found your market fit with a working product your goal isn't to build something perfect. It's to build something worth rebuilding. And the faster you get there, the better.

Once you've got your MVP...

Once you've shipped your MVP and started to find traction - customers using the product, or investors showing interest - the game changes.

At this point, you're no longer validating an idea, you're building a real business. This is where it can make sense to slow down and start laying proper foundations.

If you're talking to VCs, they'll often want confidence that your product can scale with funding. And if you're serving real customers, reliability and maintainability become critical.

But here's the beauty of moving fast in the MVP stage... you'll have learned enough about your users and your market to know where to invest your time. Instead of over-engineering for problems you might have in the future, you can solve the ones you definitely do.

This article was re-written on July 3rd, 2025