A technical phrase with an entirely commercial meaning: what your next change will cost.
A technical phrase with an entirely commercial meaning: what your next change will cost.
Maintainable means the next developer can find the thing they need to change, change it, and be confident they have not broken something else.
That is it. Everything else is detail in service of that.
It sets the price of every change for the life of the site. Unmaintainable code is a loan taken out in your name, repaid in every future invoice.
Ask who else could work on it. Ask what happens if we disappear. Ask to see the documentation. The answers tell you more about maintainability than any framework choice.
Is there a README that gets a new developer running locally? Are there tests, and do they pass? Is deployment automated, or does one specific person know the steps?
Those three answer the question without you reading a single line. A project that fails all three will be expensive to change regardless of how good the code itself is.
Familiar patterns and mainstream tools mean the next person recognises what they are looking at. Clever code is expensive to maintain even when it is entirely correct, because understanding it is a prerequisite for touching it.
We optimise for the developer who arrives in two years knowing nothing about the project. Often that developer is us, and we have forgotten everything.
Ask what a handover to another team would involve. If the answer is a long conversation with one specific individual, that dependency is a cost you will eventually pay.
Good documentation is not a nice-to-have on a project you intend to keep. It is the mechanism by which the work outlives whoever did it.
Ask to see the repository history. Frequent, small, described commits indicate a team working deliberately. A handful of enormous commits called update indicate something else.
Ask how a new developer sets it up locally, and how long it takes. If the answer is a documented command and under an hour, the project has been cared for. If it involves a call with the original developer, it has not.
Ask what the tests cover. Not the percentage, which is easy to game, but which parts. Tests around the money and the data are worth more than tests around the buttons.
Ask what happens on deploy. Automated with a way back is healthy. Someone copying files over is a risk you are carrying without being told.
It shows up as estimates that keep rising for changes that sound small, because each one requires archaeology before any work can start.
It shows up as a supplier you cannot leave. When nobody else can safely take the code on, you have lost the ability to negotiate, and that is worth more to the wrong supplier than the work itself.
And it shows up as risk you cannot see. Systems nobody understands are systems nobody can secure, and the first time that matters is usually the worst possible time.
That the repository is yours and hosted in your account, not the agency's. That every credential is handed over in a documented form. That there is a README covering setup, deploy and any scheduled jobs.
That the site can be run by another competent developer without contacting the original team, and that a handover session is included rather than billed as a favour.
None of this is unusual to ask for, and the reaction to being asked tells you a great deal before you have signed anything.