Build vs Buy: The AI Automation Decision Framework

A client called last month with a familiar question. They were running a 22-person professional services firm, losing about 15 hours a week to manual reporting and client intake. They had two options on the table: subscribe to an automation platform with pre-built workflows, or hire a developer to build something custom. They wanted to know which one was right.

The answer, as with almost every build-vs-buy question, was: it depends on three things. Workflow specificity, transaction volume, and internal capability. Get those three right and the decision is straightforward. Miss one and you spend $30,000 on a tool that nobody uses six months later.

The buy path: platforms with pre-built workflows

Automation platforms ship a library of ready-made sequences. Data entry bots. Document processors. Lead enrichment flows. You select the one that matches your task, configure it, and run it. Some platforms offer 2,500+ pre-built options.

The economics are clear. You pay a setup fee (typically $1,000 to $5,000) and a consumption charge based on volume. Time to value is fast — often under two weeks. You do not need a developer on staff.

Where this works well: high-volume, standardised tasks. Invoice processing. Contact deduplication. Inbound form routing. Work that follows the same steps every time, across every customer, with no branching logic that changes by team or context.

The build path: custom automation

Building means someone maps your exact process — the steps, the exceptions, the judgment calls — and wires automation around it. The output is a system that fits how your team works, not a template your team adapts to.

This takes longer. Two to six weeks for a single workflow, depending on how many systems need connecting. It costs more upfront. And it requires someone who can read both the technical possibilities and the operational reality — because the biggest risk in custom automation is building something that solves the wrong problem precisely.

Where this works well: workflows with context-specific branching. Client onboarding sequences that differ by service tier. Reporting pipelines where the data sources change by account. Internal operations where the process lives in one person's head and has never been documented.

The three decision variables

1. Workflow specificity. How unique is your process? If five other companies in your industry run the same steps in the same order, a platform template will handle it. If your process involves judgment calls, conditional routing, or tool combinations that are particular to your team, a template will break within weeks. I saw this pattern repeatedly at Meta — the operations team would pilot a standardised tool, and within a month the Singapore office was running workarounds because the process did not match their regional requirements.

2. Transaction volume. Platforms charge by consumption. At 50 transactions per week, the unit economics are easy to justify. At 500, consumption fees compound quickly and a fixed-cost custom build starts looking cheaper over 12 months. Run the math at your actual volume, not the demo volume.

3. Internal technical capability. A platform requires someone to configure and maintain it — not a developer, but someone comfortable with no-code tools and debugging when a trigger fails. Custom automation requires less ongoing configuration but needs a clear owner who understands the logic well enough to know when something has gone wrong. If neither person exists on your team, budget for external support either way.

The hybrid path most teams miss

The cleanest answer is often a mix. Buy a platform for the standardised, high-volume tasks (form routing, data entry, document generation) and build custom for the workflows that define how your team operates (client onboarding, weekly reporting, internal handoffs).

I worked with a consulting firm last quarter that was evaluating a full-platform subscription at $3,200 per month. After mapping their workflows, we identified that three of the seven processes they wanted to automate were standard enough for a $500/month platform tier. The other four needed custom work. The hybrid approach saved them roughly $18,000 in the first year compared to the full platform, and the custom workflows performed better because they matched the team's actual process.

Typical outcome: 40-60% of workflows suit a platform; the rest need custom design.

What to do before you decide

The decision matrix is only useful if you know what you are automating. That sounds obvious, but during my KPMG years advising on process design for Fortune 500 operations, the most common mistake was committing to a tool before documenting the process. The result was expensive software running an undefined workflow, which produced outputs that nobody trusted.

Before you evaluate a single vendor or write a single spec, do two things. First, pick the workflow that costs the most hours per week. Second, have the person who runs that workflow walk you through every step — including the exceptions and the judgment calls. Write it down. That document is the input that makes the build-vs-buy decision answerable.

Without it, you are guessing. And guessing at $3,000 to $5,000 per month is expensive.