Three AI projects per fifty-person SMB. We’re sure about the number.
Clients often ask us to scope ten initiatives. We talk most of them down to three. The reason isn’t conservatism, it’s arithmetic. Beyond about three concurrent AI workflows, an SMB without dedicated AI ops capacity loses more to operational drag than they gain in throughput.
One of the most common conversations we have in an Application Map engagement goes like this. Client: “We’ve identified twelve places we want to apply AI.” Us: “Let’s build three.” Often this lands badly at first, like we’re trying to slow them down on purpose.
We’re not. The three-project ceiling comes from a real constraint, and it’s a constraint about the business, not about us.
Every AI workflow in production carries three kinds of ongoing operational load. Monitoring (someone has to know whether it’s working). Drift response (when the underlying systems or data change, the workflow degrades, and someone has to notice and fix it). Edge-case handling (every workflow has an exception queue, and someone has to work it). At a 50-person SMB, this load lands on people who already have full jobs.
In our experience, the realistic ceiling for an SMB without a dedicated AI ops function is around three concurrent workflows. Beyond that, the operational drag of maintaining what you’ve already shipped exceeds the marginal value of shipping more.
This number is a heuristic, not a law. We’ve seen firms run more than three when they hire an internal AI ops lead, and fewer than three when the existing workflows are particularly demanding. But it’s a useful starting point for any conversation about scope: not “what can we automate?” but “what are the three highest-leverage workflows we can run well?”
The Application Map document we deliver always ranks more than three opportunities, because clients want to see we considered them. But the recommendation is always to start with three. We’re sure about the number.