How Much Does AI Automation Cost?

The direct answer

Here's the menu as of August 8, 2026. Four ways in.

• Starter Workflow, $149: one task, one output. A digest, a draft, an alert, or a sheet that updates itself. Delivered in 48 hours or less, with documentation.
• System Build, $499: two or three automations wired together, usually around an inbox, content, or research, with approval gates where they matter. Three to five days.
• Automation Partner, $199 a month: for something that already proved useful and now needs a person behind it. Tuning, new checks, fixes, and a spot at the front of my queue.
• Custom Agent System, $1,500+: the deeper stuff. Browser agents, multi-tool integrations, private research systems. We scope it together and you get 30 days of support.

What the build price covers

The AI model is the cheap part. Most of what you pay for is everything around it. Mapping the process, hooking up the right sources, writing the rules, deciding what happens when something weird comes in, keeping logins where they belong, testing, approval points, and the write-up at the end.

Tight boundaries are what keep the bill small. “Check these sources each morning and prepare this five-part digest” is something I can scope and test. “Run our operations” is not.

A practical scope matrix

Treat this as a rough map. Not every example fits neatly into a package.

What changes the scope

Tools and access

One inbox feeding one approval queue is easy. Email plus a CRM plus a spreadsheet plus a calendar plus a portal that only works in a browser is not. Every connection is another login, another set of fields to map, another way to fail, and another round of testing.

Data and exceptions

Clean forms make everything simpler. Free-form email, duplicates, missing fields and rules with a dozen edge cases mean cleanup first, plus a path for a person to review the strange ones. And if your experienced staff disagree on what the next step is, you need an escalation rule before you need more AI.

Permissions and consequences

A report that only reads things is low risk. A system that sends messages, edits records, publishes, or touches money is a different animal. Those actions get narrower permissions, logs, approvals, and a plan for undoing a mistake.

Interface, reliability, and support

A lot of the time an email digest or the spreadsheet you already use is plenty. A custom dashboard, a client portal, monitoring, or faster support is extra work on top of the automation itself.

Feasibility comes before a final quote

Some jobs shouldn't be automated, and some can't be. The tool you need might not have a usable integration. A site might ban automated access, or break it every other week. The data might be a mess. Privacy or security might call for a different design. And anything that takes high-stakes judgment, or a process nobody has actually defined, stays with a human.

Before I quote, I want the source, the trigger, the rules, the output, the owner, the approval points, how we get access, and what happens when it fails. If we can't pin those down, my advice is to simplify the process first. Or leave it alone.

Budget for operation, not just construction

Ask about the running costs too. Third-party subscriptions, model or API usage, the time your staff spends reviewing, maintenance, changes down the road. Those depend on your tools and your volume, so I work them out during scoping instead of hiding them behind a package price.

Review time is a real cost, and I'd pay it every time. It's how you catch a bad assumption before a customer does.

DIY versus working with a consultant

DIY is fine when the job is simple, you know the tools, and someone on your team will own setup and upkeep. What you need then is a written plan with the trigger, the steps, the tools, the approval points, and the name of whoever checks the output.

Bring me in when the bottleneck crosses tools, has real exceptions, or does damage if it runs wrong. Then you get the working system. A map we agreed on, connections and rules set up, a tested output, documented approval points, and a handoff so your team knows what it does and where a person still has to look.

Neither one gets you a hands-free business. If someone inside can build and maintain a narrow version, start there. Get help when a stalled setup, flaky handoffs, or one bad live action would cost more than building it right.

Estimate value with your own baseline

Watch one normal week and write down a few things.

• How often the task comes up, and how long one full round takes.
• Where it gets delayed, forgotten, or redone.
• What a person still has to look at.
• Which software and upkeep costs keep running after launch.
• Whether anyone will actually use the new output.

Then hold that weekly pain up against what the system costs to run. One honest week beats any ROI stat you'll find online. If you want a structure for writing the task down, I wrote a separate piece on turning repeated work into safe automation rules.

How to avoid paying for the wrong thing

• Pick the job before the platform. A long feature list proves nothing about your repeated task.
• Start with one useful output. Add tools once the first version has earned them.
• Pay for reliability. A clean approval queue beats a bot with broad permissions putting on a show.
• Plan for change. Outside services, fields, logins and business rules all move eventually.

Still picking a first project? I wrote up what a small business should automate first. You can also see what I build, click through my public work, or browse the portfolio. Anyway, start with one job. The $149 version will teach you more than any pitch.