Taking over a broken or half-finished website costs less than a full rebuild when the foundation is sound, and more when the code is so tangled that fixing it takes longer than starting again — the price turns almost entirely on which of those two you have.
What does it actually cost to take over a website someone else built badly?
There is no flat rate, because the work ranges from a few hours of cleanup on a solid site to a full rebuild on a broken one. The cost depends almost entirely on the condition of what you’re handing over, not on how the previous developer described it.
When a GTA business owner calls us about a site a previous developer left broken or half-finished, the first thing we tell them is that the invoice for the old work tells us nothing about the cost of the new work. A site that looks finished on the surface can be held together in ways that make every future change slow and risky, and a site that looks unfinished can sit on a clean, standard platform that’s quick to pick up.
The honest answer is that pricing follows condition. Two projects that look identical to the owner — same industry, same number of pages, same list of complaints — can differ several-fold in cost because one runs on a mainstream platform any developer can read and the other runs on a bespoke framework only its author understood.
Because of that, no reputable agency should quote you a firm number over the phone from a description alone. The number comes after someone has actually looked at the site’s code, hosting, content management system and analytics. That’s why our consultation is free and no-obligation — we’d rather spend the time finding out what you have than guess and be wrong.
What we can tell you up front is which factors move the price, and those are consistent across almost every rescue we’ve taken on: the platform, the quality of the code, whether you have full access, and whether the previous work can be built on or has to be pulled out.
Rescue or rebuild — how do agencies decide which you need?
An agency decides by auditing the existing site against a simple test: can the current foundation carry the work you still need done? If yes, it’s a rescue. If fixing the foundation costs more than replacing it, it’s a rebuild.
The decision is a cost comparison, not a matter of taste. A rescue keeps the existing platform, database and as much working code as possible, and bills for the time to understand it, repair it and finish it. A rebuild starts fresh on a clean platform and bills for that build, usually migrating your content and salvaging your branding.
The reason a rescue is sometimes more expensive than a rebuild surprises people. Reading and untangling someone else’s undocumented code can take longer than writing new code from a known starting point. When the previous work fights you at every step, the cheaper path is often to stop fighting it.
We run every takeover through the same audit before quoting either way, so the recommendation is grounded in what’s actually there rather than a preference for the bigger project. The table below is roughly how the two paths compare on the things owners care about.
| Factor | Rescue (keep and repair) | Rebuild (start fresh) |
|---|---|---|
| Best when | Foundation is sound, work is unfinished or partly broken | Foundation is broken, abandoned or on an unsupported platform |
| Upfront cost | Usually lower | Usually higher |
| Long-term cost | Higher if the foundation stays fragile | Lower once on a clean, standard platform |
| Discovery time | Significant — reading unfamiliar code | Minimal — building from a known base |
| Your content and branding | Kept in place | Migrated across |
| Main risk | Hidden problems surface mid-project | Longer timeline before you see the new site live |
Why does inheriting someone else’s code cost more than you’d expect?
Because before anyone can fix or extend a site, they have to understand how it was built — and undocumented work by another developer has to be reverse-engineered decision by decision, which is billable time a fresh build never spends.
When we write a site ourselves, we know why every part is the way it is. When we inherit one, we know none of that. Someone has to open the code, trace how the pages are generated, work out which plugins or scripts are load-bearing, and figure out which of the odd choices were deliberate and which were mistakes. That discovery phase is real work, and it happens before a single visible improvement lands.
This is the cost owners least expect, because from the outside it looks like nothing is happening. You’re paying for someone to read, not to build. But skipping it is how rescues go wrong — change something without understanding it and you break three things you couldn’t see.
The condition of the code decides how long this takes. Clean, commented work on a standard platform reads quickly. A custom build with no documentation, mixed coding styles and dead code left in from abandoned features can take days just to map. That range is why we can’t quote before we’ve looked.
It’s also why a half-finished site is sometimes harder than a fully broken one. A broken site tells you plainly what doesn’t work. A half-finished site hides which parts were never actually connected, and you find out the hard way when you go to use them.
What goes wrong before the work even starts?
Access. Owners frequently don’t hold the logins to their own domain, hosting, CMS or analytics, and recovering them from a former developer who has moved on — or is unwilling — can stall a project for weeks before any work begins.
The most common delay we see has nothing to do with code. It’s that the business doesn’t fully control its own assets. The domain might be registered under the old developer’s account, the hosting billed to their card, the CMS admin tied to their email. On good terms this is a quick handover. On bad terms it’s a standoff.
This matters because without those credentials, a rescue can’t safely proceed and a rebuild can’t launch on your own domain. We always establish who holds what during the free consultation, precisely so this surfaces early rather than mid-project when it’s more expensive to be stuck.
Ownership of the work is the second trap. If the previous arrangement never transferred the rights to the code or design, you may not legally be free to modify it — another reason a rebuild sometimes wins, because new work is unambiguously yours.
Our advice to any owner even thinking about switching developers: start collecting your access now, while relations are civil. It’s far easier to get a login handed over before a relationship sours than to recover it afterwards.
What drives the price of a rescue up or down?
The platform it’s built on, the quality and documentation of the code, whether you have full access, and how much of the previous work can be reused rather than replaced. Each of these can shift the estimate substantially in either direction.
Platform comes first. A site on Shopify, WooCommerce or another mainstream system that any developer can read is cheaper to take over than one on a bespoke framework or an obscure setup that needs specialist knowledge to touch. We work across Shopify, WooCommerce, Magento and custom builds, so we can usually tell within the first look which category you’re in.
Code quality is next. Documented, tidy code shortens discovery; tangled, undocumented code lengthens it. This is the single factor that most often makes a rescue cost more than the owner assumed, and it’s invisible from the front end.
Access lowers cost when it’s complete and raises it when it isn’t — every credential you can’t produce is time someone spends recovering or recreating it. Reusability is the last lever: content, images and branding usually carry over cheaply, while broken functionality often has to be rebuilt regardless of which path you choose.
None of these are things you can assess from the outside as an owner, which is the point of the audit. We’d rather tell you honestly that a rescue will cost more than a rebuild and let you choose than take the rescue because it sounded smaller.
1Confirm accessDomain, hosting, CMS, analytics2Audit the foundationPlatform, code quality, structure3Map what worksReusable versus broken4Recommend pathRescue or rebuild, with reasoning5Quote against scopeGrounded in what’s actually there
What should you gather before asking an agency for a quote?
Every login, invoice, contract and file connected to the site — domain registrar, hosting, CMS admin, analytics, and any handover documents from the previous developer. The more complete that pack, the faster and more accurate the quote.
A good handover pack changes the estimate more than owners expect, because it removes the guesswork and the recovery time. If you can hand an agency working access on day one, they can look properly and quote precisely. If they have to spend the first week finding out what exists, that uncertainty gets priced in.
At minimum, try to locate: control of the domain name and where it’s registered; the hosting account; admin access to the content management system; access to Google Analytics and Google Search Console if they were ever set up; and any contract or invoice that describes what the previous developer was supposed to deliver.
Also useful is anything that documents the original intent — a design file, a project brief, a list of features that were promised. On half-finished sites this tells us what was meant to be there, which is otherwise hard to reconstruct.
If you can’t find some of these, that’s fine and worth knowing early. Missing access is a solvable problem, but it’s a cost, and naming it up front means the quote you get is one you can trust rather than one that balloons later.
When is a rebuild actually the cheaper choice?
When the site sits on an abandoned custom framework, an unsupported platform, or code so poor that understanding it costs more than replacing it — in those cases the rescue’s discovery time exceeds a fresh build, and the rebuild is cheaper both now and over time.
The clearest case is an abandoned bespoke framework — a site the previous developer wrote from scratch in a way only they understood, with no documentation and nobody else who can maintain it. Every future change to that site is expensive forever. Moving it to a standard platform ends that tax.
An unsupported or dead platform is the same story. If the system the site runs on is no longer maintained or no local team works with it, you’re locked into a shrinking pool of help at rising cost. A rebuild on a mainstream platform buys back your freedom to hire anyone.
The subtler case is code quality. When the existing work is so poor that reading it takes longer than writing new work, the rescue’s upfront saving is an illusion — you pay for the discovery and still inherit fragility. We flag this honestly when we see it, even though the rebuild is the larger project.
A rebuild also resolves the ownership question cleanly. New work built for you is unambiguously yours, with credentials in your name from day one, which for a business that just got burned by a previous developer is worth as much as the code itself.
What red flags mean you should walk away from the existing site?
No access you can recover, no documentation, a dead or bespoke platform, and unresolved ownership of the code — any two of these together usually mean a rebuild will cost you less than trying to save what’s there.
Take each red flag as a cost, not a verdict, and add them up. One on its own is manageable — a missing login can be recovered, a platform can be worked with. It’s the combination that tips the balance, because they compound: undocumented code on a dead platform you don’t control and don’t legally own is three problems that each make the others worse.
Security is a red flag that overrides the rest. If the inherited site has been compromised, is running outdated software with known vulnerabilities, or was built with practices that expose customer data, the safe move is usually to rebuild clean rather than to patch something you can’t fully trust.
Be wary too of a site where nobody can tell you how it works — not you, not the previous developer, nobody. A site no one understands is a site no one can safely change, and every future update carries the risk of breaking something invisible.
When we run into these on a takeover, we say so plainly. Our job on the free consultation is to tell you which path costs you less, and sometimes the honest answer is that the site you paid for is worth less than the effort to save it. Better to hear that before you spend than after.
Common questions
Can you take over a site if I’ve lost contact with the original developer?
Usually yes, though it depends on what access you can recover. If the domain, hosting and CMS are registered under accounts you can still reach, we can proceed. If they’re locked to the former developer’s accounts, we’ll help you work out what can be recovered and what may need to be recreated — and we’ll factor that into the quote honestly rather than discovering it mid-project.
How long does taking over a website take?
Timelines vary with the condition of the site and which path you take, so we don’t quote a duration before we’ve looked. A rescue on a clean platform with full access can move quickly; a rebuild or a rescue on tangled code takes longer. We give you a realistic timeline after the audit, not before.
Will I lose my Google rankings if I rebuild?
Not if the migration is handled properly. Rankings are at risk when content, URLs and technical signals aren’t carried over carefully, which is exactly what a technical SEO audit protects against. We build the rebuild with your existing search presence in mind so you keep the ground you’ve earned rather than starting over.
Do I have to commit before I know whether it’s a rescue or a rebuild?
No. The consultation is free and carries no obligation. We look at what you have, tell you which path costs you less and why, and you decide from there. You’re not committing to a project by finding out where you stand.
What if my site is only half finished rather than broken?
Half-finished sites are common in takeovers and they carry a particular cost: it’s often unclear which parts were completed and which were only started. We map what actually works before quoting, because the gap between what looks done and what is done is where half-finished projects go over budget.
Can you work on platforms like Shopify, WooCommerce and Magento?
Yes. We work across Shopify, WooCommerce, Magento and custom builds, so we can take over a site on a mainstream platform or advise you when the existing one is worth moving away from. Being platform-agnostic is part of why we can give you a straight rescue-versus-rebuild answer.
Are you a local team or an offshore call centre?
We’re a Mississauga-based team, founded in 2017, serving the Greater Toronto Area, with an additional office in Pakistan. When you get in touch you hear back within one business day from a real strategist, not a script.