I started mvp.cafe because I kept seeing the same failure pattern.
A founder had a real problem, a detailed document, a long feature list, and months of activity. What they did not have was a small product in front of a real user.
The work looked serious: research decks, architecture diagrams, vendor comparisons, wireframes, roadmap workshops. But none of it created the evidence that mattered.
Would someone use the thing?
The planning trap
Planning is useful until it becomes protection from reality.
A specification cannot tell you whether the user understands the product. A polished prototype cannot prove that the workflow survives real data. A roadmap cannot show which problem hurts enough to change behaviour.
The only reliable way to reduce those uncertainties is to put a constrained version in front of people, observe what happens, and update the decision.
That sounds obvious. It is surprisingly rare.
What ten years of product work taught me
My background does not fit into one neat software category.
At Fourzip, we built fleet and IoT systems that had to survive unreliable networks, physical devices, government operations, and thousands of moving vehicles.
At GoMechanic, product decisions touched call-centre operations, connected-car hardware, memberships, advertising, partnerships, and a second market in Malaysia.
At ZYOD, the problem was not “build a dashboard.” It was connecting physical material, factory work, system records, and financial consequences. The resulting manufacturing systems helped unlock blocked working capital and shorten operational cycles.
Then I built UTMStamp in 13 days. That project was a useful reminder that speed is not the opposite of product thinking. Speed is valuable when it compresses the time between a hypothesis and evidence.
Across all of those environments, the technology changed. The useful habits did not:
- start with the operational problem;
- cut scope until the learning goal is visible;
- make the workflow real as early as possible;
- instrument behaviour instead of collecting opinions alone;
- keep the parts that work and remove the rest.
Why “MVP” needed rescuing
MVP has become a vague label attached to almost anything unfinished.
Some teams use it to mean a clickable prototype. Others use it to justify poor reliability. Others quietly build the entire roadmap and call the first release an MVP after the fact.
My definition is stricter:
An MVP is the smallest real product that can test the riskiest business assumption with actual user behaviour.
“Smallest” controls scope. “Real product” excludes theatre. “Riskiest assumption” forces prioritisation. “Actual behaviour” creates evidence.
That definition is the spine of mvp.cafe.
What mvp.cafe is now
mvp.cafe is an educational writing and tools project.
It is where I document practical frameworks for founders and product teams:
- how to validate an idea before building;
- how to write an MVP specification;
- how to prioritise features without roadmap theatre;
- how to track the five metrics that matter early;
- how to estimate MVP cost without pretending precision.
The free tools turn some of those frameworks into usable checklists and decision aids. The case studies show how the principles behaved in real operating environments.
There is no promise that every framework fits every company. Product work is contextual. The goal is to expose the reasoning so you can adapt it rather than copy a template blindly.
The café metaphor still works
The name came from a simple contrast.
Product development is often presented like a construction megaproject: long plans, large committees, heavy hand-offs, and delayed feedback. Early product discovery should feel closer to a café counter.
You make a constrained choice. The result arrives quickly. You experience it. Then you decide what to change next.
That does not mean careless execution. A good café still needs a repeatable process, quality ingredients, clean tools, and attention to the customer. Speed works because the operating system underneath it is disciplined.
What I am trying to publish
I want mvp.cafe to contain fewer generic startup opinions and more decision-ready material.
That means:
- first-party lessons from products I have actually worked on;
- frameworks with clear boundaries and failure cases;
- technical guides that explain trade-offs to non-technical founders;
- honest case studies without invented certainty;
- free tools that help someone make a better decision in one sitting.
It also means removing weak articles when they do not earn their place. A large content archive is not useful if dozens of pages repeat the same answer.
The operating principle
The line behind all of this is simple:
Solve business problems. Do not ship features for the theatre of shipping.
Sometimes the answer is software. Sometimes it is a spreadsheet, a process change, a manual test, or a decision not to build.
mvp.cafe exists to make that distinction easier to see.