Section 1
The binding constraint is attention, not headcount
Big teams have specialists. A ten-person company has people doing four jobs each, switching between them all day, and paying a reset cost every time they switch. That switching is where the capacity goes, not the typing. So the first automation target for a small team is rarely the longest task. It is the most frequent interruption. The lead that needs a reply within the hour. The recurring client question that pulls a delivery person out of focused work. The weekly report that three people assemble by hand on a Friday afternoon. Remove an interruption that occurs twenty times a week and you return contiguous blocks of time, which is worth considerably more than the same minutes scattered across the day.
Section 2
What a team under ten should automate first
Three categories pay for themselves quickly. Intake, where information arrives in an unstructured form and someone has to read it, classify it, and put it somewhere: inbound enquiries, supplier invoices, application forms. Status, where the work is telling other people what has happened: client updates, internal standups, pipeline reports. Drafting, where a first version is slow and the edit is fast: proposals, follow-ups, documentation. What rarely pays off early for a small team is the deep, bespoke, high-judgment work you are actually known for. That is the thing customers buy, the variance is high, and the person doing it will spend longer correcting the machine than doing it themselves. A small team also has an advantage worth using: work can run while nobody is at a desk. Batch the intake and the drafting overnight so the morning starts with a reviewed queue instead of an empty one.
Section 3
A capacity model for a team of five to fifteen
Small-team capacity is not headcount multiplied by hours. It is headcount multiplied by focused hours, minus coordination. The model below shows how to estimate each term and where automation moves the numbers. On choosing the tools that sit underneath it without ending up with six subscriptions, see [How to Evaluate AI Vendors and Partners](/blog/how-to-evaluate-ai-vendors-and-partners).
Section 4
Building it without a platform team
You do not have an engineering function, so the rule is simple: nothing that requires a specialist to keep alive. Prefer the automation that lives inside a tool the team already pays for over the elegant custom one that only the founder understands. Build in one lane, with real inputs from the last month, and keep a human approving the output for the first few weeks. Then place the result where work already happens. If the team has to open a new tab to get the benefit, they will do it for nine days. Write a one-page runbook as you go: what this does, what it touches, how to turn it off, who to call. A small team that skips the runbook has built a dependency on one person's memory.
Section 5
The single point of failure you are creating
In a company of six, one person usually builds every automation. That is efficient right up to the week they are on leave, ill, or gone, and then a workflow the business depends on has no maintainer. Mitigate it cheaply. Keep credentials in shared storage the founder can reach. Document what each automation reads and what it writes. Make sure every automated workflow has a manual fallback that somebody has actually performed at least once, not just described. And keep humans on the decisions with money, employment, legal or safety consequences attached, because a small team has no second line of defence when an automated decision goes out wrong. The transformation stories worth learning from are usually explicit about this, which is one reason [Startup Success: How AI Automation Transformed Our Business](/blog/startup-success-how-ai-automation-transformed-our-business) is worth reading alongside this piece.
Section 6
Measure focus, not output volume
Output per person is a tempting metric and a misleading one, because a small team can raise output while degrading the thing customers pay for. Track focused hours per week on revenue-producing work, response latency to customers, rework, and how much time the automations themselves consume in review and repair. You are ready for this if the same category of interruption hits your team dozens of times a week and someone can name what it costs. You are not ready if your bottleneck is that not enough people know you exist, in which case automation returns hours to a team that already has spare ones.