ProofDevs

How Much Does It Cost to Finish an Unfinished Website or App?

You paid for 80% of a website and received 50% of a working product. The remaining work is priced nothing like the original quote — here is how rescue developers calculate it and what the finish should cost.

Michael Melnyk
Michael Melnyk•Senior IT Technical Writer & Technology Analyst
•12 min read
A developer auditing a half-finished website codebase to estimate the cost of completing the missing features.

Finishing an unfinished website typically costs 30–70% of the original build budget — and the exact number can only be set after a paid code audit. A project that looks "90% done" usually has its visible features built and its invisible work missing: error handling, payment failure states, permissions, backups, and testing. Reviewed September 2026. Rate bands below are ProofDevs-published figures; totals are planning calculations from those bands, not market averages.

If your developer disappeared, stop negotiating with silence and secure your assets first with our 48-hour recovery plan for abandoned projects. Then use this guide to price the finish. For the general price map behind any quote, see custom website cost by project type; for bargaining tactics once you have a rescue quote, use how to negotiate price with a developer.

Three audit outcomes that set the finish price: continue, repair then continue, or restart.

Why "almost done" is the most expensive phrase in software

"Almost done" describes visible screens, not working software — the remaining invisible work is routinely half the project. Demos show the happy path; production demands every failure path.

A booking site can look complete while nobody handled double-booking races, refund flows, email delivery failures, or admin permission boundaries. A SaaS dashboard can render charts while exports time out, secrets sit in the code, and the database has no tested restore. As our unfinished-project service page puts it: the last twenty percent is not twenty percent of the work, because error handling, edge cases, and everything that only matters when real people use the product is still ahead.

This is also why the previous developer's "about a week left" was usually sincere and wrong. They estimated the screens they could see, not the failure states they had never built. Price the finish from a gap analysis of user journeys, never from a percentage the outgoing developer guessed.

The paid audit: what it costs and what it must produce

A takeover audit takes 2–5 days for most small projects and must produce a written gap analysis — never hire a finish without one. Any rescue quote issued without reading your repository is a guess, and guesses on inherited code are wrong in expensive directions.

Using our published bands (September 2026, see outsource-versus-hire comparison: independent senior $45–95/hr, agency $140–250/hr), the audit arithmetic is straightforward. A 16-hour audit at $45–95/hr lands at $720–$1,520 as a planning calculation; a 40-hour deep audit of a larger codebase at the same bands lands at $1,800–$3,800. Agency audit pricing at $140–250/hr puts the same work at roughly triple. These are calculations from stated bands, not quotes — your audit is scoped by repository size, not by averages.

Demand this output before any finish price is discussed:

  • Does the repository build from a clean checkout, or only on the previous developer's machine?
  • Does the deployed version match what is in version control?
  • Which user journeys work end to end on staging, and which fail?
  • Are secrets in environment config or sitting in the code?
  • Does the database schema match what the application expects, and has a restore been tested?
  • How many dependencies are unmaintained or several major versions behind?

The audit pays for itself even if you hire someone else afterward: it converts an unknown quantity into a list of specific problems, and every subsequent quote can be measured against it. Read how a proper takeover audit runs on our project takeover page.

Three outcomes and their price logic: continue, repair, or restart

An honest audit ends in exactly one of three outcomes, and the outcome — not haggling — sets the price band. Insist the auditor names theirs in writing.

OutcomeWhat it meansTypical finish vs original budgetMain risk
ContinueFoundation is sound; the work is finishing, not fixingLower third of the 30–70% planning heuristicScope creep during rescue turns it into a second stalled project
Repair then continueSomething structural (data model, permissions) must be corrected firstMiddle to upper part of the heuristic; repair is invisible work clients resist paying forSkipping the repair to "save money" corrupts everything built on top
RestartRare: unsupported technology or a data model that cannot represent the businessCan exceed the original budget; must itemize what is keptDiscarding design, copy, data, and credentials along with the code

Continue is the most common outcome and the cheapest. Repair-then-continue is where most disputes live: the client sees "rewriting something I already paid for" while the developer sees the only path to a product that survives real users. Restart must be justified with specifics — unsupported framework version, unrecoverable data layer — never with distaste for someone else's code. Even a restart should explicitly state what it preserves: design, copy, database contents, integration credentials, and the accumulated knowledge of what the business needs.

What drives the finish price up or down

Six factors move almost every finish quote; repository condition matters more than feature count. Score your project against each before comparing numbers.

  • Clean checkout and deploy parity. Code that runs only on one laptop adds paid reconstruction days before any feature work starts.
  • Tests that pass. A suite with passing tests lets the new developer change code with confidence; zero tests means every change is manual QA, billed by the hour.
  • Dependency debt. A dozen major versions behind on framework and auth libraries turns "finish features" into "upgrade-then-finish."
  • Access and documentation. Repository, hosting, domain, payment accounts in your hands plus run instructions cut handover cost sharply — see the handover list in our developer replacement guide.
  • Invisible-work share. Payments, permissions, notifications, and failure states dominate the remainder; pure screens are the cheap part.
  • Scope discipline. Freezing the original scope during rescue is the single largest cost control — new features go to phase two with separate pricing.
Six finish-price drivers: clean checkout, passing tests, dependency debt, access and docs, invisible work share, and scope discipline.

Pricing models for rescue work: which to choose

Price rescue work as paid audit first, capped hourly second, milestone-fixed third — never as a blind fixed price. Fixed totals on unread code get padded, then argued about.

StageModelWhy it fits rescue
1. AuditFixed fee for 2–5 days with written reportConverts unknown scope into a priced gap list; usable with any later hire
2. StabilizationHourly with weekly cap + demosBug count is unknowable upfront; caps plus reviews contain it
3. FinishFixed per milestone, paid on accepted user journeysPost-audit scope is definable, so fixed milestones now work

The sprint model described by Scrum.org is the right rhythm for stages 2 and 3: short cycles, defined increment, demo, then payment. Keep 20–30% of the finish value tied to launch acceptance plus a defined warranty window — the same milestone discipline our negotiation guide recommends, applied to inherited code.

Finish cases: what the money actually bought

Three rescue shapes cover most stalled projects — find yours before asking for a number.

Case 1. Next.js SaaS with broken billing: continue

Starting situation: marketing pages and dashboards rendered; Stripe subscriptions failed on renewal and webhook retries.

What blocked it: webhook endpoint assumed success-only flows; no idempotency, no failure emails, secrets mixed into code.

Solution: 3-day paid audit produced a 14-item gap list; stabilization capped at 30 hours; finish priced per milestone — billing journeys first, admin reports second. Stack stayed Next.js with Stripe; no framework change.

Result: finish landed in the lower third of the 30–70% planning heuristic relative to the original build spend. Launch acceptance was defined as real test-mode subscriptions completing renewal, refund, and cancellation journeys on staging.

Case 2. Catalog app with broken data model: repair then continue

Starting situation: 400-product catalog displayed, but filters returned wrong results and bulk import corrupted variants.

What blocked it: audit showed product variants modeled as free text instead of structured options — every feature built on top inherited the corruption.

Solution: two-week repair milestone (migration to structured variants plus backfill script) before any new feature; client froze scope and assigned an assistant to verify product data.

Result: repair consumed roughly half the finish budget and felt like "paying twice" — but skipping it would have corrupted search, filters, and checkout permanently. Finish landed mid-heuristic.

Case 3. Legacy stack nobody supports: justified restart

Starting situation: app built on a framework version end-of-lifed two years earlier; hosting provider announced forced migration.

What blocked it: audit documented specifics: no upgrade path without rewriting plugins, auth library with known unpatched issues, deploy pipeline tied to a discontinued service.

Solution: restart proposal that itemized everything kept — design system, copy, product data export, Stripe credentials, domain and DNS — and rebuilt only the application layer on a supported stack.

Result: restart exceeded the original build figure, but the itemized "kept" list saved an estimated third of greenfield cost as a planning calculation. The lesson: a restart without a keeps-list is starting from below zero.

Typical mistakes clients make when finishing a project

Most finish budgets die from the same five mistakes, not from developer rates.

  • Paying the old contractor more without an audit. Funding continuation of unknown state; the audit costs a fraction of another blind milestone.
  • Adding features during rescue. "While you are in there" converts a finish into a second stalled project — phase-two list, separate price.
  • Accepting a fixed finish price on unread code. It will be padded or abandoned mid-way; audit first, fixed milestones after.
  • Judging progress by screens. Demand staging demos of complete journeys — booked, paid, refunded, notified — not screenshots.
  • Leaving ownership with the outgoing side. Repository, hosting, domain, and payment accounts must move to you before the final payment to anyone, old or new.
  • Skipping the warranty definition. Inherited code fails in new places; define defect vs change request and response time in writing.

Expert advice

Commission the audit as a standalone engagement with one deliverable: a gap list where every item maps to a user journey and an hour range. Then freeze the original scope, ship the working part to a small group of real users before finishing the rest, and price only what survives contact with those users — feedback reorders the backlog more accurately than any planning session, and routinely reveals that a third of the outstanding work was never needed. This is the cheapest paragraph in rescue work, and the most skipped.

Red flags in finish quotes

Reject any finish quote that prices unread code, promises calendar dates without a gap list, or keeps the repository on the supplier's account.

  • Fixed total issued before repository access — the auditor priced imagination, not code.
  • "One week to finish" with no written gap analysis — sincere, wrong, and yours to fund.
  • Code stays in the supplier's personal Git account — you are renting the rescue, not buying it.
  • No defect definition for inherited bugs — every inherited failure becomes your paid change request.
  • Pressure for 100% upfront — legitimate rescue engineers accept audit-fixed, then milestone splits.

If communication already broke down rather than merely stalling, switch tracks: secure credentials and backups, then follow the structured handover in our developer replacement guide instead of funding more delay.

Contract checklist for a finish engagement

A one-page finish agreement naming scope, acceptance, money, ownership, and exit beats any template nobody reads.

  • Scope: gap list from the audit, frozen; new ideas to a priced phase-two list.
  • Acceptance: working user journeys demonstrated on staging per milestone; payment within 3–5 days of acceptance.
  • Money: audit fixed; stabilization hourly with weekly cap; finish fixed per milestone; 20–30% retained for launch acceptance.
  • Ownership: repository in your organization from day one, IP transfer on final payment, all credentials in your accounts.
  • Warranty: defined window (agree your own; 30 days is a common planning example), defect vs change-request definition, response time.
  • Exit: handover package — pushed branches, environment variables, run instructions, deploy steps — required before final payment.

FAQ: cost of finishing an unfinished website or app

How much does it cost to finish an unfinished website?

As a planning heuristic, 30–70% of the original build budget, set precisely only after a paid audit. Repository condition — not feature count — decides where in that band you land.

How much does a codebase audit cost?

Using ProofDevs-published September 2026 bands, a 16–40 hour audit at independent senior rates ($45–95/hr) calculates to roughly $720–$3,800; agency bands ($140–250/hr) run about triple. Scope it by repository size, not by averages.

Should I finish the project or start again?

Unanswerable without reading the code — anyone answering before an audit is guessing. The audit's three outcomes (continue, repair-then-continue, restart) settle it for a fraction of either option.

Can a new developer take over code written by someone else?

Yes — senior engineers do it routinely. The conditions are repository access, a clean-checkout test, and an audit that maps gaps to user journeys before pricing.

How long does a takeover take?

Audit 2–5 days for small projects; stabilization and finish in milestone sprints after. Calendar time depends more on your decision speed and content readiness than on coding speed.

Why did the first developer's estimate fail?

Visible screens were estimated; invisible work — failure states, permissions, backups, testing — was not. Price the finish from a gap analysis, never from their leftover percentage.

Fixed price or hourly for rescue work?

Audit fixed, stabilization hourly with a cap, finish fixed per milestone. Blind fixed prices on unread code get padded, then disputed.

Who owns the code during a rescue?

You should: repository in your organization from day one, IP transfer on final payment, domain, hosting, and payment accounts in your name. See the handover requirements in our developer replacement guide.

What if I lost access to the repository or hosting?

Recover credentials first — registrar, hosting, payment accounts — before hiring. Our 48-hour abandoned-project plan covers the exact order.

Should I add new features while rescuing?

No. Freeze the original scope, ship it, then price new features as phase two. Rescue-plus-expansion is the most common way a rescue becomes a second stalled project.

What warranty should a finish include?

A defined window with defect-versus-change-request language and response times. Inherited code fails in new places — undefined "free support" guarantees a dispute.

When is restarting cheaper than finishing?

Only with audit-documented specifics: unsupported stack, unrecoverable data layer, or auth that cannot be secured. Even then, demand an itemized keeps-list — design, data, credentials, knowledge — or you pay to rediscover every decision.

Tell us what works and what is missing — get a finish assessment for your unfinished project. If the previous engagement already collapsed, start from our developer replacement service, which takes over code, access, and milestones without starting from scratch.

Share this post

Michael Melnyk

Written by Michael Melnyk

Senior IT Technical Writer & Technology Analyst

View Author Profile →

Senior Technical Writer and IT Industry Analyst with over 7 years of experience analyzing software engineering ecosystems, tech leadership models, and developer procurement frameworks.

More from the blog

All articles
A startup founder managing server infrastructure and codebase recovery after an unexpected contractor departure.

Developer Abandoned Your Project? What to Do in the First 48 Hours

When a developer vanishes mid-build, panicking or sending angry emails costs time. Follow this 48-hour recovery plan to secure credentials, retrieve databases, audit uncommitted code, and resume development safely.

Michael MelnykMichael Melnyk·
Hiring a Website Security Specialist for Small Business — 2026 guide covering rates, audit scopes, and vetting

Hiring a Website Security Specialist for Small Business: What It Costs and How to Vet

Cybersecurity agencies charge $25,000 retainers meant for banks. This guide shows small business owners how to hire an independent website security specialist for audits, hardening, and malware cleanup without agency overhead.

Michael MelnykMichael Melnyk·
How to Hire a Website Maintenance Expert — 2026 guide covering vetting, hourly rates, and SLAs

How to Hire a Website Maintenance Expert: Vetting, Rates, and SLAs

Hiring the wrong person for website maintenance leads to broken production updates and missed downtime. Here is how to vet and hire a senior maintenance engineer on flexible hours with clear SLAs.

Michael MelnykMichael Melnyk·

Need this done rather than explained?

Describe the task, the stack or the problem. We connect you directly with developers who have shipped it before.

Free analysisNo commitment2 min