What drives the cost of software maintenance

An application on a framework its maintainers still patch is cheap to keep alive, because security fixes arrive from upstream with every minor release. A retired Laravel or Symfony release is not. Every fix needs a workaround, each Composer or npm library stays pinned to an old version, and a developer must test every pinned package by hand before touching anything. Hours add up.

Ask the vendor to read your composer.json, package.json or requirements.txt before quoting, and to list what it finds in the quote itself. Those files show how many packages are outdated and which ones no longer receive security fixes from their maintainers, which is the first thing a careful vendor checks.

A quote without that look is a guess. Guesses get padded, and padding costs you.

A developer who must read two hundred undocumented files before changing one line is billing you for the reading, and the reading repeats on every ticket. Documentation cuts that bill. A repository with a README, an ER diagram of the MySQL schema, a deployment note and a list of scheduled jobs removes most of that reading.

Test coverage matters a great deal. Without PHPUnit or Jest suites, each fix needs a manual regression pass across invoices, logins, role permissions, exports and the nightly import, and a tester repeats it every time. With them, the same check runs in minutes.

If documentation is missing, a good vendor will propose writing it in the first month, before any fix beyond the urgent ones is touched. Treat it as a one-time cost. It lowers every later invoice. Pay it early.

A single virtual server with a nightly database dump is simple to look after, because there are only two things that can break: the server and the dump. A setup with a load balancer, a queue worker, a Redis cache and three payment or courier APIs has more parts that can fail.

Each integration binds you to someone else’s software. When the courier changes its API, your code breaks even though you changed nothing, and the parcel labels stop printing on a Monday morning. Someone must watch for changes like that. Ask who.

List every outside service the application calls, with the account holder and the renewal date for each, in one table the vendor can read. Vendors price what they can see. Show them all of it.

Past tickets forecast future ones. Count the faults raised in the last twelve months, split by severity and by the module that failed, so the quote reflects real trouble spots. An application that fails weekly needs more reserved hours than one that fails twice a year, and the retainer should say so plainly.

Response time is priced separately. A reply within the working day costs less than a developer on call at night and on weekends, because someone must stay free to answer. Decide which screens genuinely stop the business when they fail, such as billing, dispatch or the gate pass printout, and ask for fast cover only on those.

Some vendors bill a fixed monthly retainer, others bill hours against a prepaid bank of time, and a few mix the two for urgent work. Neither model is better. What matters is that carried-over hours, overruns, out-of-hours rates and the notice period for ending the contract are written into the agreement before the first invoice.

Routine upkeep holds the application where it is. Upgrade work moves it forward. Many quotes cover only upkeep, and the upgrade arrives months later as a surprise project with its own budget fight and its own delay.

Ask for the backlog to be listed as a separate line: framework upgrade, PHP or Node version move, replaced libraries, security patching. Each gets an estimate and a date.

Then lay the quotes side by side in one table with the same rows, so that a vendor who skipped hosting or documentation shows an empty cell. Blanks show you the gap. Send that table back and ask each vendor to fill it in, and treat a refusal to fill a row as an answer about what the vendor will cover.