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.
