How to Plan an MVP That Proves Your Idea

Treat the MVP as an experiment with a deadline

A minimum viable product is not the full app with features removed. It is the smallest release that tells you whether a specific belief about your market is true. Founders who skip that framing tend to ship a thin version of every roadmap item, then cannot tell which part worked. Tepia asks one question before anything else: what has to be true for this business to work, and how will we know within a few months?

Good answers are specific. Clinic managers will send patients a link, and at least half will finish it before arrival. Contractors will post a job and accept a bid within a day. Office teams will reorder supplies from a phone instead of by email. Each names a user, an action and a threshold, which makes the MVP testable.

The plan then works backward from that test to the fewest screens, integrations and back office tools needed to run it. Tepia keeps that test visible on every planning document, so when a new feature request arrives the team can ask one question: does this help us learn the answer sooner?

Steps to plan an MVP

1. Write the riskiest assumption. Rank your assumptions about demand, willingness to switch, supply and operations, and pick the one that would end the business if it were false.
2. Define the core job and success metric. One user, one job, one number. For a marketplace that might be completed bookings per week; for an internal tool, orders placed without a phone call. Set the threshold before launch so nobody reinterprets results afterward.
3. Cut scope with a now and later list. Every feature must serve the core job or its measurement. Settings screens, referral programs and full dashboards usually move to later.
4. Decide what to do by hand. A concierge MVP lets staff handle matching, approvals or support manually behind a simple interface. Tepia often builds a basic admin panel instead of automation so a person can run operations for the first few hundred users.
5. Choose platforms. If users are on both iOS and Android, React Native or Flutter gives one codebase. If the job happens at a desk, a responsive web app may test the idea faster and skip store review entirely.
6. Instrument before launch. Define the events that prove the metric, such as signup, first core action and repeat action, and wire analytics before the first user arrives.
7. Plan the test cohort. Recruit early users in advance. TestFlight handles external testers on iOS, and Google Play requires new personal developer accounts to run a closed test before production.
8. Set the decision date. Agree when you will review results and what each outcome means: expand, change direction or stop.

Weak versus strong MVP plans

Tepia uses a comparison like this in Discovery to pressure test a plan before design starts.

The strong column reads narrow on purpose. A narrow MVP that clearly passes or fails teaches more than a broad one that produces ambiguous data.

How Tepia approaches MVP planning

Tepia runs MVPs through the same six phases as larger builds, compressed and focused on the test. Arriving with research, designs or a requirements document shortens Discovery.

1. Discovery: an assumption workshop, interviews with five to ten target users, and a check of any third party APIs the MVP depends on. Deliverables are an Investigation Summary, an Interview Summary and User Stories limited to the core job, plus a written success threshold.
2. Design: a design questionnaire, moodboards and a light style guide, then wireframes for only the screens the core job needs. Clickable prototypes can go in front of users before any code.
3. Development and Testing: an Alpha for your team and a Beta for the recruited cohort through TestFlight and Google Play testing tracks. Test plans focus on the core path, analytics events and crash free sessions.
4. Training: a session for whoever runs the manual back office, with scenarios drawn from the user stories.
5. Launch: store submission, analytics dashboards live on day one, and support reps watching early sessions.
6. Support: bug fixes and a results review against the threshold, then a ranked list for the next release.

A focused MVP often lands near the short end of Tepia’s usual ranges: Discovery 1 to 3 months, development and QA 2 to 6 months, launch about a month. See our process.

What to do after the MVP ships

The first weeks after launch are for reading data, not adding features. Tepia reviews the funnel with you: how many users reached the core action, how many repeated it, and where the rest dropped off. Session recordings and a handful of follow up interviews usually explain the numbers.

Then make the call you agreed to make. If the threshold was met, the next release replaces manual steps with automation and adds the features that kept coming up in interviews. If it missed, decide whether the job, the user or the channel was wrong before writing more code. Tepia’s app evolution consulting exists for exactly this stage.

More reading: MVP app development, how to write an app requirements document, marketplace MVPs and digital health MVPs. Talk to Tepia about your idea.

Frequently asked questions