5 signs your website's codebase is quietly costing you money

Most legacy-software problems don't announce themselves. Nobody sends a memo saying "the codebase is now expensive." Instead, small frictions pile up until a change that should take a day takes two weeks, and everyone's forgotten it wasn't always like this. Here are five concrete signs worth paying attention to.

1. Every deploy requires a specific person

If there's one engineer (or one person, period) who has to be involved in every release because "they know how the deploy works," that's not redundancy, that's a single point of failure wearing a job title. It's also usually a sign the deployment process itself has never been documented or automated.

2. Dependencies are years out of date, and nobody wants to touch them

A framework or library stuck three major versions behind current isn't just a security risk, it's usually a sign that upgrading has been tried before, broke something, and got shelved. That unresolved attempt tends to get more expensive to finish the longer it's left.

3. New features take disproportionately long to ship

If a straightforward feature request takes weeks because the team has to work around fragile, undocumented parts of the system rather than through them, the codebase is actively taxing every future feature, not just this one.

4. The staging environment doesn't match production

When "it worked on staging" stops meaning anything because the two environments have quietly diverged, testing before release stops actually preventing production incidents.

5. Onboarding a new engineer takes months, not weeks

A healthy codebase lets a competent new hire ship something real within their first few weeks. If it consistently takes months before anyone new can contribute independently, that's usually not a hiring problem, it's an architecture and documentation problem.

What to do about it

None of these require a full rewrite to fix, and a full rewrite is rarely the right first move anyway. The more durable fix is usually a staged migration: shore up the deployment pipeline, bring dependencies current in controlled steps, and document the parts of the system that currently live only in one person's head. That's the kind of work we do.