Keeping the lights on or proactive stewardship?
A Maintenance Problem Web Development Doesn’t Talk About Enough.
Ferris Bueller once said that life moves pretty fast. He was talking about bunking/wagging/skipping school in a red Ferrari, but I’ve nicked the sentiment anyway, because the web development industry has accelerated at a pace that’s left a lot of basic housekeeping behind.
I’ve said it before and I’ll say it again that I’ve worked where you work and I’ve seen what you see. The teams for which I was responsible were managing dozens of paying customers’ digital real-estate; websites, wikis, e-commerce platforms, SPAs, but rarely did they have the information to hand needed to smoothly serve them.
We had Confluence or Mediawiki pages of course, but with limited accompanying context, perhaps the names of the teams which managed each project. All of which however few people felt it was their responsibility to maintain.
Developers tended to be relied upon to carry institutional knowledge in their heads - known to us and perhaps to you as the Bus Factor alongside maintenance practices which could generously be described as reactive.
If any of this sounds familiar, read on.
Keeping the Lights On. When does it refer to something more problematic?
There’s a phrase I’ve heard from teams over the years, usually provided with a wry smile. Keeping the lights on is oft-used to describe an agency’s actual maintenance practices. The fact that it gets a knowing laugh every time should tell you something.
Controversial take: Agencies do the bare minimum to keep your website secure and up-to-date. It’s behaviour which can appear intentional from the inside but in reality it rarely is, and doing as little as possible isn’t unique to web development.
I’ve had some interesting jobs in my career; I‘ve worked at warehouses, production-lines, and shop floors, and in all of them existed a pathalogical desire to scrape-by on promises alone. It’s not just an issue exclusive to software studios, I think it appears as a feature of Human organisations in general. But in an industry where neglect can compound risk over months and years, it’s a pattern worth breaking.
As a customer, here are some signs your agency is in lights-on only mode:
You’ve never been asked about your risk profile
You’ve never signed a support and maintenance agreement — or you can’t remember the last time yours was renewed
Account management calls happen, but they’re vague; a lot of words, little substance
How support works day-to-day was never explained upfront and you never thought to ask
I’m not laying the blame entirely at the agency’s door on that last one. Solid maintenance is a two-way street. When one party doesn’t volunteer something; a contract, a schedule, or a document, the other should be asking for it.
It’s a trap! “Let’s build it in-house”
I want to address an oft-repeated phrase which I’ve heard regularly throughout my career:
“Let’s bring this in-house”
Traceable to one or more of a perceived quality, cost, or speed of execution improvement by managing software internally as opposed to paying a third-party, I’ve watched a pattern play out too many times to dismiss it.
An internal app is commissioned; built from scratch or forked or cloned from elsewhere. Once complete, and with the best of intentions, a small team - or more likely a single developer - is positioned to manage it.
But when the business needs their “resources” back for some billable work, a few predictable things happen:
The product’s backlog grows
The window of exposure widens while patches and upgrades accrue
End users lose confidence and may become vocal about it
If time and budget are genuinely and consistently allocated to the project and the people doing the work are likely to stick around, then in-sourcing can work well.
But if none of these is true, particularly if the app runs on an open source stack and “just needs the occasional update”, then it pays to be clear about what a third-party SaaS provider gives you out of the box in comparison;
zero maintenance overhead
automatic security updates
certification
SLA-bound support
SSO, RBAC, and MFA
Open Source: A Support Problem Nobody’s Solved (yet)
I’m an open source advocate. My entire career has been built on it and I’m hugely thankful for it. Without it, I might still be in one of those warehouses or factories where much of my money in my early twenties was earned. But it’s precisely because I have a close affiliation with open source that I’m able to see in which scenarios where used as a solution, it can still fall down.
There’s a segment of the technology buying community that knows exactly what open source offers and still chooses proprietary software anyway. I used to read that as risk-aversion or organisational inertia but it’s probably a lot more rational than that.
When a supported Oracle customer needs a patch, they get notified which is something that’s built into the support contract as a baseline expectation. The vendor patches, advises on upgrades, and is accountable for it.
But for software solutions built on open source, paid support beyond a handful of retainer hours is the exception rather than the rule. There still isn’t a reliable way for delivery teams to predict when an open source component baked into a customer’s $1.5 million website will hit end-of-life.
I think buyers and technologists in procurement both know this.
So we can carry on trying to persuade them that open source is superior, or we can just demonstrate that it is so, by doing better with the solutions we already manage.
What Agency Maturity Actually Looks Like
I talk about maturity in delivery organisations a lot, usually without actually using the word. So, at a basic level, a mature delivery organisation:
Has customers who are maintenance aware and agree to what that actually means
Has support agreements for every customer, whatever the project size or value
Has customer-facing ticketing systems accessible to the whole team, not just PMs
Has documented release and incident response processes which are followed
If your organisation does all of this, you’re doing better than some. But the'y’re still mere fundamentals. Doing slightly more than keeping the lights on isn’t the same as actively managing the health, or the future, of your managed applications and your customers to boot.
The next level is what I repeatedly come back to: moving from reactive support to proactive stewardship. Having visibility across the whole estate. Application health that’s measurable and ownership which is defined. These are the insights I think are needed to manage risk before it becomes an incident for some poor team member in the wee hours of the morning and the whole org at the start of the next working day.
The next level is the place where organisations bring their customers with them, where account management is informative (to customers and the team itself), and it’s where intra-org comms between traditional engineering/ops/delivery silos flow easily.
From where I’m standing, these are further away for most agencies than they should be. I won’t insult readers into thinking the concept is mechanically hard to grasp, the problem is much like anything else in an org comprising dozens of individuals: Few people are able to see the gap from the top.
I’m not selling a specific solution here. I’m merely suggesting that the investment needed to find one is perhaps overdue.
Security Vulnerability Prioritization: Beyond CVSS
When a delivery team accepts responsibility for application security as an ongoing obligation, a new question becomes increasingly necessary to ask:
“Out of the dozens of vulnerabilities surfacing daily across managed tech stacks, which ones actually matter?”
For a while, a CVSS score of 7 or above may have been the standard answer and CVSS still has a role, but as a prioritization mechanism, CVSS doesn’t account for how a vulnerable software package is actually being used inside a production application.
It’s just an indicator and teams still have to make the exploitability call themselves.
In 2019, EPSS arrived (Exploit Prediction Scoring System). It’s a machine-learning model trained on real-world vulnerability data designed to calculate the probability of a security vulnerability being exploited in the wild. An improvement over CVSS for sure, but EPSS knows nothing about your team’s specific use of an affected library, any more than a CVSS score does.
The most useful development in this space has been KEV (Known Exploited Vulnerabilities) catalogue, managed by CISA, the US government’s Cybersecurity & Infrastructure Security Agency. It’s a continuously updated list of CVEs that have been actively exploited in the wild. For software packages your team knows are in your managed applications, KEV is currently the most reliable place to start any prioritisation workflow.
So the remaining problem is discovery. How should a team identify which projects in its portfolio contain a software package at a version which is vulnerable to a newly listed CVE?
There are open source and enterprise tools that address this to varying degrees, but each requires specialist knowledge to run or their use and management precludes use by small-to-medium agencies on budget terms alone.
No tool yet provides your teams with CVSS, EPSS, and KEV to help them better prioritize.
The Path Forward: Agreement, Action, Documentation
Assuming leadership is genuinely on board, that they can see the value of improved security and risk outcomes, reduced customer churn, and making life more manageable for people at the delivery coal-face, then what should their next steps actually be?
Start with consistency. When teams are consulting the CRM just to understand the basics of an engagement, something has already gone wrong. Uptime, backups, incident response, patching and upgrades; these should look the same across every customer, regardless of project size and project value. Licensed software vendors include this as standard. There’s no good reason open-source delivery teams shouldn’t match that expectation.
Get everyone in a room. Agreement requires conversation. Teams need to align on an SLA. An SLA shouldn’t be scary or onerous. It’s just a documented understanding of what the basics of long-term maintenance actually means in practice. The security of your portfolio is a concern for your customers as well as a risk for you. Most customers will engage with you when things are framed in this way.
Those that won’t can still just sign a waiver.
Two terms worth understanding if you’re working with enterprise clients and these apply more broadly than people realise:
RPO (Recovery Point Objective)
The maximum acceptable data loss expressed in time in the event of a DR (Disaster Recovery) scenario. It’s a commitment to minimising what a customer loses.
RTO (Return to Operation)
The maximum acceptable downtime until a failed system is back up. This is a commitment to how long customers are basically left in the dark.
Neither is a bureaucratic exercise. They’re really the kind of commitments that tell a customer you’ve thought about failure and that you’ve got their backs in the event of one.
Document it. Call it inventory, classification, whatever your team will actually use, but folks need to know which projects they own and they need to know what ownership looks like. Parkinson’s Law states that work expands to fill the time available for its completion. Which means that without clarity on what responsibilities actually entail, work either doesn’t happen or drags out indefinitely.
✅ Agree
✅ Act
✅ Document
A New Kind of Tooling?
Some of what I’ve been describing points at process and workflow gaps, but there’s also a tooling gap.
The intelligence which delivery teams need to operate proactively; portfolio-wide visibility, EOL tracking, vulnerability prioritisation, health reporting and the rest of it. doesn’t exist in a form that’s accessible to most without significant investment, specialist expertise, or a level of manual effort that few are able to sustain.
Enterprise IT departments have been doing this in CMDBs for years, much of it automated. It’s a standard approach for understanding what’s in a portfolio and what state it’s in. So why are web development teams — many of whom operate inside those same enterprises — still doing it twelve different ways? Why does it often appear to buyers and customers that there’s no documented approach to maintenance alerting and patching in open-source web-dev?
My experience says it’s a combination of things: an industry that’s still maturing, agencies that haven’t made maintenance a selling point, and customers who’ve assumed too much of whoever they hired.
The question of tooling also raises a pricing question which I find genuinely interesting. Rob Walling, in his book The SaaS Playbook, describes value metric pricing: not a flat subscription, but pricing that reflects what actually varies in value between customers. For a tool targeting delivery agencies, the value metric isn’t just features; the number of applications under management combined with the number of team members who need visibility across them, is what’s important.
When project managers see the same picture engineers see, and when management can pull it as a report, then silos between AppSec, engineering, PM, and leadership can start to break down. That’s not a small thing for teams that currently rely on tribal knowledge and command-line tools to understand what they’re actually responsible for.
Conclusion
The web-development industry has treated maintenance as something that happens between billable projects, managed by whoever has a spare hour.
The consequences tend not to announce themselves; a backlog that grows or which nobody quite gets to, a customer saying everything’s fine in the monthly accounts call and then isn’t there for the next one, and a security incident that someone saw coming but there wasn’t a process for.
The distance between these and a team that genuinely manages its portfolio is not as far as it looks. It does takes agreement on what good looks like though. There are actions to put in place and discipline needed to document it.
At the end of the day, it takes treating maintenance as a deliverable in its own right.
And yes, it probably takes better tooling.
I’ve worked where you work. I’ve seen what you see. I’m building something to help fix it.
Metaport: Portfolio intelligence for delivery teams. Inventory management, EOL notification, and vulnerability discovery.