A decent share of our work starts with a codebase somebody else wrote. The developer has moved on, the agency has folded, or the project quietly outgrew whoever built it. The business is still running on the thing, and there is nobody to ring.
If that is where you are, it is a more normal position than it feels, and it is usually recoverable.
Get hold of your own things first
Before you talk to any new developer, find out what you actually control. Who owns the domain registration. Who has the DNS. Where the hosting is and whose name is on the account. Whether there is a repository, and whether you can get into it. Where the database backups live.
Chase this down even if you are perfectly happy with your current setup. The moment you need it is always the worst moment to discover a domain is registered to someone who left the company in 2019. We have spent weeks recovering domains for clients, and it is entirely avoidable.
What we look at first
When we pick up an inherited project, the first job is reading it rather than changing it. We want to know what version of the framework and language it is on and whether those are still supported, what the dependencies are and whether any have known vulnerabilities, whether there are any tests, how it gets deployed, and whether there is a staging environment or whether changes have been going straight to live.
That last one tells you a lot. A project deployed by dragging files onto a server has usually been maintained the same way.
We also look for the parts that are load-bearing. Every inherited codebase has a few functions everything depends on, often undocumented, and knowing where those are before touching anything saves a great deal of trouble.
Fix or rebuild
This is the question you are really asking, and the honest answer is that it is usually fix, not rebuild. Rebuilding is the fun option for a developer and it is frequently the wrong recommendation. Working software, even ugly working software, has years of your business rules embedded in it, and a rebuild throws that away and rediscovers it the hard way.
The cases where we would say rebuild are genuine ones: the framework is so far out of support that upgrading is a bigger job than starting again, the architecture cannot do what the business now needs without being unpicked entirely, or the code is in a state where nobody can change anything safely.
Otherwise the sensible path is to stabilise first. Get it onto supported versions, get backups and deployments working properly, get tests around the parts that matter, and then improve it in pieces while it keeps running.
You get the assessment either way
We do this review whether or not you go on to work with us, and we will tell you if the honest answer is that your current setup is fine and you do not need to change anything. That has happened.
What we will not do is quote for a rebuild without having read what you already have. Anyone who does should worry you.
A note on Laravel specifically
Most of the applications we inherit are Laravel, which is straightforward enough for us that we take them on regularly. Laravel puts out a major version every year and each one is supported for a set period, so an application two or three versions behind is common and generally fine to bring forward. Six versions behind is a different conversation, but still a conversation rather than a write-off.
More on that on our Laravel development page. If you have a project you have inherited and want somebody to look at it, send it over.
