How long does it take to build an MVP? Eight startups, eight real timelines

A real MVP takes between three weeks and three months of pure development effort. Most well-scoped MVPs land in a focused six-to-ten-week window with a small team, and calendar time runs ten to thirty per cent longer once review cycles, refinements, and content prep are folded in.

Two practical price points are worth anchoring against: an MVP built on ready-made tools (Flutter with Firebase and FireCMS, for example) lands at roughly $15K–$25K, and an MVP built on a custom backend (PHP Laravel, Node.js, or a Cloudflare-style purpose-built stack) lands at roughly $30K–$50K. Both are valid starting points. Which one is right for you depends on what your product actually needs to do, not on which is cheaper on paper.

The same kind of choice exists on the mobile side. Cross-platform — Flutter or React Native — is the cheapest path when the product fits cleanly inside it. Native iOS and native Android become the right call when the product needs a perfect, distinctly native UI (fashion, beauty, lifestyle, meditation, premium content) or deep system access (Bluetooth, ARKit, accelerometer at high frequency, advanced camera control, CarPlay).

If your back-of-the-envelope number is materially higher than the bands above, the scope hasn’t been sliced into a real MVP yet. Stack choice and scope discipline are the two biggest levers on cost. AI tools accelerate the repeatable parts of a build — CRUD screens, scaffolding, tests — but they don’t speed up the decisions that determine whether your MVP can be extended later.

 The eight projects we’ll walk through are published case studies, built between 2018 and 2025 — mostly before AI was deeply leveraged in our development workflow. With AI-curated development in the loop today, the repeatable parts of a similar build move twenty to thirty-five per cent faster. Architectural and product decisions still take roughly the same time, because they should.

This guide pulls eight real timelines from MVPs we’ve shipped, breaks down where the hours actually go using ratios from our internal estimation methodology, and shows you how to estimate your own.

Article content

What counts as an MVP, and why “how long” is the wrong first question?

Eight MVPs, eight timelines

The eight-timeline summary

What actually moves the needle on MVP cost

How to estimate your own MVP timeline

What this looks like in practice

FAQ

What counts as an MVP, and why “how long” is the wrong first question?

An MVP — minimum viable product — is the smallest version of your idea that lets a real user do the one thing your product promises. It is not a prototype, not a clickable demo, and not “everything we hope to ship in version 1.” If you’d like the longer version of this argument, our companion piece on how to build an MVP for a startup before expanding into a full-scale product walks through it in detail.

Before you ask how long an MVP takes, three questions need clear answers. First: What is the single-core action? Second: Which platforms does that action need to live on? Mobile-only is fastest; mobile plus a web companion adds thirty to sixty per cent. Third: what proves the MVP worked? Downloads, paying users, retention, signed letters of intent — pick one before writing a line of code.

Skipping these three turns a six-week MVP into a six-month rebuild. Every time.

Eight MVPs, eight timelines

Each of the eight projects below is a published NERDZ LAB case study. The timelines reflect pure engineering effort — the focused development time that actually shaped the product. Calendar time was typically longer, since real projects include client review cycles, content preparation, and refinement rounds between sprints.

1. inHype — livestream shopping MVP in roughly 3 weeks

inHype: e-commerce MVP development

Industry: eCommerce / livestream shopping
Stack: Swift, Twilio Programmable Chat, Stripe, Streamaxia
Team:iOS dev, backend dev, QA engineer, PM (4 people)
Outcome: Live in App Store, 8,500+ downloads, investor-ready demo

How a complex MVP was shipped in around three weeks: by refusing to invent. The team picked existing libraries for live video and chat, scoped the product around a single moment — a livestream sale — and skipped anything that didn’t directly serve that moment. Three weeks is close to the floor, not the average. It’s only achievable when the product hypothesis is razor-narrow.

2. Ayadi — telehealth platform rescued in roughly 2 months

Ayadi: MVP for a teletherapy platform

Industry: Healthcare / mental health (Kuwait, GCC)
Stack: Kotlin, Swift, Vue.js, PHP Laravel
Team: iOS, Android, frontend, backend, QA, delivery, PM, fractional CTO (8 people)
Outcome: First teletherapy platform in GCC; 4 mobile apps + web shipped together

Ayadi is the cost of starting wrong. The original codebase was unfit for production; a code review and partial refactor preceded the rebuild. With the right architecture in place, a five-product launch — including HIPAA-grade compliance and right-to-left Arabic — became a roughly two-month effort. The lesson is unkind but worth absorbing: how you start determines how fast you can move later.

3. NFT Pro+ — marketplace MVP in 6 weeks

NFT Pro+: A tech-savvy blockchain-based MVP for the NFT marketplace

Industry: Blockchain / NFT
Stack: PHP Laravel, Kotlin, Node.js, Web3, IAP
Team: iOS dev, backend dev, QA, delivery, PM (5 people)
Outcome: Functional blockchain MVP on schedule; stable OpenSea integration

A hard external constraint — OpenSea API rate limits — forced an architectural decision in week one (a Node.js bridge service). Made early, that decision cost two days. Made in week five, it would have cost two weeks. Architecture choices compound; deferring them is rarely free.

4. Spirit of Math — contest scoring platform in roughly 7–8 weeks

Spirit of Math: a test scanning app for an international math contest

Industry: EdTech / math competitions (grades 1–4, global)
Stack: Swift, React JS, Java, C++, OpenCV (machine vision)
Team: iOS, Android, frontend, QA, PM (5 people)
Outcome: Test sheets scanned in 0.2 seconds, accurate under poor scan conditions

Seven to eight weeks is fast for a product with a custom OpenCV pipeline. It worked because the team didn’t try to make every part of the system clever — just the part that had to be (the scanning algorithm). Everything else was conventional.

5. Blank AI — personalised AI assistant in 3 months

Blank AI app: An AI-driven coach, companion, and personal assistant in one

Industry: AI/productivity
Stack: Swift (native iOS), PHP Laravel, vector database, AWS, Google Cloud
Team: 2 iOS devs, backend, QA, delivery, PM, architecture consultant (7 people)
Outcome: Functional MVP in 3 months; multiple revenue streams active at launch

The AI parts — LLM integration, vector search, voice I/O — were the easy parts. They’re well-trodden patterns at this point. The hard part was the native iOS animation engine and the in-app purchase logic that gates premium features. That’s the pattern across our AI development work: the AI itself is rarely the bottleneck.

6. MedPod — medical education app, 4–6 weeks of pure development

MedPod: A medical education platform built for clinicians and students

Industry: Healthcare / EdTech (doctor-led startup)
Stack: Flutter, Firebase (Firestore, Cloud Functions), FireCMS, IAP, Google Payments
Team: UI/UX designer, Flutter dev, QA, delivery, fractional CTO (5 people)
Outcome: MVP on iOS + Android, in budget; rapid lesson deployment

A doctor-founder with a tight budget. The team chose Flutter to ship a single codebase across iOS and Android, and Firebase to skip months of backend infrastructure setup. The pure development effort took four to six weeks; the rest of the calendar was filled with content review, refinement rounds, and the natural delays of working with a busy clinical founder. Same scope on a custom backend would have doubled the engineering effort. Stack choice is a budget decision before it is a technology decision.

7. Runners High — music running app, roughly 6 weeks of pure development

Runners high: Run your best with the ultimate music app

Industry: Fitness/music (Netherlands)
Stack: Swift + UIKit, Firebase, RevenueCat, branch.io, FireCMS
Team: iOS dev, QA, delivery, PM, fractional CTO, architecture consultant (6 people)
Outcome: On-time launch before a major event; freemium model expanded revenue

The calendar timeline read longer because of feedback loops and content prep, but the engineering effort itself was around six weeks for an iOS-only freemium app that included subscription paywalls, music sync, deep-linking attribution, a content management layer, and a “wow factor” UI tied to a hard external launch date. The architecture consultant on the team isn’t a luxury — it’s why the product still scales today, and why a senior reviewer alongside the implementation work kept the pure-dev count tight.

8. Baza — mental health app, up to 8 weeks of pure development

База: An SaaS teletherapy platform for helping post-combatants and veterans in Ukraine

Industry: Healthcare / mental health (Ukraine, NGO)
Stack: Figma, PHP Laravel, Kotlin, Swift, AWS
Team: designer, iOS, Android, backend, QA, delivery, PM (7 people)
Outcome: #1 on App Store free chart within 1 month of launch; 10,000+ daily active users

An MVP that hit number one on the App Store in its first month, on roughly eight weeks of pure engineering effort. Two factors mattered. The first was the offline-first design — post-combatant users couldn’t depend on stable connectivity. The second was a calm, restrained UI built specifically for users in crisis. Scope discipline beat feature volume.

The eight-timeline summary

The timelines below are pure development effort, not calendar time. Calendar time is usually longer once client review cycles, content preparation, and refinement rounds are included.

The median pure-dev timeline is about six to seven weeks; the median team is six people; and the most common pattern is a mobile-first product on a managed backend. Worth remembering: these projects were built largely without modern AI assistance. With AI in the loop today, similar scopes typically compress by twenty to thirty-five per cent.

Where the hours actually go

We use a fixed set of ratios across every MVP estimate. They’re calibrated against more than two hundred shipped products, and they’re not negotiable. Cutting any of them is how teams ship something that “works in demo” and falls over in week three of real use.

The design budget is:

• 40% of frontend (mobile + web) hours. A product without design isn’t an MVP, it’s a prototype, so we size design as a fixed proportion of UI work — if it can be silently cut, it will be.
• QA runs at 20% of net development hours, because every feature needs to be tested by someone who didn’t write it.
• Project management is 15% of (development + QA) hours: coordinating a five-to-seven-person team through a six-to-twelve-week build is real work, not overhead.
• Business analysis runs 40 to 80 hours per MVP, covering discovery and technical specification before development starts; skipping it is the most reliable way to add thirty per cent to your final bill.
• And the risk buffer is 10% of the total, reserved for unknowns. We strip it out only when the client explicitly trades it for stricter scope discipline.

A real example from a recent NERDZ LAB MVP estimate — single-platform Flutter + Firebase MVP, midpoint rates:

Total cost (midpoint rates) – $16.7K–$29K

Across larger MVPs we add a Designer (40% of frontend hours), a Business Analyst (40 to 80 hours), and a 10% risk buffer. The pattern that surprises founders most: only about half of an MVP’s hours are spent writing the feature code that is the product. The rest — design, QA, PM, BA, infrastructure, security rules — is what makes those features ship and stay shipped.

What actually moves the needle on MVP cost

Two decisions, made before development starts, are responsible for most of the difference between a $15K MVP and a $50K MVP. They aren’t glamorous. They’re stack choice and scope discipline.

Lever 1 — stack choice

Stack choice has two sides. The first is the backend: ready-made tools versus custom infrastructure. The second is the mobile platform: cross-platform versus native iOS / native Android. Both are decisions, not defaults. The right pick on each side depends on what your product needs to do, not which option is cheaper on paper.

• Backend: ready-made tools versus custom infrastructure

Ready-made tools — Firebase, Supabase, FireCMS, similar managed platforms — ship with auth, real-time sync, offline storage, push, and admin scaffolding already built. You configure them rather than build them. The upside is speed and lower cost. The downside is flexibility: you live inside the tool’s data model, its query patterns, its pricing curve, and its limits. When your product fits cleanly inside those constraints, ready-made tools are a powerful accelerator. When it doesn’t, fighting the tool gets expensive — and at some point, custom infrastructure becomes the cheaper option.

Custom backends — PHP Laravel, Node.js / NestJS, Python, Cloudflare-style purpose-built stacks — start more expensive because you’re building infrastructure from scratch. The upside is full control over your data, your queries, your performance characteristics, and your scaling path. The downside is that everything that ready-made tools give you for free has to be built and maintained. When the product has unusual data models, hard performance ceilings, regulatory constraints that need bespoke handling, or a roadmap that obviously outgrows managed-tool defaults, custom is the right call from day one.

This article isn’t a deep dive on when to choose Firebase versus a custom backend — for that, our existing piece Firebase vs Back-end covers the technical tradeoffs in detail. What follows is just the cost shape, so you can see how big the lever is.

When we’ve internally estimated the same MVP scope two different ways — once on a custom backend, once on Firebase — the Firebase version routinely comes in around twenty-five to thirty-five per cent lighter on engineering hours, with proportionally lower cost. The savings come from concrete, measurable places: Firestore’s offline SDK replaces a custom offline layer, real-time listeners replace WebSocket infrastructure, security rules replace custom auth middleware, and FireCMS handles most admin-panel CRUD without custom UI work.

The takeaway isn’t “always pick the cheaper option.” It’s that backend choice is a 25–35% lever on the bill, and the right way to spend it is to match the backend to what your product actually needs. If your product fits inside ready-made tool defaults, take the speed and ship. If your product has clear reasons to go custom — performance, data control, compliance, an obvious scaling path — pay for the flexibility on day one rather than rebuild on day ninety.

• Mobile: cross-platform versus native iOS / native Android

The same logic applies to the mobile side, with different tradeoffs.

Cross-platform (Flutter, React Native) lets one codebase target both iOS and Android. For most product categories — productivity, marketplaces, B2B tools, content apps, basic e-commerce, simple healthcare — Flutter ships roughly forty to fifty per cent cheaper than building two native apps in parallel, and the user experience is indistinguishable from native to most users. Most of the MVPs in this article were built in Flutter or React Native because that tradeoff is overwhelmingly favourable when the product fits.

Native iOS (Swift / SwiftUI) and native Android (Kotlin) are the right choice when one of three conditions is true. The first is when the product needs a perfect, distinctly native UI — fashion, beauty, lifestyle, meditation, premium content — anything where the visual polish is the product. Cross-platform can get close, but the last ten per cent of fidelity (gestures that feel like the OS, animations that match Apple’s or Google’s design language exactly, motion that doesn’t feel “almost right“) usually requires native.

The second is when the product integrates deeply with device hardware or system APIs — Bluetooth Low Energy, low-level network monitoring, accelerometer or gyroscope at high frequency, AR/ARKit/ARCore, advanced camera control, CarPlay or Android Auto, watch companions, custom keyboards, background location at full fidelity. Cross-platform plugins exist for some of these, but they lag behind the native APIs and frequently break with OS updates.

For products where the hardware integration is the product, native is the safer floor. The third is when the product has a long roadmap of platform-specific features — Live Activities, Dynamic Island, App Clips, deep iOS-specific or Android-specific integrations. Cross-platform makes these expensive; native makes them straightforward.

Among NERDZ LAB MVPs, this is the split we see in practice. Cross-platform Flutter served products like MedPod (medical education) and Tablebud (restaurant social). Native iOS (Swift/UIKit) was the right call for Runners High (high-fidelity fitness UX, music sync, Apple-platform features) and Blank AI (custom animation engine, distinctive native experience). Native Android served OnForm’s coaching analysis tool, where deep video processing and frame-by-frame controls demanded full platform access.

The cost shape is straightforward. A single-platform native MVP runs roughly the same hours as a single-platform Flutter MVP. The split appears when you need both platforms — Flutter is roughly one team building one app, while native iOS plus native Android is roughly two teams building two apps with shared design and a shared backend. That’s the lever. Our mobile app development services page outlines how we structure each path.

A deeper piece on when to choose native versus cross-platform — with the product, hardware, and roadmap criteria laid out properly — is also a separate article we’ll publish.

• Putting both sides together

Either way, the most expensive mistake is making the choice by accident. A short focused discovery phase — typically sixteen to forty hours of business analyst time — is usually enough to turn both backend and mobile decisions into deliberate ones. Our MVP development services page walks through how we structure each path.

Lever 2 — scope discipline: a true lean MVP

A disciplined “lean” MVP is the cheapest way to put a real product in front of real users. Two recent NERDZ LAB lean MVP estimates make the point:

What gets cut in a lean MVP is deliberate: gamification (tiers, streaks, achievements), fraud detection, custom rule editors, multi-role admin, secondary auth methods, in-app banners, advanced filters, calendar export, and automated CI/CD. What stays is also deliberate: auth, the one core flow, the smallest admin surface that lets the team operate, and analytics.

A lean MVP isn’t a worse product. It’s a faster, cheaper test of whether the thing you’re betting on actually works. The fuller scope is what you build after the lean version proves the concept.

Where AI fits in

AI-curated development accelerates the repeatable parts of a build — scaffolding, CRUD screens, basic tests, well-documented integrations, static pages. Across a typical MVP, that’s a twenty to thirty-five per cent reduction in implementation hours for those parts of the work. AI doesn’t speed up the decisions: data model, module boundaries, security model, what to leave out. Those still take roughly the same time as before, because they should. For the specifics — the tools we run, how we run them, and the daily practices our engineering team applies — see our CTO’s piece on how we use AI across our development workflow.

The maths comes out clean. AI is a meaningful efficiency on the second-largest cost in your MVP (engineering time). Stack choice and scope discipline are levers on the largest cost, total hours of work needed in the first place. Pull those two first.

The structuring problem — why a “fast” MVP can become an expensive one

Your MVP is the ground state of the product. Every decision — schema design, module boundaries, where state lives, how you authenticate, whether you have a queue — quietly sets the ceiling on how easy it will be to extend later.

Done well, an MVP is a foundation. Done badly, it’s an obstacle that needs to be removed before you can build anything new on top.

We’ve inherited both kinds. The ones built well get a Stage 2 estimate that adds features in days. The ones built badly get a Stage 2 estimate that starts with “rewrite the auth layer, repair the data model, then add features.” The second estimate is usually two to three times the first.

Two practical signs you’re getting structuring right at the MVP stage. First: a new developer can ship a small feature on day three. That means the codebase is legible, modules are bounded, and the dev environment is reproducible. Second: adding a second user role doesn’t require rewriting the first one. That means permissions and data ownership were modelled, not retrofitted. If neither is true, you don’t have an MVP — you have a prototype dressed up as one.

Vibe coding versus AI-curated development — and why the difference matters at the MVP stage

“Vibe coding” — generating code from prompts without engineering review — is the fastest way to get something on screen. It’s also one of the most reliable ways to ship technical debt that a Stage 2 effort has to pay off before it can do anything else.

We rebuilt a fintech platform’s frontend earlier this year after the founders discovered the vibe-style code underneath had become impossible to extend. The product worked. The team couldn’t move. Public case study, real outcome — the rewrite cost roughly what a careful original build would have.

The difference, plainly:

The middle path — AI in the loop, a senior engineer in the chair — is what we use across every MVP we ship today. AI handles the parts where speed pays off. Humans handle the parts where speed doesn’t.

For a deeper look at how we approach this, our MVP development services page breaks down the process, and the discovery phase is where most of these structural decisions get locked in.

How to estimate your own MVP timeline

A workable rough estimate of pure development effort before a full discovery phase. The numbers below assume a single-platform mobile MVP built cross-platform (Flutter or React Native) with ready-made backend tools (e.g. Firebase + FireCMS) and AI-curated development in the loop. Two adjustments handle the most common stack changes — one for backend, one for mobile.

1. Start at 450 hours / 6 weeks with ready-made tools. That’s roughly where a single-platform cross-platform lean MVP lands — auth, one core flow, basic admin, push notifications, analytics. Expect ~$15K–$25K at midpoint rates.
2. Add 120–240 hours for each major feature module. Wallet/transactions, content marketplace, scheduling, video processing, payments, and real-time chat — each is roughly 1.5–3 weeks of work.
3. Add 40–120 hours for a web companion or admin beyond FireCMS. If your admin needs custom dashboards, no-code rule editors, or a public-facing web portal, you’re moving from FireCMS configuration to custom Next.js/React work — see ourweb development services for how we structure that work.
4. Add 40–80 hours for any “novel” component. Custom ML model, BLE hardware integration, computer vision, video streaming. These are the parts AI does not speed up. (For ML / LLM-specific scope, see ourAI development services
5. Adjust for backend choice. If your product needs a custom backend (PHP Laravel, Node.js, Cloudflare-style infrastructure), add roughly 25–35% on top of the dev hours above.
6. Adjust for mobile choice. If your product needs both native iOS and native Android — for perfect native UI fidelity, deep system access, or platform-specific features — add roughly 40–50% on top of the mobile dev hours. Single-platform native (just iOS or just Android) costs roughly the same as single-platform cross-platform.
7. Add ~50% on top in non-engineering hours. Designer (40% of frontend hours), QA (20% of dev), PM (15% of dev + QA), BA (40–80 hours), risk buffer (10% of total). These ratios are not optional — they’re how the product actually ships.
8. Then add a calendar buffer of 10–30%. Real-world client review cycles, content prep, and refinement rounds typically push the calendar 10–30% longer than the engineering effort itself.

Anchored against real recent MVP estimates, there are two clean reference points for a cross-platform MVP. A lean MVP on ready-made tools (Flutter + Firebase + FireCMS) lands at roughly 450–700 hours / 6–8 weeks / $15K–$25K.

An MVP that needs a custom backend (PHP Laravel, Node.js, Cloudflare-style infrastructure) lands at roughly 700–1,300 hours / 8–12 weeks / $30K–$50K. Apply the native-mobile adjustment on top if both iOS and Android need to be native. If your back-of-the-envelope number is materially higher than that, the scope likely hasn’t been sliced into a real MVP yet — and the highest-leverage thing you can do is slice it before you start.

This is a back-of-the-envelope number, not a quote. The number you actually act on should come out of a focused discovery phase — typically sixteen to forty hours of business analyst time — that turns the rough number into a feature-by-feature estimate.

What this looks like in practice

If you’re starting your own product, the highest-leverage hours you’ll spend are the ones *before* development — narrowing the core action, picking platforms, and locking architecture decisions you’ll have to live with for years.

We work with founders at exactly that stage. Our discovery phase produces a lean canvas, feature breakdown, and tech stack recommendation in roughly sixteen to forty hours of business analyst time, and turns into a single-source MVP estimate you can budget against. From there, our MVP development team builds, ships, and hands you a codebase that doesn’t have to be rewritten on day ninety.

If that maps to where you are, book a free consultation — we’ll tell you honestly whether your idea is closer to a 2-week MVP or a 5-month one, and why.

FAQ

• How long does it take to build an MVP in 2026?
  Between three weeks and three months of pure development effort, depending on scope and platform count. Most well-scoped MVPs land in the six-to-twelve-week range of focused engineering. Fast MVPs (under six weeks) require a tightly bound core action, an experienced team, AI-curated development in the loop, and existing libraries for non-core features. Calendar time is usually ten to thirty per cent longer than pure dev time once review cycles and refinements are included.
• What is the minimum team to ship a real MVP?
  Four people, in our experience: one developer for the primary platform, one for backend (or one full-stack), a QA engineer, and a project manager who also handles delivery. Cross-functional designers and fractional CTOs sit on top of that core when scope demands it.
• How much does an MVP cost in 2026?
  Two honest reference points from recent NERDZ LAB MVP estimates. ~$15K–$25K for a lean MVP that leans on ready-made tools (Flutter + Firebase + FireCMS) — single core flow, basic admin, ~450–700 hours of pure development. ~$30K–$50K for an MVP built with a custom backend (PHP Laravel, Node.js, or Cloudflare-style custom infrastructure) — when product needs cannot be served by managed-tool defaults. Anything beyond that is no longer an MVP — it’s a multi-product platform, and the right move is usually to slice it into a real MVP first.
• See our pricing page for current bands, and our deeper guide on how much it costs to develop an app in 2026  for the full breakdown.
• Has AI made MVPs cheaper?
  Yes — by roughly twenty to thirty-five per cent on the implementation side. That has not made strategy, architecture, or QA cheaper. Founders who reinvest the savings into more careful product decisions tend to ship more durable MVPs than those who pocket the savings as a smaller team. Our CTO walks through exactly which tools we use and how in How we use AI across our development workflow.
• Should I let AI write my MVP without engineer oversight?
  If you only want to quickly validate an idea from scratch — testing whether the concept resonates before committing to real product investment — vibe coding can get you to a clickable demo fast and is acceptable for that purpose alone. For an MVP you intend to put in front of paying users and extend, no. Vibe-coded codebases routinely get rebuilt at Stage 2. AI-curated development — AI under engineering supervision — is the durable middle path.
• What’s the difference between a prototype and an MVP?
  A prototype answers “what does this look like?”. An MVP answers, “will real users do the thing we hoped they’d do?” If your product can’t put a real user in front of a real outcome, it’s a prototype, regardless of how polished it looks.
• How do I know my MVP was built right?
  Two checks. A new developer should be able to ship a small feature within their first three days. And adding a second user role should not require rewriting the first one. If either fails, the codebase will fight you on every Stage 2 feature.
• Should I build cross-platform (Flutter / React Native) or native iOS and Android?
  Cross-platform when the product fits inside it — productivity, marketplaces, B2B tools, content apps, basic e-commerce, simple healthcare. One codebase, one team, roughly forty to fifty per cent cheaper than building two native apps. Native iOS / native Android when the product needs perfect native UI fidelity (fashion, beauty, lifestyle, meditation, premium content), deep system access (Bluetooth Low Energy, low-level network monitoring, accelerometer at high frequency, AR, advanced camera control, CarPlay), or a long roadmap of platform-specific features (Live Activities, App Clips, watch companions). The cost penalty for going native on both platforms is real — but for products in the categories above, cross-platform either complicates the build dramatically or fails to reach the same quality bar. Like backend choice, this deserves its own deeper article.
• Should I use ready-made tools (like Firebase) or a custom backend for my MVP?
  It depends on what your product needs to do. Ready-made tools (Firebase, Supabase, FireCMS, etc.) trade flexibility for speed: you get auth, real-time, offline, and admin scaffolding for free, but you live inside the tool’s data model and limits. Custom backends (PHP Laravel, Node.js, Cloudflare-style infrastructure, etc.) trade speed for flexibility: you build more, but you control everything. When we’ve internally estimated the same MVP scope both ways, the ready-made path runs roughly twenty-five to thirty-five per cent lighter on engineering hours — but cheaper isn’t automatically better. If your product has unusual data, hard performance targets, or compliance constraints that ready-made tools don’t cover well, custom is the right call from day one. The deciding factor is fit, not price. For the technical tradeoffs in detail, see our companion piece, Firebase vs Back-end.
• How cheap can a lean MVP actually get?
  The lowest-priced MVP we’ve delivered recently came in at around $7,500 — covering both design and development end-to-end. That’s the floor: a single, tightly-bounded core action, ready-made tools doing as much heavy lifting as possible, no admin beyond what’s strictly necessary, no compliance overhead, no novel components. More representative lean MVP estimates land at $15K–$23K (e.g., a Flutter + Firebase loyalty/rewards MVP, 446–693 hours) and around $19.5K (Flutter + Firebase wedding guest app, ~611 hours). Lean MVPs are deliberate: remove gamification, secondary auth methods, fraud detection, custom rule editors, and multi-role admin. Keep auth, one core flow, the smallest admin surface, and analytics. Lean is a faster test of the hypothesis, not a worse product.