#26 - Should Your First MVP be "Expedient" or "Elastic"?

I need your opinion on something.

My friends and I are building an app, and we’re making great progress. But wow, have we been inefficient...

When my buddy and I sat down to write the first lines of code, I expected the process would feel like a 40-yard dash: a straight-line sprint from point A to point B.

But in reality, it’s felt like running suicides: spending half of our time backtracking, drenched in sweat, only to get a little further each time.

We tried to hack together our first iteration as fast as possible. That first version was slow, buggy, and impossible to evolve. We had to throw almost all of it out and re-architect it from scratch.

We’re a few iterations in now, and we’re still so often writing spaghetti code and building up tech debt just so we can stick to our self-imposed release schedule.

Maybe this is what the “lean startup” approach is supposed to feel like, but I can’t help but think we could have done better. If I build another startup (which is an inevitability given my acute case of shiny-object-syndrome) I want to take the most efficient approach to building and iterating on an MVP.

In my mind, there are two categories of MVPs one could build:

“Expedient” MVPs

Build an MVP that you can put in users’ hands as fast as humanly possible.

This is the approach we’ve taken so far with this app, and it certainly has its benefits: we managed to learn some important insights early on that totally changed our direction for the next iteration.

The big downside is that these MVPs are gross and brittle. A lot of the feedback we get from users is on bugs and performance rather than on the hypotheses we’re trying test. Also, the code is often rigid, suboptimal, and difficult to evolve. So we often need to toss it all out and start from scratch.

“Elastic” MVPs

Optimize for flexibility. Take as long as you need to implement a clean and flexible architecture that can be easily evolved.

This is the approach I naturally lean into. If my team and I had focused on things like “dependency inversion” and having clear “separation of concerns” in our code, we would have been able to iterate on the application quickly and painlessly without having to throw out a ton of work.

The disadvantage here is that it takes a lot of upfront effort, significantly pushing back the timeline for the first MVP. You may quickly figure out that what you spent so much time painstakingly building was the total wrong solution.

—

So which MVP would you build if you were starting from scratch?

As with most “either or” questions, I assume the true answer is the unsatisfying, “somewhere in-between” or “it depends”.

Depending on how murky the waters are, I’m thinking I’d probably start out with an “Expedient MVP” just to figure out ASAP whether or not I’m building something people want. And if/when I feel convicted that I am, I’d slow down and build an “Elastic MVP” that allows me and my team to move faster in the long run.

Quick reminder - If you appreciate my writing, please reply to this email or “add to address book”. These positive signals help my emails land in your inbox.

If you don't want these emails, you can unsubscribe below. If you were sent this email and want more, you can subscribe here.

See you next week — Rayhan