Direct answer: a simple consumer or MVP rebuild runs roughly $120k–$300k; a standard B2B rebuild with integrations and auth runs $300k–$800k; a complex SaaS with multi-tenant data, billing, and analytics runs $800k–$2.5M; and enterprise replatforms with regulatory/compliance work commonly start at $2.5M and go past $10M. Data migration, QA, and integrations typically add 10–40% on top of base development estimates.
How much does it cost to rebuild an app: what really drives the price
Three categories drive 80% of rebuild cost: feature parity, data migration, and integration rewrites. Feature parity is scope—every button, edge case, and import/export path translates to work. Data migration is brittle—format conversions, correcting historical inconsistencies, and designing fallback reconciliation increase cost. Integrations are multiplicative—each third-party API (Stripe, Plaid, Salesforce) is a separate engineering and test effort.
A single full‑time engineer in the US runs $180k–$220k/year fully loaded. A 4‑engineer rebuild over six months therefore carries a baseline labour value of $360k–$440k before vendor, infra, QA, and migration line items. Managed platform savings are real—using Firebase or Supabase reduces backend work by 20–40% but increases long‑term vendor lock‑in costs and migration risk.
Concrete inflation points: data migration typically costs 10–30% of the project, QA and compliance add 15–25%, and integration rewrites add 20–40%. If your legacy system has poor observability or no tests, expect an additional 30–100% premium as engineers discover hidden requirements during implementation.
Cost bands and example scopes
Define your rebuild against four realistic bands. Use these as priors for vendor conversations and internal budgeting.
1) Small consumer or single‑feature app — $120k–$300k. Typical scope: 3–6 months, 2–4 engineers, limited integrations, minimal data migration. Use case: rewrite UI in modern frontend (React/Next.js), move backend to serverless functions, no multi‑tenant or heavy analytics.
2) Standard B2B app — $300k–$800k. Typical scope: 6–12 months, 4–8 engineers, single sign‑on or role model, Stripe/Payment+CRM integrations, medium data migration. Use case: replace monolithic Rails app with modular Next.js + managed Postgres (Neon/PlanetScale).
3) Complex SaaS — $800k–$2.5M. Typical scope: 12–24 months, 8–20 engineers, multi‑tenant data isolation, metered billing, analytics pipelines, and compliance (SOC2/GDPR). Use case: migrate to a new data model, introduce feature flags and observability, reimplement core business logic.
4) Enterprise replatform — $2.5M+. Typical scope: 18–36 months, cross‑discipline teams, bulk data migration of TBs, complex integration matrix (ERP, SSO, reporting), heavy compliance and SLA guarantees. These projects often include professional services costs for data transformation and months of parallel run.
Why quotes diverge so dramatically
Vendor and internal quotes diverge because of hidden scope and risk buffers. A conservative vendor will price 25–40% contingency for unknowns (poor tests, undocumented APIs). A price‑competitive shop will present a low headline number and then invoice change orders as discoveries emerge. Always ask for a discovery phase quote that converts into fixed scope milestones.
- Discovery & specs: 5–15% of total budget, but reduces surprises by 40–60%
- Data migration: 10–30% variable depending on data cleanliness and volume
- Integrations: 20–40% per external system when you need total parity and retries
Example TCO comparison: if your team spends $1.2M/year maintaining a legacy app and customers churn at 4% monthly attributable to performance bugs, a $1.0M rebuild that reduces maintenance to $400k/year can break even inside 18 months when combined with reduced churn. Use real numbers from billing, retention, and engineering time when you model this.
A rebuild quote is only as honest as the data migration and integration line items — ignore them and your budget will be wrong.
Big‑bang vs. strangler: budgeting the risk
Big‑bang rewrites show a lower nominal cost because you avoid temporary adapter layers, duplicated engineering, and operational complexity. Typical big‑bang vendors quote 10–25% lower than an incremental strangler approach for the same feature set. But big‑bang carries operational and market risk: 6–12 months of blocked feature velocity and a single release that can drop revenue immediately.
Strangler pattern increases development cost by 15–30% because you maintain both systems during cutover and build adapters; however, it preserves revenue flow, reduces launch risk, and lets you amortize cost over multiple releases. For companies with $50k+/month recurring revenue, strangler is often the safer economic choice.
Decision rule: if >40% of engineering time today is maintenance, and you can prove a path to 30–50% efficiency improvement, rebuild via strangler. If maintenance is <25% and the product roadmap demands rapid new features, prefer modular refactor or incremental improvements.
What this means for a CTO or technical founder
You control the three levers that determine final cost: scope (feature parity vs intentional simplification), risk allocation (vendor fixed‑price vs time‑and‑materials), and migration strategy (big‑bang vs strangler). Make each decision explicit and convert assumptions into dollar‑line items on the project budget.
Scope discipline saves money: a 20% feature cull typically reduces cost by 30% because integrations and edge cases cluster in the tail. When a vendor quotes include a clear mapping of features to hours and a separate line for migration and integrations, you can trade scope for lower early‑stage spend without losing control.
Operational advice: require a 6–8 week discovery priced as fixed scope. That discovery should produce a migration playbook (with sample SQL transforms and reconciliation metrics), a CI/CD and observability design, and a rollback plan. If you need senior execution without hiring in‑house, engage a team that specializes in migrations and replatforms—see our legacy modernization offering for how a senior team structures this work.
A short checklist to avoid the common traps
- Require a migration runbook with reconciliation tests and expected hours
- Separate migration, integration, and feature work into distinct milestones
- Insist on observability and SLOs before cutting the legacy system
- Budget 25–40% contingency if tests or documentation are missing
How to build a reliable estimate in 6 steps
- Run a paid 6–8 week discovery that produces a line‑itemed scope, migration playbook, and rollback plan.
- Map every integration (payments, identity, analytics) to hours and tests and budget 20–40% extra for each.
- Quantify current maintenance spend and customer churn attributable to technical debt.
- Choose a migration strategy (big‑bang vs strangler) and add 15–30% to the strangler baseline for dual‑running costs.
- Require staged acceptance with production data reconciliation during each milestone.
- Negotiate fixed‑price milestones for discovery outputs, then convert to time‑and‑materials with hard caps for execution phases.
If you want a replatforming TCO lens that folds in hosting, SRE, and three‑year maintenance, our earlier analysis of replatforming cost estimates and the mechanics in custom software TCO are useful priors for the financial model.
- Estimate realistically: use the four cost bands above as priors for planning.
- Budget migration and integrations explicitly as separate line items adding 10–40%.
- Prefer a paid discovery that produces executable migration and rollback playbooks.
- Choose strangler when revenue continuity and customer experience matter; accept a 15–30% cost premium.
- Hire senior execution (internal or a specialized partner) for migrations; inexperienced teams increase total cost by 40–100%.
A final operational note: vendors who underprice discovery or refuse to produce a migration playbook are selling optimism, not certainty. If you are preparing to sign a statement of work, insist on testable exit criteria for each milestone and an explicit reconciliation plan for customer data. When this is in place, the headline number aligns with delivered outcomes.
When you’re ready to move from decision to delivery, engage a team with migration experience and observable delivery metrics. You can start by funding a short, fixed discovery and then convert to milestone‑based execution. We help CTOs structure that exact engagement for rebuilds and replatforms — start with a discovery, not a guess.
