Building the Throwaway Version First
I spent a weekend building an MVP of an app I actually want to make properly, with no intention of shipping it. The point was to find out which decisions were real.
There is an app I want to build. Not a weekend project, a real one, the kind with a schema you have to live with and users who notice when you get it wrong. I am not ready to build it yet.
So I built a version I plan to throw away.
I am keeping the specifics to myself for now, partly because the idea is not the interesting part and partly because I would rather talk about it when there is something to show. In outline: a consumer app for matching people, built around actually meeting in person instead of accumulating conversations, where compatibility is computed from how people live rather than what they look like.
What I want to write about is the prototype, and why building one you intend to discard is different from building an MVP.
They are not the same thing
An MVP is the smallest version you would still ship. Every decision is load bearing, because you are going to keep it, and that makes you cautious in exactly the places where caution is expensive.
A throwaway is the fastest version that answers your questions. Nothing is load bearing, so you can make the wrong choice on purpose to see how wrong it is.
I built a monorepo with an API, a web client, a mobile client, a database with geospatial support, magic link auth, seed data, and CI. Two weeks of evenings. Roughly none of that code will survive. All of it was worth writing.
What it actually told me
Which problems were hard was not what I guessed. I assumed matching would be the hard part, since that is the part people talk about. Matching was a weekend. The hard parts were geospatial queries at the boundaries between areas, and the fact that "when are two people both free and near each other" is a genuinely nasty scheduling problem that I had been treating as a detail.
Which decisions were actually reversible. I had been agonizing over the mobile stack. Building it revealed the client is thin and the model lives in the API, so that choice is cheap to revisit. Meanwhile the shape of the venue and availability data, which I had barely thought about, turned out to constrain almost every feature downstream. I had my anxiety pointed at the wrong thing, and only building it moved the anxiety somewhere useful.
Where the product was quietly boring. Some of the mechanics I was most excited about were fine on paper and flat once they existed. That is the cheapest possible place to learn it.
The discipline it takes
The failure mode is falling in love with your throwaway. You spend two weeks on it, it works, and now you are attached, so you start treating prototype decisions as commitments and defending code you wrote to answer a question you have already answered.
Two things helped. I wrote it in a repo I always intended to leave behind. And I let it be ugly in the places where being pretty would have been the reason to keep it.
The stuff I am carrying forward fits in a document. The geospatial approach and its edge cases. The availability model, which is where the real product complexity lives. A list of the mechanics that were dull in practice. That document is the deliverable. The code was the means of producing it.
Why bother
Because the alternative is finding all of this out with a schema in production and users on it.
Two weeks to learn that my instincts about the hard parts were wrong is the best trade I have made this year. The real version starts from a much better place, and starting it has never felt less risky.