Idea to MVP: What to Build First
August 12, 2026 · PanaceaLogics Team
Most MVPs we are asked to quote are not minimum, and they rarely prove anything. They are the full product with a few features crossed out, priced at whatever the budget happened to be.
The useful question is not “what is the smallest thing we can build?” It is “what is the riskiest thing we believe, and what is the cheapest way to find out if it is true?” Those give very different answers, and only one of them is worth paying for.
Name the risk before you name the features
Every product idea rests on assumptions. Write them down and one of them is always scarier than the rest.
- Demand risk. Will anyone use this? Nothing technical will save you here.
- Workflow risk. Will it survive contact with how people actually work?
- Technical risk. Can this be built at acceptable cost and speed?
- Commercial risk. Will anyone pay, and enough?
Build to attack the biggest one. If demand is the risk, a landing page and twenty conversations beat a codebase. If workflow is the risk, a rough tool used by five real people beats a polished demo. We have talked clients out of builds on this basis, and it costs us the project, but it is the right advice.
The one-workflow rule
The most reliable scoping heuristic we use: an MVP does one workflow end to end for one type of user.
End to end matters. A product that lets someone start a job but not finish it teaches you nothing, because nobody can use it for real work. One workflow matters just as much, because two half-finished workflows are worth less than one complete one.
Concretely, that usually means picking a single user role and ignoring the others for now, supporting the common path and handling the exceptions manually, and having exactly one way to do each thing.
What to leave out, and what you cannot
Teams tend to cut the wrong things. Here is the split that has held up across our builds.
| Safe to leave out of v1 | Do not skip |
|---|---|
| Admin screens, do it in the database | Authentication and access control |
| Bulk import and export | Backups and a way to restore them |
| Configurable settings and themes | Error logging you can actually read |
| Notifications beyond the essential one | A deployment you can repeat |
| Reporting and dashboards | Basic input validation |
| Onboarding flows and tours | Anything legally required in your sector |
The right column is not gold plating, it is what separates a testable product from a liability. Skipping authentication to save a week creates a system nobody can safely put real data into, which means you learn nothing from it.
Two more that are worth the time even in v1: make it easy to change and instrument it. If you cannot ship a fix the same day, you cannot iterate, and iteration is the entire point. And if you do not know which screens people reach and where they stop, you have built an opinion generator rather than an experiment.
Manual is a feature
The fastest MVPs we have shipped had a person behind them. Matching handled by an operator, documents reviewed by a human, onboarding done over a call.
This feels like cheating and it is not. You are testing whether the outcome is valuable, not whether you can automate it. Automate once the manual version is doing enough volume to hurt, and by then you will know exactly which part to automate, which is knowledge you cannot get any other way.
A realistic shape
For most line-of-business products, a first version lands in six to twelve weeks. Under that and you are usually building a prototype, which is fine if you call it one. Over that and the scope has quietly become the full product again.
What we would expect in that window: one workflow working end to end, real authentication, deployed somewhere real users can reach, basic logging and analytics, and a short list of known gaps you have decided to live with.
What we would not expect: every role, every edge case, an admin panel, or a design system.
The part that decides everything
Ship it to people who did not build it, and watch rather than present. The gap between what someone says in a meeting and what they do when the screen is in front of them is where the real product is.
Then be willing to act on it. An MVP that confirms everything you already believed is usually a sign the questions were too easy.
We build first versions in .NET and Azure for teams who would rather learn something in ten weeks than guess for a year, and we will tell you when the honest answer is to build less. See our custom software development service, or get in touch.