Should agencies build their own website security and maintenance solutions?
Or why agencies shouldn't build their own Alpaca Management System.
We’ve been talking to agencies for quite some time. It has been, and remains a fascinating process - because we’ve gone from assuming that agency maintenance practices leave something to be desired, to having the data tell us that it is indeed so. *
Of those we’ve spoken to, we’ve found that some have almost no formal maintenance processes or reporting tools (we’re talking to these guys). Others already operate well-known application security tools for monitoring and notification (Metaport integrates with some, so we’re talking to these guys too).
But most pertinent are those agencies we’re not talking to at all. Rather, they don’t want to talk to us.
Why? Well it’s not for want of asking. It’s because they’ve cobbled together a solution themselves which appears to work for them for the time being.
Is your agency in this camp too? We’re keen to talk to you. What did you build? Out of what, and why?
Democratising software or diminishing lived experience?
It’s March 2026 and we’re very much established in the age of AI 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 want to query: 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 would 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 I what I was actually asking was that the 25% be spent thinking. Developers find not doing physical things like that really hard because in their world, key-presses == productivity.
So it would be ore than a shame if as engineering professionals, our hard-won skills, knowledge, and experience were cast aside because when considering building a tool ourselves - we’d 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” and was 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 the 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. As is the means by which software is paid for. Old school programs came in an actual box with a manual which mostly went unread. They were 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 near ubiquitous standard.
Irrespective of whether it is downloaded, installed, or web-based, software provides something which its users can not not 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 and 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). It 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, which 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, which can be done 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 software, is itself in urgent need of monitoring and maintenance.
And when this happens, we’ve 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 characterised 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 un-planned, ad-hoc fashion looks way too much like the situation our non-communicative agency friends appear to be trying to avoid.
Thanks for reading.
* We kicked-off an industry survey in early 2025 and which is still going. Give it a nudge here.
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.