An MVP — minimum viable product — is a learning instrument, not a small product. Its job is to answer the riskiest question about the idea as cheaply as possible: will anyone use this, and will they pay for it? Every scope decision in an MVP engagement flows from that purpose. Features that teach nothing get cut no matter how impressive they sound; the single core loop that tests the hypothesis gets built properly. This page is the doctrine we build startup MVPs by in Dehradun.
Dehradun's startup scene shapes what MVPs here look like: edtech and coaching-tech founders testing with local institutes, tourism and wellness founders validating booking concepts against real seasonal demand, and SaaS founders selling to small businesses across the hills. The pattern is consistent — founders with domain access and limited runway, needing evidence before the next round of spending. The MVP serves that evidence.
The scope-cutting method
Scope-cutting is the core skill of MVP work, and it follows a method, not instinct. First, name the single riskiest assumption — the thing that must be true for the business to work. Second, identify the smallest loop that tests it: the minimum set of screens and logic where a real user can complete the core action. Third, list everything else and park it explicitly in a "later" column with the trigger for building it (e.g. "build when 50 paying users ask for it"). The output is a scope document with two columns, and the discipline is that the later column is a decision log, not a graveyard — each item has a named condition for resurrection.
The v1 / later table: how it looks in practice
| In v1 | Explicitly later (with trigger) |
|---|---|
| User signup and the single core transaction | Social login — when signup friction is measured, not assumed |
| One payment method that works | Multiple gateways and wallets — when transaction volume justifies it |
| Manual admin processes behind the scenes | Automated admin tooling — when operations time exceeds a day per week |
| Basic analytics on the core loop | Full analytics dashboards — when decisions need data v1 cannot provide |
| Email notifications | SMS, push, and WhatsApp automation — when users demonstrably miss emails |
The "manual behind the scenes" row deserves emphasis: concierge-style manual work powering an apparently automated product is a legitimate MVP strategy. It tests whether users want the outcome before investing in the machinery. What it is not is a sustainable operation — the trigger column exists so manual work gets automated on evidence, not neglected until it breaks.
Validation is built in, not bolted on
An MVP without defined success metrics is just a small product. Before building, the engagement defines what the MVP must demonstrate in its first weeks of real use: activation rate (users completing the core loop), retention over a defined period, and — where the model requires it — willingness to pay. Vanity metrics (signups, page views) are explicitly excluded from the success criteria. The analytics implementation covers the core loop events from day one, because retrofitting measurement onto a shipped MVP means flying blind through the most important weeks.
Technology for MVPs: borrow before building
MVP technology choices optimise for speed of learning, not architectural purity. That means: proven frameworks over novel ones, managed services over self-hosted infrastructure, and third-party APIs over custom-built components wherever the component is not the differentiator. The codebase should be clean enough to extend — MVPs that validate get built upon — but the architecture stays deliberately simple: no microservices, no premature scaling infrastructure, no abstractions for futures that may never arrive. If the MVP succeeds, the v2 rebuild-or-extend decision is made with revenue evidence, which is the best possible position to make it from.
How MVPs fail
- Building the vision instead of the test — the v1 scope quietly expands to include the founder's full roadmap, and the learning instrument becomes an expensive small product
- No distribution plan — an MVP with no users teaches nothing; the first ten users should be named before the build starts, not discovered after launch
- Measuring vanity — celebrating signups while nobody completes the core loop, then declaring validation that never happened
- Perfecting instead of shipping — polish on an unvalidated core loop is the most expensive form of procrastination in startups
- Ignoring the manual-work trap — concierge MVPs that work so well the team never automates, until operations collapse under modest growth
What an MVP engagement covers
- Assumption mapping — the riskiest hypotheses named and ordered before any scope discussion
- Scope document — the v1/later table with triggers, signed off by both sides
- Core-loop build — the minimum working product, designed for the test, not the vision
- Measurement wiring — analytics on the core loop and the agreed success metrics from day one
- Launch to real users — deployment plus support through the validation window
- Evidence review — a structured read of what the data showed and what v2 should be
What drives cost and timeline
The core loop's complexity dominates: a simple booking flow is weeks, a multi-party marketplace loop is months. Manual-process design (the concierge layer) is cheaper than automation but needs operational planning. Third-party integrations each add their surface. And founder availability is the hidden timeline driver — MVP builds need fast feedback on scope decisions, and a founder unreachable for a week costs a week. The engagement is structured for rapid decision cycles; that only works if both sides show up.
Related services
For the broader startup web presence, Startup Website Development in Dehradun; when the validated MVP grows into a product, SaaS Development in Dehradun; and for the underlying custom build questions, Custom Software Development in Dehradun.
Frequently asked questions
How small can an MVP actually be?
As small as the riskiest assumption allows. If the question is "will coaching institutes pay for online test management," the MVP might be a working test-and-results flow for one institute — not a platform, not a mobile app, not a content library. Smallness is measured against the question, not against some absolute feature count.
Should the MVP be built to scale?
No — it should be built to learn, with clean enough code to extend if it validates. Building for scale before validation is spending the scaling budget on a product nobody has proven they want. The v2 architecture decision happens with evidence, which is precisely the point.
What if the MVP shows nobody wants it?
Then it did its job at a fraction of the full-product cost. The evidence review distinguishes between "wrong product" (pivot the concept), "wrong execution" (fix the loop), and "wrong audience" (change who you test with) — three very different conclusions that all beat building the full vision blind.
Can we use no-code tools for the MVP instead?
Sometimes, and we will say so when it fits: if the core loop can be tested with existing tools, that is the cheapest possible MVP. Custom development earns its place when the loop needs specific logic, branding, or integrations that no-code cannot express. The decision follows the test, not our preferences.
How long does an MVP build take?
It follows the core loop's complexity — simple transactional loops in weeks, multi-party loops in months. The honest answer comes from the scope document, not from this page: any fixed timeline quoted before the v1/later table exists is a guess.
Test the riskiest assumption first
The most expensive startup mistake is building the full vision before validating the core. An MVP engagement exists to prevent exactly that. Contact Tirupati Technologies to map your riskiest assumption and scope the smallest build that tests it.