It’s a common, frustrating spot: a previous developer disappeared, a freelancer ghosted, or an agency relationship fell apart — and you’re left holding a website that’s 60% done and nobody fully understands. The instinct is to either nag the old developer back or scrap everything and start over. Usually neither is the best move.
Here’s how to take over a stalled build without lighting money on fire.
Step one: audit before you build
The single most important rule when inheriting a half-finished project is don’t write a line of new code until you understand what exists. A good takeover starts with an audit, not a sprint.
An audit answers the questions that determine everything else:
- What’s actually built versus what’s just designed or mocked up?
- Is the code reasonable quality, or is it a tangle that’ll cost more to fix than to redo?
- What’s the real completion percentage — honestly, not optimistically?
We run a fixed 4-hour audit at the start of every takeover for exactly this reason. Four hours is enough to tell whether the existing work is a foundation or a liability.
What to check (your takeover checklist)
If you want to do a first pass yourself before bringing anyone in, work through this:
Access and ownership
- Do you have the code repository (GitHub, GitLab, etc.) — not just a live URL?
- Do you control the domain registrar and DNS?
- Do you have the hosting account logins, or are they trapped on someone else’s account?
- Who owns the design files, the content, and any third-party accounts (payment, email, analytics)?
Ownership gaps are the most common — and most dangerous — finding. A site you can’t access or move is a site you don’t really own.
Code and infrastructure
- Is the code in version control with a readable history, or is it a folder of files someone zipped up?
- Are there any docs, a README, or setup instructions?
- What’s the tech stack, and is it something current and maintainable?
- Does it actually build and run from a clean checkout?
Functionality
- Which features work end-to-end, and which are half-wired?
- Are forms, payments, or logins actually functional or just visually present?
- What’s broken on mobile?
Red flags that change the math
Some findings push the honest recommendation from “finish it” toward “rebuild the foundation”:
- No repository access. If you literally cannot get the source code, finishing it may be impossible — you might be rebuilding regardless.
- A dead or exotic tech stack that few people can maintain.
- No working build. If the project won’t run, “90% done” is meaningless.
- Security problems baked into the foundation — sometimes cheaper to replace than to patch.
A trustworthy partner will tell you when starting over is the cheaper option. That honesty is the whole point of auditing first.
How we structure a takeover
Our “Finish What They Started” tier is built for this exact situation: a fixed $2,000, structured as a 4-hour audit plus 40 hours of finishing work, delivered in about 10 business days or less. The audit comes first; if it turns up something that changes the recommendation, you hear it before more money is spent.
Like every project, it includes two free revision rounds within 60 days, a lifetime warranty on bugs from our delivery, and full code ownership at handover — so you never end up stranded again.
The bottom line
Don’t restart on instinct, and don’t pour money into a foundation you haven’t inspected. Audit first, get an honest read on what’s salvageable, then finish what’s worth finishing.
If you’re sitting on a stalled build, our finish my website service is the place to start. Tell us what’s going on and we’ll take a look.