MVP Development in 2026: What to Build and What to Cut

Why Fora Soft wrote this MVP playbook

Fora Soft has shipped software products since 2005 — more than 250 of them across video, AI, telehealth, e-learning, fitness, and social audio. Plenty were greenfield MVPs that became real businesses. Plenty were “MVPs” in name only that needed a firm scope conversation before we let them ship. Across 20 years of those conversations we’ve built a clear picture of what kills early products and what saves them. The patterns are depressingly consistent.

This article makes those patterns explicit. We cover what an MVP actually is in 2026 (it is not what it was in 2014), why “cut features” is a survival strategy rather than a slogan, the seven MVP shapes worth knowing, the scoping frameworks that hold up under pressure, realistic 2026 budgets with the arithmetic shown, and the most expensive mistakes we watch founders make. The deliverable is a checklist you can run this week, not theory.

Proof, if you want it. The early version of BrainCert went out as a focused virtual classroom and is now used by 100K+ customers running 500M+ classroom minutes. Perspire.tv launched with a single live-class workflow and grew into a multi-instructor streaming platform. CirrusMED shipped its first HIPAA-compliant telehealth slice with the one clinical workflow clinicians asked for most, then layered the rest. Every one of them scoped down before it scaled out.

What an MVP actually is in 2026

An MVP is the smallest version of a product that lets you learn whether a real user, one who pays in attention or money, will come back. Eric Ries put it precisely in The Lean Startup (2011): “the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.” The wording is old; the meaning has matured. In 2026 the weight sits on the word learning, not the word minimum. The product is the experiment. The features are the variables.

Figure 1. An MVP is one turn of a learning loop — the smallest build that produces a decision, not a smaller version of the finished product.

The 2026 update. The bar for “viable” has risen. With AI coding assistants, no-code platforms, and mature component libraries, a credible product is faster to build than ever — and users have absorbed that. They expect baseline quality from minute one, not three months in. A bare-bones MVP that crashes, hallucinates, or looks broken loses the second visit. That is why teams increasingly say Minimum Lovable Product (MLP): same scoping rigor, higher craft floor.

MVP vs prototype, PoC, pilot, beta and MLP

These terms get used interchangeably and it costs teams real money, because each one answers a different question and justifies a different budget. Here is the plain-language split.

The trap is building a beta when you needed an MVP. A beta assumes you have already decided the product is worth building; an MVP is how you earn that decision. A prototype and a PoC are cheaper still — if your riskiest question is “will the interaction feel right” or “can this even be built,” you do not need a product at all yet.

Why cutting features is the whole point

Because most features never earn their keep. The Standish Group’s much-cited 2002 study found that 7% of software features are always used and 13% often used, leaving 64% rarely or never touched. Pendo’s 2019 Feature Adoption Report put the unused share closer to 80%, with roughly 12% of features driving 80% of daily usage. The Standish sample was small, so treat the exact number with care; the direction has held for two decades across every later dataset.

Figure 2. Two decades apart, the same result: a small slice of features carries almost all the usage. Everything else is cost.

Now pair that with the other half of the evidence. “No market need” has sat at or near the top of CB Insights’ startup post-mortems for years: 42% and first place in their original 101-company study, 35% and second (behind running out of cash) in the 110-company update. Their 2024 analysis of 431 failed companies puts poor product-market fit at the top of the root causes, near 43%. Building features nobody asked for is the most efficient way to burn the cash you raised and find the market need too late.

Cutting early wins on four axes at once:

1. Cost. Every feature carries a build cost, a test cost, a support cost, and a maintenance cost. Five features in eight weeks is a fraction of the bill of fifteen in twenty-four — and the bill includes the long tail of a button you shipped two years ago that nobody can explain anymore.

2. Time-to-market. Faster shipping is faster learning, and faster learning is a faster pivot when you need one. Most startups die because they ran out of time to learn, not because they ran out of features.

3. Signal clarity. Ship five things and one gets loved, and you know exactly what to double down on. Ship fifteen and the heatmap is murky — each extra feature reduces the legibility of every other feature’s data.

4. Option value. Cutting now creates room to add later with real evidence. Building everything now creates a code base you have to defend, refactor, and re-explain to every new hire. The opportunity cost is what you will not learn because you spent the quarter shipping the wrong thing.

Five MVP origin stories worth re-reading

Pattern recognition beats worship. Each of these is a living example of one MVP shape, and each carries a lesson you can transfer to your own scope.

1. Airbnb (2008): the concierge MVP. Brian Chesky and Joe Gebbia photographed their apartment, posted three air-mattress listings, and personally hosted the first guests. They tested the riskiest assumption, whether strangers would pay to sleep on a mattress in someone’s living room, before writing a real product. The answer was yes; the product followed.

2. Dropbox (2008): the video MVP. Drew Houston shot a short screencast showing what file sync would feel like and posted it to Hacker News and Digg. The beta waiting list jumped from about 5,000 to 75,000 people overnight. No product shipped. The signal proved demand existed and that real customers were waiting at the end of the engineering.

3. Zappos (1999): the wizard-of-oz MVP. Nick Swinmurn photographed shoes in local stores, posted them online, and bought them at retail whenever someone ordered. He validated that people would buy shoes online before building any inventory or warehouse. Terrible unit economics for a month; a verified market thesis after.

4. Twitter (2006): the internal-tool MVP. Jack Dorsey, Noah Glass, Biz Stone, and Evan Williams built “twttr” as an internal SMS-broadcast toy while their podcasting startup, Odeo, was failing. The team noticed they were spending real money on SMS just to use it. That was the demand signal that pivoted Odeo into Twitter.

5. Instagram (2010): the cut-everything-else MVP. Burbn was a check-in app that tried to do too much. Kevin Systrom and Mike Krieger saw photos dwarf every other feature in usage, cut location, gaming, and check-ins, and kept photos plus filters plus a feed. The renamed app shipped in about eight weeks. Facebook bought it roughly eighteen months later for about a billion dollars.

Seven MVP shapes you should know in 2026

Not every MVP is “build a small version of the product.” The shape should match the riskiest assumption you are testing. Pick the wrong shape and you build the wrong evidence.

1. Landing-page / smoke-test MVP. A page describing the future product plus an email signup or a fake “Buy now” button. One to three days. Tests demand and messaging — right when nobody knows whether the problem is real or your wording lands.

2. Concierge MVP. Deliver the service manually, one customer at a time. One to two weeks plus ongoing labour. Tests the workflow and the pricing — right when the question is whether customers want the job done at all.

3. Wizard-of-Oz MVP. Looks automated; humans run every operation behind the screen. One to two weeks of setup. Tests the experience without paying for automation — right when the workflow is fixed but the automation is the expensive part.

4. Single-feature MVP. One core action, fully functional, polished enough to delight. Four to eight weeks. Right when the market is crowded and you need to be remembered.

5. Piecemeal MVP. Two or three tightly integrated workflows. Eight to twelve weeks. Right for B2B SaaS where the value lives in the integration between steps.

6. AI-wrapper MVP (newer in 2025–2026). A focused UX and prompt graph wrapped around a foundation model. Two to four weeks. Right for testing whether your specific use case justifies its own product before you commit to fine-tuning, evaluation infrastructure, or proprietary models.

7. No-code / low-code MVP. Bubble, Webflow, Glide, Softr, Make, Zapier. Four to eight weeks. Right for testing functionality and demand without custom code, then porting to a real stack once the hypothesis holds. Materially cheaper to start, with the honest tradeoff that scaling past product-market fit usually means a rebuild.

MVP shapes compared — pick the one that fits your hypothesis

A condensed view of when each shape fits, what it costs in time, and what it actually tells you.

A scoping framework — what to keep, what to cut

The scoping conversation is the most expensive hour of the project. Run it well and it saves three months; run it badly and it costs you six. Pick the framework your team will actually use.

MoSCoW. Must, Should, Could, Won’t. Fast and team-aligning — best when you agree on the goal but argue about order. The risk: every feature wants to be a Must.

RICE (Reach, Impact, Confidence, Effort). Numerical scoring, popularized by Intercom. Best when you have a roadmap and competing items. The risk is false precision — the score is only as good as its inputs.

Kano model. Separates basics, performance features, and delighters. Best for UX-driven products where emotional response matters. It tells you what people care about, not what to cut.

Value vs. effort 2×2. Plot value against cost; do high-value, low-effort first. Best for visual alignment in a 30-minute meeting. Most teams under-estimate effort and over-estimate value, so calibrate against past projects.

Riskiest Assumption Test (RAT). The one we reach for most. Ask: what single assumption, if wrong, makes this whole product irrelevant? Build only what tests that. The MVP is the answer; everything else is postponed by default. RAT cuts harder than MoSCoW and forces clearer thinking than RICE.

A decision framework — which MVP shape in five questions

Which shape fits? Answer these five questions in order and the shape usually names itself. The tree below walks the same logic top to bottom.

Figure 3. Start at your riskiest assumption and follow the branches. Each question rules out shapes until one is left.

Q1. Is the risk that nobody wants this at all? If you are not yet sure the problem is real, do not build. Ship a landing-page or smoke-test MVP and measure signups or pre-orders first.

Q2. Is the risk in the workflow, not the code? If the open question is whether people want the job done at all, regardless of automation, run a concierge or wizard-of-oz MVP and deliver it by hand behind the screen.

Q3. Is one feature the entire value? If a single action is the reason to come back, build a single-feature MVP and polish that one flow until it delights. Everything adjacent waits.

Q4. Does the value live in the integration between steps? If the product is only useful when two or three workflows connect (typical for B2B SaaS), scope a piecemeal MVP around that seam.

Q5. Is the differentiator a model, or the speed of shipping? If it is “this model, this prompt, this niche,” build an AI-wrapper. If you just need something functional this month and expect a rebuild later, go no-code. If it must scale into a serious product within 6–9 months, or carries regulated or real-time workloads, start on custom code.

What an MVP actually costs — a worked example

Ranges are easy to quote and easy to distrust, so here is the arithmetic on a concrete case: a two-sided marketplace MVP with six core features. Estimate each feature in engineer-weeks, sum, convert to hours, apply a blended rate, then add overhead. The rate below is an illustrative mid-market blend; swap in yours.

Step 1. Scope in engineer-weeks. Auth and profiles 2, listing create/edit 3, search and browse 2, booking and checkout 3, messaging 2, admin plus instrumentation 2. Total: 14 engineer-weeks.

Step 2. Convert to hours. 14 engineer-weeks × 40 hours = 560 hours. Two engineers working in parallel put that at roughly 7 calendar weeks.

Step 3. Apply a rate. 560 hours × $75/hour = $42,000 for the build.

Step 4. Add real overhead. Hosting, third-party integrations, and one post-launch iteration cycle add 20–40%. At 25% that is roughly $52,500 all-in.

Figure 4. The same six-feature scope, two ways: a standard build versus one compressed by Agent Engineering. The arithmetic, not a range.

The Agent Engineering effect. Roughly 60% of that scope is routine scaffolding: CRUD, auth, forms, wiring. AI-assisted delivery trims about 30–40% off that portion, which lands near a 20% cut on the whole: about 450 hours, roughly $33,750 to build and about $42,000 all-in. That drops this MVP below the 2026 “sweet spot” benchmark of $45,000–$90,000 that agency surveys report for a professional, investable build. We hold our estimates conservative: when a number is in doubt, we do not publish it.

Realistic budgets and timelines in 2026

Zoom out from one worked example to the ranges we use as sanity checks. These track the 2026 agency surveys; your real number lands on the curve based on complexity, regulatory load, and how much you insist on shipping at MLP polish.

Simple SaaS MVP. Landing page plus a single core workflow. Roughly 5–8 weeks, about $15,000–$30,000. Right for testing whether anyone buys the workflow at all.

Standard B2B SaaS MVP. A couple of integrations, basic admin, role-based access. Roughly 8–14 weeks, the $45,000–$90,000 “sweet spot” most investable builds land in.

AI-powered MVP. LLM features built in — chatbot, agent, copilot. Roughly 12–18 weeks, about $70,000–$120,000+. The width reflects how much grounding, evaluation, and guardrail work you take on.

Regulated MVP (telehealth, fintech). Compliance posture, audit log, encrypted storage, data residency. Roughly 16–24 weeks, routinely $150,000+. Skip the cheap-end quotes — they blow up at audit. And budget the hidden 20–40% for hosting, integrations, and iteration on every tier above.

Pick the right build path — custom, no-code, or AI-wrapper

Shape and build path are two decisions. You can ship a single-feature MVP on no-code, a piecemeal MVP on a custom stack, or an AI-wrapper on a thin front-end with a vector store. Pick the path that minimises waste based on what comes after product-market fit.

Ship less, learn more — why signal beats surface area

The strongest argument for cutting is not cost, it is legibility. A lean launch produces a clean signal; a bloated one produces noise you pay to collect. Same runway, opposite outcomes.

Figure 5. Left: fifteen features, half a year, and no idea what drove retention. Right: five features, eight weeks, one obvious winner to double down on.

On the left, fifteen features ship in twenty-four weeks. Retention wobbles and the team cannot say which feature caused it, so the next quarter is a guess. On the right, five features ship in eight weeks; one is clearly loved, and the roadmap writes itself. The lean team has spent a third of the money and learned three times as much — and still has runway to place the next bet.

Mini case — how Fora Soft cuts scope without cutting value

Proof of pattern, not a pitch. Each of these launched as an MVP and became a real product.

Perspire.tv: one workflow, polished hard. The first cut focused on a single live-class flow: an instructor goes live, members join, the instructor sees and corrects form in near real time. We deliberately cut the on-demand catalogue, the recommendation engine, and the discovery feed. Those came later, once the live-class workflow proved it could hold weekly users. One feature done well beat ten done adequately.

BrainCert: the riskiest assumption was “will teachers use a virtual classroom.” The MVP focused on the classroom itself (whiteboard, screen share, recording) and skipped the marketplace, the certificate engine, and the public API. The first paying institution validated the workflow; the rest of the platform layered in over the following year. It now serves 100K+ customers and 500M+ classroom minutes.

CirrusMED: the regulated MVP. Compliance is not optional in telehealth, so we did not cut it. We cut everything else: onboarding to one workflow, scheduling to a single slot template, analytics to one dashboard. The MVP shipped HIPAA-compliant from day one with the smallest defensible feature set, and the practice runs on it today.

Each of those teams opened with “we need everything.” We asked which one user and which one workflow they could not ship without, and the rest became a phase-2 backlog that turned into a real roadmap once usage data arrived. Want to run that conversation on your product?

Five pitfalls that turn an MVP into a misfire

1. Scope creep dressed up as “just one more feature.” Each addition feels small; the cumulative effect is a launch six months late on a brittle code base with no learning. Fix: hard time-box of 6–12 weeks. When time is fixed, scope becomes the variable, and “just one more” gets the answer it deserves.

2. Polishing the wrong layer. Three weeks on the dark-mode toggle while the core workflow has no analytics. Polish belongs on the one or two flows that prove the riskiest assumption; everything else can wait. Use a component library so you do not pay the UI tax twice.

3. Building for “all users.” SMB plus enterprise plus freelancer plus non-profit yields feature bloat, diluted messaging, and no traction. Pick one persona, exclude the rest, expand in phase 2 with evidence.

4. No instrumentation from day one. Activation, retention, and feature adoption tracked from launch, not “added later.” You cannot iterate on data you never captured. Mixpanel, PostHog, and Amplitude are all set-up-in-a-day options — pick one before launch, not after.

5. Treating the MVP as v1. The most expensive mistake: build, ship, declare victory, and pour follow-on cash into scaling before you know the product works. Plan three iteration cycles after launch, and plan to rewrite 30–50% of the MVP code based on what you learn.

KPIs that tell you the MVP is working

Three buckets. Vanity metrics (downloads, signups, page views) are early demand evidence at best, not MVP success.

Activation. The share of signups that complete the core action — post a listing, send a first message, finish onboarding. A healthy floor is around 20%, with the top decile past 40%. Below 10% and you have an onboarding or value-prop problem; fix that before anything else.

Retention and product-market fit. Day-7 retention is the early read (sustainable products often hold 20–30%+); Day-30 is the lagging confirmation. Pair it with Sean Ellis’s test — if at least 40% of users would be “very disappointed” to lose the product, you are near fit. A retention cliff at Day-2 is a broken core loop.

Time to value and willingness to pay. Minutes from signup to the first “aha” — aim under 15 for self-serve; past 24 hours you bleed users to setup friction. And measure intent: even a pre-revenue MVP can run a “would you pay $X/month” test that separates curiosity from a real buyer. Add five user interviews per cycle for the “why” the dashboards never show.

When NOT to scope down — the cases for a fuller first launch

An MVP is not always the right answer. Three situations where a thin slice will hurt you.

1. Regulated industries with all-or-nothing compliance. Healthcare PHI, financial data, and EU-resident PII do not allow a half-built version — you either pass the audit or you do not. Cut features inside the compliance envelope; never cut compliance to ship faster.

2. Network-effect products with a critical-mass requirement. A two-sided marketplace that needs both sides, real-time multiplayer that fails below four players, a chat product where being alone is the same as being broken. The MVP must include enough scaffolding for the network to form, not one user with no peers.

3. Established markets where polish is the moat. Enter a saturated category on craft and your MVP is your reputation. Shipping rough code to discriminating buyers is damage you cannot reverse. The move is a smaller scope at higher craft — the MLP framing again.

What to look for in an MVP development partner

1. Shipped MVPs in your category — not just “done MVPs.” A partner who has launched five video products knows which features a video MVP can cut. The same team is risky on a fintech MVP. Match the portfolio to your problem.

2. Will say “cut that.” The right partner pushes back on the wrong features; the wrong one agrees with everything and bills you for it. In your first scoping call, count how often they say “we’d skip that for the MVP.” That is the signal.

3. Owns instrumentation, not just features. A partner who scopes activation, retention, and event tracking from week one is building the data you will need in week ten. One who treats analytics as phase 2 is handing you a black box you cannot iterate on.

4. Has a real iteration cadence. Two-week sprints with a working build at the end of each, and a demo you can show a customer or investor. The right partner ships weekly; the wrong one disappears for six weeks and returns with a tarball. See how we structure that in our engineering playbooks and our custom software development practice.

5. Has a credible take on AI tooling. Agent Engineering and AI-assisted delivery are how productive teams ship faster in 2026, which is part of why our estimates beat 2020 benchmarks. A partner without an opinion on AI tooling is billing 2020 hours for 2026 work. See our AI integration practice.

Frequently asked questions

What does MVP stand for?

Minimum Viable Product. The term was coined by Frank Robinson (2001) and popularised by Steve Blank and Eric Ries. The literal words matter less than the spirit: minimum effort, viable enough to test a hypothesis, and structured as a product so you collect real-user data.

How long does MVP development take in 2026?

Most well-scoped MVPs ship in 6–12 weeks; a landing-page or video MVP can ship in days. A regulated MVP (telehealth, fintech) runs 16–24 weeks because compliance is non-negotiable. If a partner quotes 4–6 months for a “simple” MVP with no regulation, they are over-scoping — ask which features they would cut.

How much does MVP development cost?

Rough 2026 benchmarks: simple SaaS $15,000–$30,000; standard B2B SaaS $45,000–$90,000; AI-powered $70,000–$120,000+; regulated $150,000+. Add 20–40% for hosting, integrations, and iteration. Your real number depends on regulation, polish target, and how much no-code and AI tooling the team uses.

What is the difference between an MVP and an MLP?

An MVP (Minimum Viable Product) is the smallest thing that tests a hypothesis. An MLP (Minimum Lovable Product) keeps the same scoping discipline but raises the craft floor so the small thing delights, not just functions. In 2026, MLP framing fits most consumer products; MVP framing still fits B2B tools and internal pilots where utility beats emotional response.

Can I build an MVP without code?

Often, yes. Webflow, Airtable, and Zapier can deliver a credible MVP for forms, dashboards, and content in 4–8 weeks; Bubble handles two-sided marketplaces; Glide ships data tools fast. No-code is cheaper to start, with the honest tradeoff that scaling past product-market fit usually needs a rebuild. The play is no-code first, custom rebuild after the hypothesis holds.

How do I know which features to cut from my MVP?

Start with the Riskiest Assumption Test: name the single belief that, if wrong, makes the product irrelevant, and build only what tests it. Everything else is “phase 2 unless proven otherwise.” MoSCoW, RICE, and Kano are useful supports, but RAT is the cut tool — it forces a yes/no on every feature.

What metrics define MVP success?

Activation (target 20–40%+), Day-7 and Day-30 retention, time to first value (under 15 minutes for self-serve), and a willingness-to-pay signal such as a paid conversion or pre-order test. Add five qualitative interviews per cycle. Downloads and signups are demand evidence, not success.

Should I throw away the MVP code if it works?

Often, partially, yes. Plan to refactor or rewrite 30–50% of the MVP code in the months after launch as you learn what users actually do. The pieces that survive are the ones backed by evidence. Treating the MVP as the permanent foundation means defending early guesses with thin data — technical debt with no offsetting learning.

What to Read Next

Ready to scope your MVP?

An MVP is a learning instrument. The features you cut are the experiments you save; the features you keep are the ones you bet your runway on. In 2026 the build is faster than ever, with AI tooling, no-code, and mature component libraries, but the discipline to cut is the same as it was in 2011. Pick the riskiest assumption, pick the shape that tests it, set a hard time-box, instrument from day one, and plan three iteration cycles after launch.

If you want a partner that says “cut that” early and “let’s ship that one polished” often, that is the conversation we have every week. The most useful next step is a 30-minute scoping call — bring your hypothesis, your audience, and your one-line goal, and we’ll come back with a cut list, a build path, and a calibrated 2026 timeline.