I’ve been thinking about MVPs a bit differently lately.
Most people talk about what they managed to build.
I’m more interested in what they deliberately decided NOT to build.
AI makes it really easy to keep adding things now.
Notifications? Sure.
Analytics? Why not.
Team accounts? Easy enough.
Another integration? Add it.
But at some point “easy to build” starts getting confused with “needed right now.”
If you’ve launched something before:
What’s one feature you were convinced belonged in v1, but you intentionally left out?
And did you ever come back and build it later?
Clear and practical, thanks. Did anything surprise you along the way?
Great breakdown. What feedback have you had from early users?
Clear and practical, thanks. Did anything surprise you along the way?
Clear and practical, thanks. Did anything surprise you along the way?
Clear and practical, thanks. Did anything surprise you along the way?
Yeah — how different “working” can mean between tools surprised me.
We recently gave the same booking-app prompt to nine builders. Five produced something usable, but only Bolt and Base44 actually rejected a second booking at the server. One of the prettier outputs even allowed the same slot to be booked twice.
That made me think a lot more about what belongs in an MVP versus what just makes it look complete.
We documented the test here:
https://built.new/learn/no-code-app-builders-tested/
Nice progress. What is the next thing you are focusing on?
Right now I’m more interested in the decisions around the first version than adding more features.
What absolutely needs to exist, what can wait, and what the first real users should actually teach us.
I think getting that part right is more valuable than making v1 look bigger.
Interesting take. Would you still recommend this approach to someone starting today?
Definitely.
If anything, I think it matters more now because AI makes adding features almost frictionless.
The danger isn’t that you can’t build enough anymore. It’s that you can build too much before you’ve learned whether the core thing matters.
I’d rather ship one complete workflow and learn from it than launch ten half-tested assumptions.
Helpful post. How did you get your first bit of traction?
Burada build-in-public article’ı çok iyi oturuyor:
Mostly through conversations and sharing what we’re learning rather than trying to manufacture a big launch spike.
I’ve been looking quite closely at build-in-public for this reason. We recently analyzed 57 posts from Base44’s founder, and the interesting part was that lessons, costs and things that went wrong consistently got much more engagement than normal feature announcements.
That pushed me more toward sharing useful findings instead of just posting product updates.
https://built.new/learn/build-in-public-playbook/
Good write-up. What would you do differently if you started again?
I’d define the question the MVP is supposed to answer before defining the feature list.
It’s really easy to start with “we need auth, analytics, notifications…” and only later ask what you were actually trying to validate.
Next time I’d write the core user flow first, then make every extra feature justify why it belongs before launch.
This is useful. How are you finding your first users so far?
We’re still early, so it’s mostly very manual — founder communities, people already building with AI/no-code tools, and conversations around early MVPs.
I actually like that at this stage because the same conversation can give you both a potential user and a product insight.
How did you decide this was worth building in the first place?
Repetition more than one big “aha” moment.
The same problem keeps coming up: people can build faster now, but they still struggle with deciding what the first version should actually be.
When you hear the same confusion around scope, priorities and “what do I build first?” often enough, it starts feeling like a real problem rather than just an idea.
Thanks for sharing the numbers, that makes it much easier to follow.
actually didn’t share any numbers in this one 😄 This was more about MVP scope and what people intentionally leave out of v1.
Really relatable. How much time do you put into this each week?
It varies quite a bit depending on what we’re working on that week.
I try to spend less time just producing more and more, and more time looking at what people are actually asking, testing assumptions, and turning that into something useful.
Thanks for writing this up. Bookmarking it for later.
Appreciate it. I’d actually be curious to hear what you end up leaving out when you get to that point — those decisions usually say more about an MVP than the feature list.