Switching web designers mid-project

Changing web designers mid-project is more common than it looks from the outside, and handing an unfinished build to a new developer is rarely as simple as the new supplier “picking up where the last one left off.” What actually happens depends heavily on the platform, how much was genuinely completed, and whether the new developer can honestly assess the existing work rather than simply agreeing to continue it because that is what you asked for.

What a new developer needs from you on day one of a mid-project transition

Item	Why it’s needed
Domain registrant access	Nothing can go live without it — confirm this first, before anything else
Hosting account access	The new supplier needs to see and work with the actual environment, not a description of it
CMS admin login, if the platform is being kept	To assess what exists and continue building on it
Design files, if they exist	Even an incomplete design file saves reworking decisions from scratch
Source code or repository access, for a custom build	Needed to assess whether the codebase is workable to continue
Your own content and images	So nothing is lost regardless of what happens to the previous supplier’s work
The original brief or contract	Tells the new supplier what was actually meant to be delivered, not just what currently exists

The honest question a new developer should answer before quoting a mid-project handover

Whether to continue the existing work or rebuild is not a question the new supplier should answer to please you — it should be answered by what they actually find. A site built on a common, well-documented platform in a reasonably standard way is often genuinely continuable. A custom-coded build with undocumented decisions, or a platform site built in an unusual or heavily customised way, is frequently cheaper and lower-risk to rebuild than to reverse-engineer. Be wary of a supplier who agrees to continue sight-unseen, before reviewing what actually exists — that is a commitment made without the information needed to make it honestly.

What is usually reusable when changing web designers, and what usually isn’t

Content — the words, the photographs, the structure of what pages exist — is almost always reusable regardless of what happens to the underlying build. Design decisions, if design files exist, can often inform a rebuild even where the code itself is discarded. What is least often reusable is bespoke custom functionality built by someone else, because a new developer inheriting unfamiliar code carries a real risk of subtle bugs they did not create and may not understand well enough to safely modify. That risk is legitimate, not an excuse to pad a quote — ask the new supplier to explain specifically what concerns them about the existing code if they recommend a rebuild.

Closing out the previous developer relationship

Confirm in writing what has been paid, what was delivered against that payment, and request whatever you are contractually entitled to — access, files, content — regardless of whether the relationship ended well or badly. This is worth doing even where you do not intend to pursue anything further, because it closes the record cleanly and avoids ambiguity if a dispute resurfaces later. Where the previous supplier is unresponsive, what to do if your web developer disappears sets out the order of operations for securing access without their cooperation.

What to tell the new developer about why the previous project ended

Be plain about why the previous relationship ended, without editorialising more than the facts require. Web projects sometimes fail mid-build for ordinary, recurring reasons — content arriving late, the previous developer disappearing, or the scope changing without the contract changing with it — and a new developer who understands which of those applies here can price and plan for a similar risk rather than assuming a clean start. What the new engagement’s quote and contract should contain is the same as any first engagement — see what should be in a website quote — with the added detail of exactly what is being inherited versus rebuilt.

The cost implication of a mid-project transition worth planning for

A switch mid-project rarely costs less overall than the original quote, even where some work is reused, because assessment time, any necessary rebuilding, and the new supplier’s own margin for the uncertainty of inheriting someone else’s work all add cost the original quote did not anticipate. Budget for this rather than assuming the switch will be a discount on the remaining scope.

What to do next when changing web designers mid-project

Confirm domain and hosting access before agreeing to anything with a new developer, and ask them to genuinely assess the existing work — platform, code quality, what’s actually complete — before committing to continue or rebuild. A quote given before that assessment is a guess, not a plan.

What that assessment and the resulting engagement should look like as a purchase is the same territory covered on website design services as a purchase.