“It’s about 80% finished” is one of the least useful sentences in software rescue work.
The missing 20% may be:
- three simple screens;
or:
- authentication, payments, permissions, deployment, data migration and every failure state that makes the product safe to launch.
Those are very different budgets.
For 2026 planning, I would separate an unfinished-app takeover like this:
| Stage | Planning budget | Main outcome |
|---|---|---|
| Structured takeover audit | $500–$2,500 | Understand what exists and what is trustworthy |
| Contained feature completion | $2,500–$7,500 | Finish a small, healthy codebase with defined missing scope |
| Stabilization + completion | $5,000–$15,000+ | Fix architecture/production gaps and complete launch-critical work |
| Partial rebuild | $10,000–$30,000+ | Replace weak layers while preserving useful product work |
| Complex/regulated product | Scope individually | Deeper security, migration and assurance needs |
These are planning ranges, not universal rates.
Pay for diagnosis when the product is inherited
A new developer should inspect enough of the system to answer:
- What actually works?
- What only works in the demo/happy path?
- Is the data model sensible?
- Are permissions enforced properly?
- Can production be deployed reproducibly?
- Are payment flows verified?
- Are secrets handled safely?
- What test coverage exists?
- Which parts can be kept?
- Which parts should be rewritten?
A fixed “finish everything” quote before this review is usually pricing assumptions.
“Frontend complete” does not mean product complete
Modern tools can produce polished interfaces very quickly.
The hidden work may still include:
- server-side validation;
- database constraints;
- roles and permissions;
- payment verification;
- email delivery;
- migrations;
- backups;
- monitoring;
- admin tooling;
- production environment configuration;
- regression tests.
This is why an unfinished app can look nearly done while still being far from a responsible launch.
Start with repository and account ownership
Before another developer changes anything, confirm access to:
- repository/source code;
- deployment platform;
- database;
- domain/DNS;
- email provider;
- payment provider;
- storage;
- analytics/monitoring;
- third-party APIs.
Do not solve an ownership problem by creating more duplicate accounts unless necessary.
Evaluate the foundation before rebuilding
A useful rescue classification is:
Keep
The component is understandable, testable and fits the product model.
Repair
The component is sound but contains local defects.
Harden
It works but lacks production controls such as permission tests, logging, recovery or reliable deployment.
Rebuild
The model is structurally wrong or continued repair costs more than replacing the layer.
This prevents the emotional “throw everything away” response.
Permissions deserve special attention
An app can work perfectly for the founder account and still be unsafe for real users.
If using Supabase, its current guidance recommends Row Level Security on exposed tables and least-privilege grants. See Supabase RLS.
The stack-independent test is simple:
Can one user access another user’s data through the API even if the UI hides it?
That should be tested explicitly.
Payments are often unfinished even when checkout works
A payment button succeeding once is weak evidence.
The product may still need to handle:
- failed payment;
- duplicate callback/webhook;
- abandoned checkout;
- retry;
- refund;
- subscription state;
- delayed provider events;
- reconciliation.
If payments are central, separate feature completion from financial-integrity work in the quote.
Security should not be a vague final task
The OWASP Application Security Verification Standard provides a concrete framework for verifying web-application security controls.
An unfinished product does not need to implement every enterprise control before testing demand, but launch-critical areas should have explicit expectations rather than “we’ll secure it later.”
What should you send the rescue developer?
Provide as much context as safely possible:
- repository;
- current live/preview URLs;
- product brief;
- designs;
- list of known bugs;
- what users are supposed to do;
- current database schema;
- third-party services;
- production/deployment notes;
- existing tests;
- what the previous developer considered unfinished.
If those materials do not exist, the audit simply has to discover more.
How to scope the completion plan
I would group work into four buckets.
1. Launch blockers
Anything that prevents a real user completing the core workflow.
2. Trust blockers
Permissions, payments, data integrity, security, backups and critical error handling.
3. Operational blockers
Admin tools, logs, support visibility and deploy/recovery processes.
4. Nice-to-have roadmap
Animations, secondary dashboards, minor automations and future features.
Do the first three before the fourth.
This is different from finishing a Lovable app
I already have a dedicated guide for the cost to hire a developer to finish a Lovable app.
This article owns a broader intent: any unfinished application—AI-built, freelance-built, agency-built or founder-built—where another developer must inherit the code and take responsibility for launch.
If the app already works but specifically needs production hardening, see vibe-coded app production hardening cost.
The best rescue preserves good work
You are not paying a new developer to prove the old developer was wrong.
You are paying for the shortest responsible path from the current state to a product you can depend on.
Sometimes that means finishing what exists.
Sometimes it means replacing one weak backend boundary.
Sometimes a clean rebuild is cheaper.
The audit should make that decision evidence-based.
If you have an unfinished web app or SaaS product and need someone to tell you what is actually left—not just promise to “finish it”—send me the repository context, current product URL and the core workflow that must work at launch.
