Build vs. Buy for Agencies: When Custom Ops Software Wins
A practical framework for agency owners deciding when to keep SaaS, when to consolidate the stack, and when AI-built custom tools become a margin advantage.
The short answer: keep commodity workflows on off-the-shelf SaaS, consolidate the overlapping middle of your stack, and build custom software only where the workflow is your competitive advantage — usually your client portal, your delivery process, or the pipeline logic that makes your agency yours. What’s changed is the third bucket. AI-assisted development has cut the cost of internal tooling so dramatically that “we should build something” is no longer a fantasy reserved for agencies with a dev team on payroll — it’s a real option that deserves the same scrutiny as any other line item.
This is the framework we use with our own clients when the question comes up, and it starts with admitting how we all got here.
How agencies end up with 20 tools and no system
The pattern is almost universal. A problem appears — leads falling through cracks, clients emailing for status updates, delivery handoffs getting messy — and the reflex is to buy a subscription. Each individual decision is rational: the tool costs less per month than an hour of anyone’s time, it works on day one, and someone else maintains it.
The aggregate is not rational. It’s common for a small agency to be running well over a dozen subscriptions: a CRM, a project management tool, a proposal tool, a client communication layer, a time tracker, two or three automation platforms gluing it all together, and a spreadsheet that quietly overrides all of them because nobody trusts the data anywhere else.
Three costs show up that never appeared on any pricing page:
- Seat math compounds. Per-seat pricing across a dozen tools means every new hire raises your software bill in five places at once. Your ops cost scales linearly with headcount even when the work doesn’t.
- The glue becomes the system. The Zapier-and-spreadsheet layer connecting your tools is unowned, undocumented software. When it breaks, it breaks silently, and the person who built it left eight months ago.
- Your process bends to the tool. Every off-the-shelf product embeds someone else’s opinion about how agencies should work. Small mismatches get absorbed as workarounds, and workarounds are where onboarding time and delivery errors live.
We’ve written before about how this kind of quiet operational waste compounds — see Where Agency Margin Really Leaks — so here we’ll focus on the decision framework rather than the damage report.
Meanwhile, “custom software” got mentally filed under six-figure projects, six-month timelines, and a maintenance burden nobody wants. That filing was accurate in 2019. It isn’t anymore.
What AI-assisted development actually changed
We want to be precise here, because the hype version of this claim gets agencies in trouble.
What has genuinely collapsed is the cost of the build. For well-scoped internal tools — known requirements, few integrations, no exotic scale — work that once meant hiring a contract developer for an extended engagement can now come together in a fraction of the time. The debugging and iteration tail is still real, and anything with heavy integration work or fuzzy requirements will still take longer than the demo videos suggest. But the class of software an agency can realistically own — a client portal, a pipeline dashboard, a delivery checklist system wired to your actual data — has expanded enormously. Internal tools are the sweet spot for this kind of building: known users (your team and your clients), forgiving scale, and requirements you can describe precisely because you live them every day.
What has not changed: software still needs an owner. Someone has to decide what it does, notice when it breaks, and keep it aligned with how the business evolves. AI compressed the construction cost, not the ownership cost. If nobody on your team can be that owner — even part-time, even non-technically, working with a partner — that fact should weigh heavily in your decision. The equation moved; it didn’t disappear.
The three-bucket framework
When we audit an agency’s stack, every workflow lands in one of three buckets. The discipline is refusing to treat them all the same way.
Bucket 1: Keep buying — commodity workflows
If a workflow is the same at your agency as at ten thousand others, buy it and move on. Accounting, payroll, email, calendars, e-signatures, video calls, password management. There is no version of your agency that wins clients because of a better bookkeeping tool, and these categories carry compliance and security weight you do not want to own. There’s no real build-versus-buy question here — SaaS wins, full stop.
The test: would a client ever notice or care how we do this? If no, buy the boring standard option and stop evaluating alternatives every quarter.
Bucket 2: Consolidate — the overlapping middle
This is where most of the waste lives. CRM, project management, task tracking, internal docs, light automation — agencies typically run several tools whose feature sets overlap heavily, because each was bought to solve one acute pain. Before you build anything, consolidate. For most owners this is the highest-ROI move on the table, and it costs mostly attention, not money.
A practical pass: list every subscription, write down the one job you actually use each tool for, and look for tools whose one job another tool already does. In our experience, most agencies find real cuts this way — and, more valuably, end up with one place where client and pipeline data is actually true.
Consolidation also clarifies the build decision. Half the time, the “we need custom software” feeling is really a “we have five sources of truth” problem, and it dissolves once the stack shrinks.
Bucket 3: Build — where the workflow is the advantage
Build when a workflow meets three conditions at once:
- It’s client-facing or margin-critical. The canonical example is the client portal — it’s the surface clients touch weekly, and a portal shaped exactly around your delivery process is a differentiation asset no competitor can subscribe to.
- Off-the-shelf tools force real workarounds. Not cosmetic annoyances — actual manual steps, duplicate data entry, or process compromises that cost hours weekly or cause client-visible errors.
- The requirements are stable. You’ve run this process manually or on SaaS long enough to know exactly what it needs. Building is how you encode a proven process, not how you discover one. If the process still changes monthly, you’re not ready.
When all three line up, custom stops being a liability and becomes durable margin: no per-seat creep, no bending your process around a vendor roadmap, and a delivery experience that becomes part of your pitch — clients see exactly where their work stands without sending a single status-update email.
The mistakes that turn builds into regrets
A few failure modes come up repeatedly, and they’re all avoidable:
- Building bucket 1 software. Someone gets excited and rebuilds a time tracker. Now you own undifferentiated software forever. Build only where differentiation lives.
- Building to avoid a conversation. If the team won’t adopt the current CRM, they won’t adopt a custom one. Tooling doesn’t fix accountability problems — the same trap we unpack in Switching CRMs Won’t Fix Your Pipeline.
- Skipping the manual version. The best custom tools are automations of a process that already works on spreadsheets and elbow grease. If you can’t run it manually, you can’t spec it.
- No owner. Decide who answers for the tool before the first line is written. “The AI built it” is not an ownership model.
- Big-bang scope. Start with one workflow — the portal, or the pipeline, not both. Ship it, live with it a quarter, then extend. Small scopes are where AI-assisted building shines; sprawling ones are where it quietly produces things nobody maintains.
Where to start this quarter
Don’t start with the build. Start with the audit: list every subscription, bucket every workflow, and run the consolidation pass first. Most agencies come out of that exercise with a leaner stack, one source of truth, and — usually — one or two workflows that clearly belong in the build bucket. That’s a much better position to decide from than a tool-fatigue moment after the fourth pricing-page tab of the day.
If you want a starting point for the consolidation side, that’s the problem OpenAva was built around — pulling agency CRM, client work, and delivery into one system so the build decision only has to cover what genuinely makes you different. The agencies winning on ops right now aren’t the ones with the most tools or the most code — they’re the ones who decided, deliberately, where software should be rented and where it should be theirs.