Someone told me recently, with real pride, “we built it ourselves in a weekend.”
And honestly? I loved it. I still do. A People team that opens a laptop and builds something instead of sitting through a fourth vendor demo has learned more about their own process in two days than a procurement cycle would teach them in two quarters. Building before buying is one of the healthiest instincts I’ve seen emerge in People and Talent Ops in years. If that’s you, keep going.
But I have to say the uncomfortable thing, because nobody else seems to be saying it:
A prototype is not an operating model. And most of what’s being built this year has been built as a prototype dressed up as a system.
I’ve watched this film enough times to know how it ends. Let me tell you how it goes, and then let me tell you what to do differently — because the fix isn’t “stop building.” The fix is to build like someone who’s seen the sequel.
The Friday-afternoon build has a predictable death
Here’s the lifecycle, and I’d bet money you’ve seen at least half of it.
Someone builds a clever automation on a Friday afternoon. It works. It genuinely saves the team hours. Word gets around, people start relying on it, and within a few months it has quietly become mission-critical — without anyone ever deciding it should be.
Then the cracks. Only one person actually understands how it works. It was never documented, because documenting a Friday hack feels absurd at the time. The business grows. You hire into three new countries, each with its own leave rules and pay logic and data-protection regime that the original build never imagined. You acquire a company, and suddenly there’s a second HRIS and a second payroll provider that the automation was never designed to talk to.
And the thing that saved you time last year is now the bottleneck everyone routes around. The person who built it has moved teams, or moved on. Nobody can safely change it, so nobody does. It becomes a small, load-bearing piece of technical debt with a human single point of failure attached.
That’s expensive. And here’s the part I really want to land: it’s not expensive because you built it. It’s expensive because it was never architected to survive growth.
This isn’t a hunch. It’s the best-documented failure in automation.
I want to give you some numbers, because I think they make this stick in a way that my opinion alone can’t.
The most quoted figure in the automation world is EY’s: 30 to 50% of initial RPA projects fail. That’s not a fringe statistic. It’s been the industry’s open secret for the better part of a decade.
But the deployment failure isn’t even the interesting part. The scaling failure is. More than 50% of RPA projects fail to grow beyond 10 bots, and more than 70% plateau at fewer than 50. Read that again. The problem isn’t that people can’t build automations. They build plenty. The problem is that the automations don’t survive contact with growth. They stall the moment the organisation gets more complex than the day they were written.
And why do they die? Not because the technology malfunctions. Around 70 to 75% of RPA’s total cost goes to implementation, maintenance and support — versus only 25 to 30% on the actual licensing. The build is the cheap part. Keeping the thing alive as the world changes around it is where the money — and the misery — actually lives. As one analysis put it bluntly, these projects don’t fail because the bots break; they’re symptoms of architectural brittleness.
Here’s my favourite finding, because it’s the one that should make every People leader sit up. Deloitte tracked how many organisations had scaled automation to any real degree — 50 or more automated processes. Between 2017 and 2018, that number crept from 3% to 4%. A full year of enterprise effort, billions in spend, and the share of companies that actually scaled moved by a single percentage point.
That is what happens when you build without architecting. At the population level. For a decade.
“But this time it’s AI, so it’s different.” It isn’t. It’s worse.
I can hear the objection, because I hear it constantly: that’s old robotic-process-automation stuff. We’re using AI now. AI is flexible, it handles the messy cases, it’s not brittle like those old rule-based bots.
All true. And it changes nothing about the core problem. If anything, it raises the stakes.
McKinsey’s projection is the one I’d tattoo on the wall of every People team experimenting with agents right now: 40% of agentic AI initiatives could be abandoned by 2027 — not because the agents fail at their tasks, but because organisations lack the frameworks to safely deploy autonomous decision-making at scale.
Sit with that. The failures ahead of us won’t be technical. They’ll be governance failures. The AI will work fine. What’ll be missing is the architecture around it: who decides what the agent is allowed to do without a human, how you audit the decisions it makes, who owns it when it gets one wrong. The exact questions a weekend build never asks.
So no — moving from rule-based automation to AI doesn’t rescue you from this trap. It hands you a more capable tool and a bigger blast radius. A brittle rule-based bot fails loudly and obviously. A poorly-architected AI system fails quietly, plausibly, and at scale, making confident decisions about real people that nobody designed it to be trusted with.
The distinction nobody names
Here’s the line I keep coming back to, and it’s the whole point:
There is an enormous difference between building something that solves today’s problem and designing something that still works through scale, expansion and M&A.
The first one is fast, useful, and exactly right for the company you are this quarter. The second is designed for the company you’re becoming. Both are valuable. But they are not the same skill, and pretending they are is why so much good work quietly rots.
Anyone can build an automation. Very few people build systems that survive growth. That’s not a knock on the builders — it’s just a different discipline, and it’s the one almost nobody is teaching.
So here’s what “architecting” actually means in practice. Three principles. None of them require you to slow down your prototyping. They just change what you build.
1. Design for the edges, not the average
The Friday build is optimised for the company you are today: one HRIS, one country, today’s headcount. Architecture assumes the edges you can already see coming.
Assume a second HRIS and a second payroll. You will either acquire a company or switch providers — probably both, eventually. Build so that a new system plugs in, rather than so that everything breaks the day it arrives.
Assume more than one country. Different leave rules, different pay logic, different data law. Design the exceptions in from day one, because retrofitting internationalisation into a system built for one jurisdiction is a rebuild, not an update.
Assume ten times the volume. If the process only works because someone eyeballs every case, it will not survive scale — it’ll just convert growth into an ever-longer queue of manual review. The moment a human has to touch every instance, you haven’t automated the work. You’ve hidden it.
2. Kill the single point of failure
If one person understands how something works, that’s not an asset. It’s a risk wearing an asset’s clothing.
Document the logic, not just the steps. Anyone can write down what the automation does. What matters is why it decides what it decides — the rules underneath — because that’s what the next person needs in order to change it safely without detonating something downstream.
And make it legible to the whole team. This is the one I feel most strongly about. A system that only its original builder can touch isn’t really a system. It’s a hostage situation with a friendly face. The builder goes on holiday and the team holds its breath. The builder leaves and a piece of your operation goes dark. You did not build resilience; you built a dependency and called it efficiency.
3. Separate the logic from the tool
This is the most important one, and the most ignored.
Your rules — how you level people, how you escalate a case, what your policy actually is — are yours. They should not live trapped inside one vendor’s platform. Tools change. Your logic shouldn’t have to change with them.
Build so you can swap a tool without a rebuild. The day you change HRIS should not be the day all your automations die. If it is, you didn’t build on the vendor — you built inside it, and you’ve handed them a quiet veto over your ability to ever move.
And keep the capability in-house. If the only people who understand how your process works are on the vendor’s payroll, you don’t own your own process. You’re renting it, and the rent goes up.
The mindset, in one line
I tell every People team the same thing: prototype fast, learn quickly, but architect for the business you’re becoming — not the one you are today.
Build the weekend hack. Seriously, build it. Learn from it. Then, before it quietly becomes load-bearing, take a breath and ask the boring, unglamorous questions that separate a prototype from a system. What happens when there are two payrolls? What happens when the builder leaves? What happens when we swap the tool? What happens at ten times the volume?
The numbers are unambiguous about what happens if you don’t ask. Somewhere between a third and a half of these efforts fail outright. The overwhelming majority never scale. And the next wave — the AI one — is projected to fail for reasons that have nothing to do with the technology and everything to do with the architecture we’re not building around it.
The good news is that this is a choice. The failure isn’t inevitable, and it isn’t about talent. It’s about whether you designed for growth before growth arrived, or hoped the thing you built on a Friday would somehow scale itself.
It won’t. It never does. But you can build the one that does.