Between 2023 and 2025 we shipped three MVPs that nobody used. Not a polite-no-traction kind of nobody: the kind of nobody where the analytics dashboard becomes a meditation aid. Each project had a great founder, a real budget, and code we were proud of. And each project, six months in, was either pivoted into something unrecognisable or quietly shelved.
What follows is what we learned, and what we now ask before we touch a keyboard. It is also, in places, a confession.
Three MVPs, three quiet failures.
The first was a marketplace for second-hand camera gear. We thought we'd built a Stripe Connect masterpiece. We had. Nobody listed anything. The supply side had no reason to be there yet. We'd built half a marketplace.
The second was a CRM for music venues. The founder was deeply experienced and had a waiting list of three early customers who had said the words “I would pay for this.” Reader, they did not pay for it. They liked the demo. They didn't change behaviour.
The third was an AI-powered email triage tool. We shipped it in nine days. The early users were enthusiastic. Three months later they were quietly back in Gmail.
“We had built something they liked. We had not built something they needed.”
The “vitamin not a painkiller” trap.
The cliché is true and we kept falling into it. All three of these projects were vitamins: nice to have, slightly better than the status quo, easy to put down. None of them were painkillers.
What's worse: we knew this in theory. We had asked the painkiller question. But we'd asked it wrong. We asked: “Would you use this?” Everyone said yes. We didn't ask: “What are you doing today that this would replace?” When we asked that, on the third project, the answer was “nothing. I just deal with it.” That's a sentence we now treat as a stop sign.
The trap of shipping the wrong thing.
We pride ourselves on shipping fast. Fourteen days, brief to production. That's our default. But fast shipping is a tool, and we used it badly. Three times we built the wrong thing quickly, instead of building the right thing slowly.
The thing we now do, before any code: write the homepage of the thing-that-doesn't-exist-yet. Three paragraphs and a hero. Show it to five people who might use it. If nobody wants the page, nobody wants the product.
- If the homepage doesn't make people want the product, the product isn't the problem.
- If people read the homepage and say “what about X?”, that X is your actual product.
- If you can't write the homepage, you don't understand the product yet.
What we ask now, before we touch a keyboard.
Three questions, every kickoff. We won't start a build without an answer to each.
1. What are users doing today instead? The “nothing, just deal with it” answer is a red flag. We want a specific tool, a specific workaround, a specific person on the team handling it.
2. If we built nothing, what happens? If the answer is “we keep going, slowly,” we walk. If the answer is “we lose money every month,” we start tomorrow.
3. Who is the first user, by name? Not a persona. A person. If you can't name them, you don't have a user yet; you have a hypothesis.
The small acorn rule.
The pattern across all three failures was the same: we planted too big. We built the marketplace, not the listings tool. We built the CRM, not the booking sheet. We built the email triage, not the “show me only the threads that mention me” filter.
Now we plant smaller. The smallest acorn we can find that solves one real, named, painful problem for one real, named person. Then we stay. Then it grows.
None of this is new. It's all in The Mom Test and the lean startup books and a thousand essays you've read before. We knew it. We did it anyway. We do better now.
— A.B., from the studio, on a Friday afternoon.
