MVPs make bad milestones_

When investing in a project it's tempting to say the same old line "Let's just get something out there now, and we'll come back and fix it later."

You never will, as we all know. Don't argue with me.

This leads to the majority of outcomes where your MVP/prototype/experiment is stuck with you as a permanent fixture of a project whose rewrite is pitched every other month due to its failure to scale and consistent stream of headaches.

Making something that's "good enough" is indeed the right answer, but it's right only 30-40% of the time, the remainder the extra time investment of doing it "right" would have paid off easily in the medium and long run.

The term MVP itself became a buzzword long ago, shifting into the technical domain from the product realm, to the detriment of many projects, losing all clear defined meaning, able to pushed and stretched further and further to suit the needs of the speaker.

This has left us with a generation of developers who think that the MVP is supposed to be a half-baked, barely functional, untested, unmaintainable piece of software that will be thrown away after serving its purpose.

In reality these Maximally Viable Problems are kept as the basis of the next iteration(s), with compounding limitations, and bugs.

Value in startups

"But wait," you say, "you've always preached minimum time to market and just shipping what you have."

This is true, but seeking early validation and feedback of an idea is not the same as shipping a half-baked product, they're not in the same ballpark. In fact, I believe nothing should be shipped until you have "validation" of a product.

Once you're entering the market with something tangible it makes sense to put your best foot forward in terms of UX, performance, and maintainability.

This doesn't mean feature stuffing your first version, it just means doing a decent enough job that you're not continually fighting against your own codebase to customers who handed over money while you rushed through ideation to market.

In fact if your product is still in search of a market, and you're pivoting regularly you're far, far more likely to have trouble doing so without a properly abstracted codebase of services.

Value in orgs

In a larger or more "traditional" organisation the urge to "just get something out there" is even stronger. Arising from tight deadlines, stakeholder pressure, and potentially in the worst case a sign of a lack of trust in the team's ability to execute.

But as the product gains traction and the user base grows, the problems compound. Suddenly, the team is faced with a choice: continue to build on a shaky foundation or invest significant time and resources into a rewrite (assuming you have the technical ability to even do so properly).

The latter option is often met with resistance. Stakeholders may argue that the product is already generating value and that a rewrite would be a waste of time. But this ignores the opportunity cost of continuing to build on a suboptimal system. Every new feature takes longer to implement, every bug takes longer to fix, and the overall quality of the product suffers.

At the end of the day there is no such thing as avoiding technical work, only shifting and compounding the amount of work you have to do by delaying it.

What am I advocating for

To clarify, I'm not pushing for 6 months development on the first version of your website, I'm just strongly encouraging you not to wing its technical implementation.

Minimal feature sets are a great idea as you gather user feedback, but don't mistake this with sacrificing the quality of your codebase unnecessarily for the sake of what has become a buzzword.

The same goes for larger organisations. Though deadlines are tight and stakeholders want the moon on a stick, it's important to always work towards a well architected, scalable, and maintainable system.

You just know you'll regret it later if you don't. And if you disagree, I'm sorry, you're the midwit in the meme.

As the lead to the article says, shipping fast doesn't mean shipping without timezone support.

Oh, and as always: it depends.

This mini-snack was inspired by a video from the Primeagen I think, idk, i couldn't find it when i looked again.