Taking over an existing site is one of the most common requests a studio gets, and one of the easiest to get wrong. The temptation is to say yes, quote a monthly figure and find out later.
The review below takes about two days. It is the difference between a support arrangement you can honour and one that quietly consumes twice the hours you priced.
Access first, and completely
Before anything technical, establish what you actually have. Missing access is the most common reason a takeover stalls, and it is usually discovered at the worst moment.
- Source repository, with full history rather than a zip of the current state.
- Hosting, DNS and TLS certificate control – all three, held by the client and not the previous supplier.
- CMS administrator access, and the ability to create new administrators.
- Third-party accounts: payment gateway, email sending, analytics, error tracking, any SaaS the site depends on.
- Domain registrar. This one is missed constantly and is the hardest to recover.
If the previous supplier holds any of these, resolving that is the first piece of work, and it is worth doing before the relationship with them ends badly.
Does it build?
Clone the repository onto a clean machine and try to run it. This single step tells you more than an hour of reading code.
Does it install without undocumented steps? Is there a README that matches reality? Are environment variables documented, or do you have to guess which of forty are required? Is there a database seed or fixture, or does local development require a copy of production data – which is both a practical problem and a data protection one?
If getting the project running takes more than half a day, factor that into every future estimate, because every developer who ever touches it pays that cost again.
Dependencies and known vulnerabilities
Run the dependency audit for the ecosystem and read the output properly rather than counting the warnings.
What matters is not the number, it is the shape. A hundred advisories in transitive development dependencies is noise. One unmaintained package that the payment flow depends on is the whole engagement.
Check the maintenance status of anything load-bearing: last release date, open issue count, whether the maintainer still responds. A package abandoned three years ago is a rebuild waiting to be scheduled, and you want that on the roadmap rather than in an incident.
For CMS projects, count the plugins and check each one's update history. Twenty-five plugins where three overlap in function is the classic profile of a site that cannot be updated safely.
Tests, and what they actually cover
Coverage percentage is close to meaningless. What matters is whether the paths that lose money are covered: checkout, authentication, permissions, anything that calculates a number a customer sees.
A project with twelve per cent coverage concentrated on the calculation engine is in better shape than one with seventy per cent spread evenly across getters.
If there are no tests at all, that is not automatically disqualifying – plenty of working software has none – but it changes what a support arrangement can promise. Without tests, every change is a manual regression risk, and the response times you quote have to reflect that.
The three honest answers
At the end of the review there are three outcomes, and a supplier who only ever reaches the third is telling you something about themselves.
- Support it as it is. The code is comprehensible, dependencies are current enough, the critical paths are covered. Price the retainer and get on with it.
- Support it with a remediation phase first. Common. There is a specific list – update these dependencies, document the deploy, add tests around the checkout – that has to happen before response times can be promised. Quote it separately and honestly.
- Rebuild. The architecture is the constraint, or the dependency situation is unrecoverable, or the cost of working inside it exceeds the cost of replacing it. This is the answer clients least want and it is sometimes correct.
The review is worth paying for on its own, even if you then choose a different supplier. It converts an unbounded risk into a written list, and the list is portable.