DEV Community: Dcentrica

The Hidden Margin Killer: Quantifying the Cost of Reactive Maintenance in agency and studio Portfolios.

Dcentrica — Tue, 22 Sep 2026 19:22:49 +0000

Professional and managed services teams know maintenance matters. The harder question is whether they know what reactive maintenance is actually costing them.

This is one of those problems that can sit quietly in the background for a long time. A website launches. An application goes live. The team celebrates briefly and moves on to the next project. Over time, that new system becomes one more thing in a growing estate of frameworks, libraries, dependencies, hosting environments, SSL certificates, integrations, APIs, and security obligations.

Nothing looks especially urgent if you or your org has maintenance blind spots.

A framework reaches end of life (EOL). A dependency vulnerability is published. A client asks whether they are exposed. A developer has to stop planned work to investigate. A project manager has to re-scope work that now needs budgeting. Maybe a Statement of Work is required. Maybe a proposal or business case needs to be built. Someone then has to explain why something that “just worked” last week now needs time, money, and attention.

The technical fix may be a few hours, a few days, or in the case of larger upgrades and migrations, several months. The cost around the fix is usually the bigger problem.

In our whitepaper, Hidden Costs in Application Maintenance: How Proactive Agencies Win, we describe maintenance as a blind spot in agency operations. Not because teams are careless, but because the information needed to manage maintenance properly is often spread across engineering knowledge, Slack threads, spreadsheets, hosting platforms, existing application security (AppSec) tools, version control repositories, and individual memory.

Maintenance is often reactive. It starts after something fails, after a client escalates, or after a security risk becomes visible enough that it can no longer be ignored. The knowledge is also usually siloed. Developers may know where the risks are, but that does not mean project managers, account leads, delivery leads, or executives have a useful portfolio-wide view or know if a problem found in one project doesn’t also affect others.

That is where the issue stops being technical and starts becoming commercial.

Unplanned maintenance pulls people away from planned work. It creates context switching. It disrupts delivery momentum. It makes budget conversations harder. It can make an agency look less in control than it actually is.

What Reactive Maintenance Costs in Real Terms

Using conservative industry data and typical developer charge-out rates of USD $75–$150 per hour, the financial cost of ad-hoc maintenance can be modeled fairly quickly.

Take cross-portfolio end-of-life (EOL) planning as one example.

If EOL planning takes around 10 hours per project annually, spread across developers and project managers, then a 10-project portfolio represents roughly 100 hours of unplanned effort.

At USD $75–$150 per hour, that equates to USD $7,500–$15,000 per year in time that may not be properly forecast, budgeted, or recovered.

Now take cross-portfolio vulnerability review and risk analysis. If vulnerability review takes around 1 hour per project, per week, then a 10-project portfolio creates around 10 hours of recurring weekly effort. At the same charge-out range, that becomes approximately USD $3,000–$6,000 per month in avoidable cost.

That is before the wider operational cost is counted: context switching, delayed roadmap work, emergency client communication, re-planning, proposal effort, and the loss of confidence that comes when clients feel issues are being discovered late rather than managed early.

For one application, the cost may feel tolerable. Across 20, 40, or 100 maintained applications, the numbers start to look very different. This is the commercial shape of the problem.

Reactive maintenance is not just a technical risk. It is margin leakage hiding inside normal delivery operations.

Leveraging AI Makes This More Complicated at Scale

AI is making it faster to create software, scripts, internal tools, prototypes, features, and automation. That is useful, but it also means organisations may be creating more digital assets than they have maintenance discipline for.

Every new asset creates a future obligation. Dependencies need monitoring. Runtimes need patching. APIs change. Hosting environments age. Security risks emerge. AI-generated code may also introduce patterns that are harder to understand later, particularly when it was created quickly and without enough architectural context.

The AI cost model is changing as well. More AI platforms are moving toward usage-based pricing or tightening the economics around heavy use. So the cost of running and maintaining digital assets is no longer just hosting, software licences, support retainers, developer time, and security tooling.

AI usage itself becomes another cost line teams need to understand and justify.

That matters because the reactive maintenance cost is already material. Even a simple 10-project model can point to USD $7,500–$15,000 per year in unplanned EOL planning effort, and USD $3,000–$6,000 per month in recurring vulnerability review and risk analysis.

If AI increases the volume of software being created, and adds another usage-based cost layer to reviewing, analysing, remediating, and maintaining that software, visibility becomes more important, not less.

That creates a simple but uncomfortable question:

Are we creating more digital assets than we can afford to maintain well?

That is not an argument against AI. It is an argument for better visibility. Shipping faster is only useful if teams can still govern, secure, maintain, and explain what they have shipped.

The Fix is Only One Part of the Cost

A common mistake is to measure maintenance by the fix itself. That misses all the surrounding cost that customers may assume is simply “a cost of business.”

The maintenance question is no longer just

How much does it cost to fix this issue?

It is closer to

How much are we spending to discover, understand, explain, prioritise, and repeatedly rework issues we could have seen or planned for earlier?

What Changes When Maintenance is Planned

A proactive agency has a different conversation with its clients. It can see which applications are approaching end of life. It can identify which clients are affected by a vulnerability. It can plan upgrade windows before they become emergencies.

The tone of the conversation changes from,

We have a problem and need to fix this urgently

to:

We are tracking this across your environment. Here is what is coming, here is the likely impact, and here is how we recommend planning for it.

Commercially, it is significant. It builds confidence. It makes maintenance easier to budget. It gives project managers better information. It also creates a stronger basis for ongoing client relationships. Maintenance stops being only a cost centre and becomes part of the service model.

Where Metaport Fits

This is the problem we are working on with Metaport.

Metaport is designed to help agencies and digital teams see maintenance risk across the applications they manage. It brings together signals around end-of-life (EOL), dependencies, vulnerabilities, and SSL expiries, so teams can move from reactive discovery to proactive planning.

The value is in making maintenance risk visible at the portfolio level, in a way project managers, delivery leads, and leadership can actually use.

Because the hard part is not always fixing the issue. Often, the hard part is seeing it early enough to have the right conversation, with the right person, at the right time.

Want to stop maintenance from creeping up on you?

Try Metaport

Software End of Life vs End of Support (2026)

Dcentrica — Tue, 22 Sep 2026 19:09:51 +0000

Digital teams don't struggle to understand what end of support or end of life mean in theory. They struggle with the weight of knowing what such signals mean in practice when responsible for an entire portfolio of websites and applications.

A single outdated component on just one website might be manageable, but across dozens of them, it's something else entirely. Planning, delivery, budgeting, and security are all affected, as are your customer conversations.

The distinction between software end of life and end of support matters because definitions affect how your teams prioritize work, where risk buils-up across your digital portfolio, and how early you need to act.

End of support vs end of life

End of support (EOS) means software still "works", but its vendor or maintainer has signaled they're no longer actively supporting it.

What this means practically is that websites become increasingly vulnerable to a security incident or become susceptible to degraded performance because there's:

no bug fixes (may vary by vendor)
Sometimes or no security fixes (may vary by vendor)
no feature development
no technical or vendor support

Essentially, the software itself may continue to be available alongside its documentation, but users or consumers of it can have no confidence of it's ongoing compatibility.

End of life (EOL) on the other hand goes a step further. It's a hard-stop, a signal that "this software should no longer be used". The software itself or a specific version of it has been retired altogether. Continuing to run it becomes harder to justify over time.

Building on End of Support, what this means practically is

no bug fixes (at all)
no security fixes (at all)
no feature development (at all)
not available in some ecosystems, repositories, or marketplaces

For website teams, the practical difference is timing:

End of support is usually the point where risk starts to increase.
End of life is the point where that risk becomes much harder to accept.

These may sound like minor distinctions, but it does change how you plan.

Why things become harder across multiple apps and websites

If you manage one project, life-cycle issues can often be dealt with as they come up. You can arguably be reactive to a point. But when you're responsible for ten, fifty, or hundreds, then that approach doesn't hold up for long.

Different projects can run different CMS versions, plugins, frameworks, hosting setups, runtimes, and third-party integrations. All of these have their own support timelines and upgrade paths and each carries a different levels of risk depending on what the project does and who's relying on it.

That is where software end of life tracking is important.

Without a clear view across the portfolio, teams end up asking the same questions over and over:

Which sites are approaching end of support?
Which clients need an upgrade conversation this quarter?
Which issues are genuinely urgent, and which can wait?
Where is the biggest concentration of risk?
What should the team focus on first?

When those answers are hard to see, maintenance is reactive. Work is driven by whatever breaks, whatever becomes critical, or whatever someone happens to notice first.

Why spreadsheets and manual tracking only get you so far

Most teams start in a reasonable place. A spreadsheet, wiki or even a configuration management database (CMDB). Maybe a few reminders in a ticketing system, shared calendars or even a system developed in-house. Whatever it is, teams are reliant on an occasional technical audit and a hope that insights are forthcoming.

This can work for a while. But once you're managing multiple projects across different clients, teams, products, or business units, it gets harder to trust and harder to maintain as you scale.

The challenge isn't just in the collection of end-of-life data, it's also in turning that data into something usable by you and your team.

A spreadsheet might tell you a framework version is old, but it won't tell you:

which live websites or applications are affected
how close each component is to end of support
where the highest business or security risk sits
how work should be sequenced across the portfolio
what needs to be raised with clients or stakeholders now

A life-cycle date on its own however is just reference information, its value comes from understanding what that date means in the context of the projects; the websites and apps you actually manage.

Resources like Is It End of Life tool and others are useful for infrequently checking support status across common technologies. But checking a date is only part of the problem. You still need to know how that date affects your portfolio.

So, when should you update software?

Best practice, before support ends (End of Support), not after.

That sounds obvious, but in reality the right timing depends on more than the life-cycle date itself.

Support timelines

If a CMS, framework, or runtime has a published support end date, that should shape your overall planning horizon. A source like isitendoflife.com can help confirm whether a version is still supported, but it does not help create the plan for you, and gathering this information is time consuming over a wide digital portfolio.

Business criticality

Not every website or app matters equally. A low-risk campaign site and a core business platform may not be treated the same way. The more important the site, the less risk tolerance there should be for unsupported components.

Upgrade complexity

Some updates are minor. Others need code changes, regression testing, infrastructure changes, or stakeholder coordination. The harder the upgrade path, the earlier it needs to show up in planning as these activities will often take weeks or months of your team's capability.

Portfolio scale

If several projects are heading toward support deadlines at the same time, the issue stops being purely technical. It becomes a delivery and capacity problem as well.

Your clients may see this too if you are too busy on what you feel is higher priority, so reputational risk comes into play.

Security and compliance expectations

For some teams, unsupported software is not just untidy maintenance. It can create security, audit, governance, or client assurance issues.

A useful rule of thumb is not to wait until software is obviously obsolete. The better time to plan is while support is still active and the window to act is still manageable.

What teams should actually be tracking

A life-cycle date is only the starting point.

For teams that are already reasonably mature, the more useful question is not just whether a component is supported. It is whether they can see the operational implications clearly across the projects they manage.

This means tracking:

the technologies each website or app is running
the components are approaching end of support
which components are already end of life
how critical each affected website or app is
how difficult the upgrade path is likely to be
how soon action needs to happen
how many sites are exposed to the same issue

Your team might fully understand end of support vs end of life as concepts and still be carrying more risk than they realize because they're unable to see where those conditions exist across a portfolio.

Managing multiple projects without losing sight of maintenance risk

When people ask how to manage multiple projects more effectively, life-cycle visibility is a big part of the answer.

Managing multiple projects is not just about content governance, uptime, or design consistency. It is also about knowing where maintenance risk is building, and being able to respond before that risk turns into disruption.

A more sustainable approach usually looks something like this:

Keep a current inventory

Know what each project is running across CMS versions, plugins, frameworks, runtimes, hosting dependencies, and major integrations.

Map life-cycle status

Track which components are supported, which are nearing end of support, and which are already end of life.

Prioritize by impact

Not every issue needs immediate action. Prioritize based on business criticality, security exposure, effort to remediate, and how broadly the issue appears across the portfolio.

Plan ahead

Use life-cycle visibility to shape quarterly or half-yearly maintenance planning, rather than waiting for urgent issues to force the work onto the roadmap.

Communicate clearly

Make it easier to explain what is coming, what matters now, and where clients or stakeholders should expect investment.

This is where a portfolio-level view becomes far more useful than isolated checks.

It is one thing to know a version is unsupported. It is another to know which websites or apps are affected, how urgent the issue really is, and how that work fits into the rest of your maintenance programme.

Turning life-cycle data into actual planning

Knowing that a version is approaching end of support is useful.

Knowing which ten projects are affected, which three carry the most risk, and which two can reasonably wait until next quarter is much more useful.

That is the difference between reference data and operational visibility.

For teams managing multiple projects, life-cycle information becomes much more valuable when it helps answer questions like:

What needs action now?
What can wait?
Where are we carrying the most risk?
Which upgrade conversations need to happen this month?
How do we stop maintenance becoming reactive?

Rather than being just another reference source for life-cycle dates, Metaport is designed to help delivery and portfolio managers see maintenance risk across the projects they manage, identify where attention is needed first, and plan work more confidently.

Metaport achieves this providing tools such as the App Planner, Policy-based notification and the Application Health Report for each application.

We will continue to build new features that focus on these questions, and we'll continue to not fall into the "AppSec tool" trap. All the while we invest in meaningful integrations to compliment tools you are already using at a technical layer such as Dependabot, JIRA, DependencyTrack, Redmine, GitHub and GitLab.

For agencies and digital teams that have outgrown spreadsheets and one-off audits, Metaport points to a more practical way of turning life-cycle and dependency information into portfolio-wide planning, risk awareness and prioritization.

Some Final thoughts

The difference between end of support and end of life matters more than many of us think, and for teams which manage multiple projects, the biggest issue is visibility.

End of support is usually the point where risk starts rising.

End of life is where deferral is increasingly difficult to defend.

The challenge is being able to see those signals clearly across the portfolio before they turn into problems which teams need to react to (as opposed to plan for).

That is why software end of life tracking matters in practice. Better visibility leads to better planning, better prioritization, and better conversations with clients and stakeholders.

If your delivery leads are already checking support dates by interrupting your developers, spending hours manually curating spreadsheets, the next step is being able to see what those dates actually mean across the projects you manage.

That is exactly the kind of visibility Metaport is built to provide.

Do you work in a digital agency? Tell us how you're thinking about these problems inside your own organisation.

If you want to level-up your own agency or team's website and application security monitoring, alerting, and planning, then check out Metaport here.).

Health checks are integral to website maintenance programmes

Dcentrica — Tue, 05 May 2026 21:52:10 +0000

Every company seeks stable, predictable revenue. And for agencies, studios, and in-house delivery teams the cyclical workflow makes that especially critical:

Specification → Design/Build/Test → Launch → Next project

When agencies treat maintenance as an afterthought, they leave revenue on the table and risk reputation damage if an incident occurs. In today's AI‑driven world - where vibe‑coding, spec driven development (SDD), and agent orchestration accelerate delivery, then simply "keeping the lights on" after launch is no longer sufficient (if indeed it ever was).

Just as human developers benefit from peer review, AI‑generated code also needs a systematic review process. By embedding ongoing health checks and post‑launch stewardship into the delivery pipeline, agencies turn maintenance into a revenue‑generating, risk‑mitigating advantage.

Predictable revenue as a component of consistent delivery

Agencies thrive on mature, predictable revenue, and that starts with a maintenance program that customers value and rely on. By keeping digital products under active, ongoing care, just as we would with physical assets, businesses reduce risk and unlock growth.

A proactive approach tackles three often‑overlooked challenges:

Software End‑of‑Life (EOL): Updating libraries, frameworks, and servers before support ends eliminates surprise upgrades and migration costs, keeping services smooth and uptime high.
Security Posture: Regularly patched software blocks attackers, protects data, and preserves brand reputation, turning potential fines and breach expenses into savings.
SSL Certificate Renewal: Timely reminders, as well as automated renewals prevent "Not Secure" warnings in browsers, sustains SEO/GEO rankings, and maintains conversion rates, freeing teams to focus on planned initiatives.

Providing a health‑check for every managed application which covers these three indicators, gives agencies and their customers a clear, data‑driven picture of risk, reinforcing confidence and driving steady, predictable revenue.

Why health metrics strengthen maintenance agreements

A maintenance agreement isn't a cure‑all, and major upgrades are rarely covered because of upfront costs and limited end-of-life (EOL) data. Still, modern contracts are already tying performance to clear metrics such as Return To Operation (RTO) and Recovery Point Objective (RPO), priority‑based response times, and expiry‑date windows. So adding agency‑specific health data is both feasible and valuable.

The key is in presenting that data in the customer's language. When a customer asks, "Do we really need this?" the answer should focus on the protective benefits rather than the expense:

Business continuity: Up‑to‑date software, licenses, and certificates keep operations running smoothly.
Regulatory compliance: Continuous compliance avoids costly audits and penalties.
Brand reputation: A secure, reliable service reinforces trust with users and partners.

When health metrics are displayed in concise reports which include executive summaries, clear recommendations, and a side‑by‑side view of the current state versus the cost of doing nothing, customers can see the tangible value. The maintenance line item then becomes a logical, even essential, investment in stability and growth.

How a rapid health check works (and why it's valuable)

A health check for a typical midsize website or web‑app can be compiled in less than a day, making it a practical, repeatable component of any agency's maintenance routine.

Data collection & cross‑referencing: Every library, framework and O/S version is matched against vendor support calendars to surface upcoming end‑of‑life dates.
Scoring model: The system weighs vulnerability severity, business impact of impending EOL dates, and SSL‑certificate timelines to generate a single, easy‑to‑read Health Score.
Executive summary: The score is visualised as green (on‑track), amber (needs attention), or red (at risk), giving leaders an instant view of application health.
Recommendations summary: A concise "fix‑now" list is paired with a risk‑impact brief that outlines the benefits of timely remediation.

Because metrics are expressed as concrete numbers or clear "stamps" (e.g., "3 critical CVEs, framework EOL in 24 months, SSL renewal in 30 days"), the report transforms abstract concerns into specific agenda items for the next customer account meeting.

The result is a proactive road-map that protects continuity, strengthens compliance, and builds confidence in the digital product's long‑term performance.

Application health as a strategic benefit

A health‑check report gives agencies a natural up-sell path, differentiates them from competitors, and boosts customer retention. Customers who see continuous value rarely churn after the first project.

Risk scores can be fed straight into customers' risk registers, satisfying auditors and board members, while the recommendations give them enough foresight to budget upgrades proactively instead of scrambling at the last minute.

Most importantly, knowing their website or app will stay secure, compliant, and performant underpins marketing campaigns, drives conversions, and strengthens overall trust.

We call a one‑day turnaround "fast"; from the customer's view, consistent delivery is the next biggest advantage.

Embedding health reporting into a website maintenance programme

A solid maintenance programme is built around recurring snapshots that capture health‑check findings, risk levels, and clear actions. Typical alerts look like:

"Two critical CVEs. Patch within 48 h."

"Framework reaches end‑of‑life in Oct 2026. Start migration planning this quarter."

"SSL certificate expires 15 Jun 2026. Renew by 1 Jul to avoid browser warnings."

By weaving health checks into support contracts, agencies turn a one‑off service into an ongoing partnership. And with the right tooling, reports are generated immediately and automatically, slashing production time and cost while still providing a billable and value‑driven deliverable.

A call to action for teams

Standardise the health check: Build a repeatable workflow and embed it into your delivery pipeline. It can be as simple as a bullet‑list in a wiki; elegance isn't the name of the game but consistency is.
Turn the first check into a teaching tool: Show customers how a regular "website‑maintenance" review safeguards their revenue. Price the value, not the labour, and position the contract fee as a risk‑transfer.
Showcase the report: Publish anonymised examples on your website and company LinkedIn page. Demonstrating real‑world insights builds credibility and even draws-in new business.

Closing thoughts

Security‑related incidents are climbing every year, and a single breach can erase months of SEO, GEO, and brand investment.

When software components are refreshed as often as you get a haircut, website and application health is no longer an optional pillar of any agency's digital strategy.

A disciplined maintenance programme anchored by regular health checks and a clear, actionable report delivers three simultaneous advantages:

Protects both the customer's and the agency's business from costly downtime and compliance gaps.
Creates a sustainable revenue stream by turning reactive fixes into proactive stewardship.
Builds trust, converting one‑off projects into long‑term partnerships.

If your agency still treats post‑launch support as an afterthought, you and your customers may be one incident away from a pretty rough day.

Take the first step today: run a health audit on a recent launch, share the findings with the customer, and watch the conversation shift from "extra cost" to "strategic investment."

Software End of Life vs End of Support (2026)

Dcentrica — Tue, 21 Apr 2026 21:53:57 +0000

...And What It Means When You're Managing Multiple Websites and Applications

Your digital team doesn't struggle to understand what end of support or end of life means in theory. What they struggle with is the weight of knowing what these signals mean in practice when they're responsible for an entire portfolio of websites and applications.

A single outdated component on just one website might be manageable. But across dozens of them, it becomes something else entirely. Planning, delivery, budgeting, and security are all affected, as are customer conversations.

The distinction between software end of life and end of support matters because definitions affect how your teams prioritize work, where risk is building across your digital portfolio, and determines how early you need to act.

End of support vs end of life

End of support (EOS) means software still "works", but its vendor or maintainer has signaled that they no longer actively support it.

What this means practically is that websites and applications become increasingly vulnerable to a security incident or become susceptible to degraded performance because there's:

no bug fixes (may vary by vendor)
Sometimes or no security fixes (may vary by vendor)
no feature development
no technical or vendor support

Essentially, the software itself may continue to be available alongside its documentation, but users or "consumers" of it can have no confidence of it's ongoing compatibility.

Building on End of Support, what this means practically is

no bug fixes (at all)
no security fixes (at all)
no feature development (at all)
not available in some ecosystems, repositories, or marketplaces

For website teams, the practical difference is timing:

End of support is usually the point where risk starts to increase.

End of life is the point where that risk becomes much harder to accept.

These may sound like minor distinctions, but it does change how you should plan.

Why things become harder across multiple websites and applications

If you manage one website, life-cycle issues can often be dealt with as they come up. If you're responsible for ten, fifty, or hundreds, then that approach doesn't hold up for long.

Different websites are often running different CMS versions, plugins, frameworks, hosting setups, run-times, and third-party integrations. All of those have their own support timelines and upgrade paths. Each carry different levels of risk depending on what the site does and who's relying on it.

That is where software end of life tracking starts to matter.

Without a clear view across the portfolio, teams end up asking the same questions over and over:

which sites are approaching end of support?
which clients need an upgrade conversation this quarter?
which issues are genuinely urgent, and which can wait?
where is the biggest concentration of risk?
what should the team focus on first?

When those answers are hard to see, maintenance is reactive. Work is driven by whatever breaks, whatever becomes critical, or whatever someone happens to notice first.

Why spreadsheets and manual tracking only get you so far

Most agencies start in a reasonable place. A spreadsheet, wiki or even a configuration management database (CMDB). Maybe a few reminders in a ticketing system, calendars or even a system developed in-house (maybe don't do that). Whatever it is, teams are reliant on an occasional technical audit and a hope that insights are forthcoming.

This can work for a while. But once you're managing multiple websites across different clients, teams, products, or business units, it gets harder to trust and harder to maintain as you scale.

The challenge is not just in the collection of end-of-life data, it's also in turning that data into something usable.

A spreadsheet might tell you a framework version is old. It usually does not tell you:

which live websites or applications are affected
how close each component is to end of support
where the highest business or security risk sits
how work should be sequenced across the portfolio
what needs to be raised with clients or stakeholders now

A life-cycle date on its own is just reference information. The value comes from understanding what that date means in the context of the websites you actually manage.

Resources like our Is It End of Life tool are useful for checking support status across common technologies. But checking a date is only part of the problem. You still need to know how that date affects your portfolio.

When should you update libraries and components then?

Best practice, before support ends (End of Support), not after.

That sounds obvious, but in reality the right timing depends on more than the life-cycle date itself.

Support timelines

Business criticality

Not every website matters equally. A low-risk campaign site and a core business platform may not be treated the same way. The more important the site, the less risk tolerance there should be for unsupported components.

Upgrade complexity

Portfolio scale

If several websites are heading toward support deadlines at the same time, the issue stops being purely technical. It becomes a delivery and capacity problem as well.

Your clients may see this too if you are too busy on what you feel is higher priority, so reputational risk comes into play.

Security and compliance expectations

For some teams, unsupported software is not just untidy maintenance. It can create security, audit, governance, or client assurance issues.

A useful rule of thumb is not to wait until software is obviously obsolete. The better time to plan is while support is still active and the window to act is still manageable.

What teams should actually be tracking

A life-cycle date is only the starting point.

This means tracking:

the technologies each website is running
the components are approaching end of support
which components are already end of life
how critical each affected website is
how difficult the upgrade path is likely to be
how soon action needs to happen
how many sites are exposed to the same issue

A team might fully understand end of support vs end of life as concepts and still be carrying more risk than they realize because they cannot see where those conditions exist across the portfolio.

Managing multiple websites without losing sight of maintenance risk

When people ask how to manage multiple websites more effectively, life-cycle visibility is a big part of the answer.

Managing multiple websites is not just about content governance, uptime, or design consistency. It is also about knowing where maintenance risk is building, and being able to respond before that risk turns into disruption.

A more sustainable approach usually looks something like this:

Keep an up-to-date website and application inventory

Know what each website is running across CMS versions, plugins, frameworks, run-times, hosting dependencies, and major integrations.

Map life-cycle status

Track which components are supported, which are nearing end of support, and which are already end of life.

Prioritize by impact

Not every issue needs immediate action. Prioritize based on business criticality, security exposure, effort to remediate, and how broadly the issue appears across the portfolio.

Plan ahead

Use life-cycle visibility to shape quarterly or half-yearly maintenance planning, rather than waiting for urgent issues to force the work onto the roadmap.

Communicate clearly

Make it easier to explain what is coming, what matters now, and where clients or stakeholders should expect investment.

This is where a portfolio-level view becomes far more useful than isolated checks.

It is one thing to know a version is unsupported. It is another to know which websites are affected, how urgent the issue really is, and how that work fits into the rest of your maintenance programme.

Turning life-cycle data into actual planning

Knowing that a version is approaching end of support is useful.

Knowing which ten websites are affected, which three carry the most risk, and which two can reasonably wait until next quarter is much more useful.

That is the difference between reference data and operational visibility.

For teams managing multiple websites, life-cycle information becomes much more valuable when it helps answer questions like:

what needs action now?
what can wait?
where are we carrying the most risk?
which upgrade conversations need to happen this month?
how do we stop maintenance becoming reactive?

Rather than being just another reference source for life-cycle dates, Metaport is designed to help delivery and portfolio managers see maintenance risk across the websites they manage, identify where attention is needed first, and plan work more confidently.

Metaport achieves this providing tools such as the App Planner, Policy-based notification and the Application Health Report for each application.

We will continue to build new features that focus on these questions, and we'll continue to not fall into the 'AppSec tool' trap. All the while we invest in meaningful integrations to compliment tools you are already using at a technical layer such as Dependabot, JIRA, DependencyTrack, Redmine, GitHub and GitLab.

Some final thoughts

The difference between end of support and end of life does matter.

But for teams managing multiple websites, the bigger issue is not definition. It is visibility.

End of support: Usually the point where risk starts rising.
End of life: When deferral becomes much harder to defend.

The challenge is being able to see those signals clearly across the portfolio before they turn into urgent problems.

That is why software end of life tracking matters in practice. Better visibility leads to better planning, better prioritization, and better conversations with clients and stakeholders.

Do you work in a digital agency? We'd love to know how you're thinking about your own internal systems.

If you want to level-up your own agency's website and application monitoring, alerting, and planning, then be among the first to know when Metaport SaaS arrives.

But don't take our word for it, have a look at it yourself and let us know what you think.

Should agencies build their own website security and maintenance solutions?

Dcentrica — Mon, 20 Apr 2026 01:26:18 +0000

Or: Why agencies shouldn't build their own Alpaca Management System.

We've been talking to agency development teams for quite some time and it remains a fascinating process. We've gone from assuming that studio and agency maintenance practices leave something to be desired, to having the data tell us they are. *

Of those companies we've spoken to, we found that some have almost no formal maintenance processes or reporting tools at all (we're talking to these guys). Others already operate well-known application security tools for monitoring and notification.

But most pertinent are those agencies we're not talking to at all. Rather, they don't want to talk to us.

Why? Because they've cobbled together a solution themselves which appears to work for them for the time being.

It's April 2026 and the age of AI is very much upon us, where practically anyone can build and deploy a software application in a matter of days.

There's a story being told of the decreasing existential moat supposedly surrounding traditional software and SaaS providers which we'd like to drill into: Does self-managed software - built with the help of AI or otherwise - really spell the end of the traditional SaaS? Or are we collectively missing the obvious?

When I was a senior developer, I'd advocate that my team allocate at least 25% of their estimates to doing nothing at all.

OK, that's not strictly true. Developers are knowledge workers, so what I was actually asking was that the 25% be spent just thinking, something developers find hard to do in front of a keyboard because in their world, key-presses == productivity.

So it would be more than a shame if as engineering professionals, a developer's hard-won skills, knowledge, and experience were cast aside because when considering building a tool ourselves - we'd have fallen at the first hurdle - not thinking too deeply first.

Back in the day

Going back to first principles, it's pertinent to ask why does SaaS as a category of software even exist? And while we're at it, we might equally ask why anyone uses software at all?

Software didn’t used to be so-named. It was commonly referred-to as a program, only available for install on a desktop PC via a floppy disk. Later it was available via the upstart CD-ROM, and later still came the internet which provided the ability to download all that you needed (and much that you didn't, but did anyway).

SaaS is just the most modern incarnation of software-programs along these same principles we've been used-to for decades. Prior to the relatively modern era - 2010 and after, we had "Application Service Providers" (ASP), "Web-based Software", and "Cloud Applications" to name just three.

Apart from the name; software upgrades, new features, bug-fixes, and design tweaks are provided to users with the same minimal amount of effort required. The same can be said of how software is paid for. Old school programs came in a physical box with a manual which mostly went unread, and was purchased from a physical shop.

The main difference is that users no longer need to exert any physical energy downloading or installing anything (pulling out a company credit card doesn't count). For products and services offered over the web, the subscription based payment model has since become the ubiquitous standard.

Irrespective of whether it's downloaded, installed, or web-based, software provides something which its users cannot do, don't want to do, or can do vastly more efficiently than they alone can ever do. And it's among these three advantages where the software value proposition lies, a proposition predicated on something being cheaper, faster, or less hassle to pay someone else to manage, than it is to do otherwise.

Were Alpacas the way forward?

I once visited an Alpaca farm in the early 2000s. I got talking with the owner who quietly disclosed to me that only half of his income derived from farming the animals themselves.

His further disclosure as to where the other half came from will go with me to my grave:

Alpaca Management System!

This guy had developed alpaca management software and he had a monopoly on the market (it was the only such software in existence at the time). The software was distributed via CD-ROM and when a new version was released, it was just sent out via snail-mail.

Alpaca have unique characteristics which owners and farmers need help with in order to get the most (money) out of the animals which the system provided to its users, something the users alone could not (easily) provide for themselves.

From Alpaca to AI

The messaging from AI providers and those engineers at the bleeding edge of agentic AI and AI-powered software development, seems to be that everyone is either going to build - or should soon be in a position to build - their own Alpaca Management Systems.

But anyone who's built software professionally for any length of time should have a few questions by now. Chief among these for us is to ask who (or what) is responsible for the things we currently pay traditional software providers to do on our behalf?

Assuming that an AI is never asked to "mark its own homework" by designing, building, and testing its own output, then the most suitable candidate is someone with hands-on experience in managing software maintenance, performance, APIs, platform and framework upgrades, as well as UI redesign work.

An experienced software engineer employed as an internal agency resource for example.

I think it's useful to ask what we think AI should really be doing for us. When something is capable of assisting in the build, test, and deployment of software, and doing so faster than any traditional delivery team, and when anyone can build software to a specification, doesn’t the proverbial rising tide raise all boats, not just your own?

And where is the business left whose value proposition is perhaps predicated on faster time-to-market as a result of software built in-house, when their competitors can do exactly the same thing themselves and at the same speed?

While everyone is seemingly focused on a race to the bottom, what actually happens to the software under production when the internal resource - the one hand-holding the AI - is inevitably requested to do internal, billable work?

We've seen what happens when the very systems agencies have commissioned to monitor and report on the maintenance standing of customer's websites and applications is itself in urgent need of monitoring and maintenance.

When this happens, we'll have arrived at an interesting purgatory which previously existed at the tail-end of the installable software era, and at the onset of ASP/Web-based/SaaS era. An era characterized by Frankensteinian ticketing systems, internal search engines, and where customer data was stored on intranets.

Maybe an AI assistant could be deployed to remedy the situation. But to do so in such an unplanned, ad-hoc fashion looks way too much like the situation our non-communicative agency friends appear to be trying to avoid.

We kicked-off an industry survey in early 2025 and which is still going. Give it a nudge here.

Do you work in a studio, development or agency team? We'd love to know how you're thinking about your own internal systems.

If you want to level-up your own agency's website and application monitoring, alerting, and planning, then be among the first to know when Metaport SaaS arrives.