Picture the weekend you finally get fed up and decide to fix it yourself. You wire up a handful of automations: incoming carrier emails get sorted, attachments drop into the right folder, a spreadsheet updates itself. It works beautifully for about four months. Then a carrier changes the layout of its emails, one automation starts filing things in the wrong place, and nobody notices until a client asks about a policy the system says does not exist. You spend a Saturday trying to remember how you built the thing in the first place.
Every agency owner who gets fed up with a legacy AMS arrives at the same fork. There are four roads out, and they are not equally good, even though they look that way at the start.
Road one: hire a developer
The instinct is reasonable. If the software does not do what you need, hire someone to make software that does. The problem is what you are actually signing up for.
A software developer is a six-figure hire. The median annual wage for software developers was $133,080 in May 2024, according to the Bureau of Labor Statistics. That is base salary. Once you add benefits, taxes, equipment, and overhead, the common rule of thumb of roughly a third on top puts the real cost somewhere north of $170,000. For that you get one person, which means your entire technology operation now has a single point of failure with a two-week notice period.
Worse, the salary is the cheap part. The build is a small fraction of what software costs over its life. In Facts and Fallacies of Software Engineering, Robert Glass puts maintenance at 40 to 80 percent of total software cost, averaging around 60 percent. You are not buying a feature. You are adopting a permanent liability that has to be fed after the exciting part is over.
And the odds are not with you. By OpenCommons' summary of the Standish Group's long-running CHAOS research, small software projects succeed roughly 90 percent of the time, while large ones succeed less than 10 percent. That sounds encouraging until you notice how projects grow. The thing you build to sort emails is small and works. The thing it becomes, once it also has to handle carrier submissions, quote comparison, and every exception in your book, is large, and large is where custom software goes to die.
Road two: stitch together tools
The lighter version is the weekend version above. No developer, just a subscription to a no-code automation tool and a free Saturday. It is genuinely cheap to start, and that is exactly the trap.
The tools connect things, but connecting is not integrating. Every automation is a point-to-point wire that assumes the format on both ends never changes, and in insurance the format on both ends changes constantly. A carrier tweaks a portal, a form gets a new field, and a wire you forgot you built goes quietly wrong. The failure mode is not a crash. It is a plausible-looking wrong answer that no one catches for weeks.
At scale, the wires become sprawl. An adjacent signal comes from Zapier, the company whose whole business is selling those wires: in a 2025 survey of enterprise leaders about AI tool sprawl, 31 percent said they were discovering new, unsanctioned AI tools running inside their own operations every month, and the costs they named most often were money wasted on redundant software and time lost to manually moving data between tools that were supposed to move it for them. Those were large enterprises studying AI tools rather than agencies stitching automations, so read it as direction, not as your exact number. The direction is what matters: the tools multiply faster than anyone tracks them, and the automations meant to save time quietly generate new work. You do not end up with a system. You end up with a tangle that was built ad hoc by whoever needed it that week, understood in full by no one, and one bad carrier change away from silently failing.
Road three: wait for your AMS
The path of least resistance is to do nothing and assume the incumbent will catch up. They are certainly trying. In October 2025, Applied Systems announced a suite of AI features layered onto Applied Epic and EZLynx, built on, in their words, more than 40 years of insurance expertise. That phrase is the tension. The AI is being layered on top of the long-standing Epic and EZLynx ecosystem, which is a different thing from a system whose core workflow was built around AI doing the work.
It also does not touch the problem agencies actually name as their worst. In the 2024 Agency Universe Study from the Big "I", dealing with multiple disconnected carrier interfaces was the number one technology issue agents reported. That is a systems-integration problem at the core of the architecture. A feature bolted onto the surface does not reach it. Waiting is not neutral. It is a decision to keep paying the current cost while hoping someone else fixes the foundation without rebuilding it.
Road four: buy the thing built for the job
The fourth road is the one that feels riskiest on day one, because it is the biggest visible change: a new system, a migration, a vendor you have to trust. It is also the one that often turns out cheaper and less fragile by year three. Buy a system built for the work, from people whose whole job is maintaining it.
The reason comes down to what your agency is actually for. Geoffrey Moore's core versus context framework, from Dealing with Darwin, draws the line between the work that differentiates you and wins clients, which is core, and the work that is necessary but does not differentiate you, which is context. For an agency, core is the client relationship and the risk judgment. Building and babysitting software plumbing is context. Moore's advice is to pour your best people into core and get context off their plate, because context done in-house drains the people who should be doing the thing only you can do.
You are a good agency owner. You are not, and do not want to be, a software maintenance shop. Every Saturday spent debugging an automation is a Saturday not spent on the relationships and the risk judgment that are the actual business.
The question that decides it
Every one of these roads can be made to work for a while, and that is the trap. The demo of the thing you built runs clean. The first month of automations goes fine. The webinar where your AMS shows off its new AI looks impressive. Then the real bill arrives, and it always arrives the same way: something you never planned for changes. A carrier reformats its forms. The developer quits. The automation nobody wrote down starts failing quietly. That is the moment the choice you made actually gets tested.
So do not ask whether you can make something that works. For a while, you can. Ask who is awake at six on a Tuesday morning two years from now, when a carrier quietly changes its portal and every submission your agency sends starts bouncing. If the answer is you, or the one developer you hired, or the one person who happened to understand the automations before they left, then you did not buy software. You hired yourself a second job.
Buy a system built and maintained for the job, and that person is not you. The maintenance, the carrier changes, the edge cases, the uptime, all of it belongs to a company whose only job is keeping it running. Your best people stay on the client and the risk. The plumbing stays somebody else's problem. That is the whole case, and it is an operating-risk case, not a matter of taste.
We built Aluna so an agency never has to become a software company to run like a modern one. Book a demo and we will show you what a purpose-built AMS looks like in practice.