An enquiry arrives from someone who paid a developer four months ago, has a site that is sixty percent finished, cannot reach him and does not know whether she owns anything she has paid for.
She is not shopping for a website. She is trying to work out whether she has lost her money.
When rescue makes sense
It makes sense when the platform is one you work with, when the existing work is competent, when full access can be obtained, when the remaining scope is clear and when the client understands they are paying for someone else's unfinished work.
When starting again makes sense
It makes sense when the existing build is poor enough that fixing it costs more than replacing it, when access cannot be obtained, when the platform is one nobody should be using, or when the client's requirements were never properly defined in the first place.
Establish access before anything
Hosting, domain, repository, content management login, any third-party accounts and the design files. A project you cannot fully access is not one you can take responsibility for.
Ask what was agreed and paid
Not to apportion blame, but because it determines what the client expects for their remaining budget and whether their expectations are realistic.
Look at the code before quoting
An hour spent reviewing the build is what distinguishes a quote you can honour from one you will regret. Charging for that assessment is reasonable.
Be honest about the assessment
Telling a client that the work she paid for is not salvageable is a difficult conversation and it is the one she needs. Clients respect it, and they remember who told them the truth.
Never criticise the previous developer personally
Describe the state of the work, not the person. Clients who feel let down are looking for validation and giving it makes you look unprofessional.
Price the unknowns properly
Rescue work contains surprises. An assessment fee, then a scoped quote, is fairer than a fixed price that assumes the best.
Set expectations about what you inherit
Where you take on someone else's code, be clear what you can and cannot guarantee about parts you did not build.
Explain ownership plainly
Who owns the domain, the content, the design and the code. Many clients discover at this point that they own less than they assumed, and helping them understand it is genuinely valuable.
Decide who talks to the previous developer
Sometimes the original developer resurfaces, wants paying or holds credentials nobody else has. Agreeing at the outset that the client handles that relationship, while you deal only with technical handover, keeps a studio out of a dispute it has no part in and protects the working relationship you are trying to start.
Timelines matter more than usual
These clients have already waited months, which is the pressure described in timeline questions from clients who needed it yesterday and how long a website takes and other timeline questions.
Dissatisfied clients also arrive as redesigns
The enquiry is a cousin of redesign enquiries from businesses with tired websites, and they usually find you on a phone, as in mobile visitors and enquiries.
Getting started
Publish how you handle takeover projects, your assessment fee and what you need access to, then capture project details at any hour. SpideyChat for web studios answers from your published pages. Try SpideyChat on your own site, or read about capture on the features page.