What "transformation" assumes
When an enterprise announces an AI transformation, a set of preconditions sit silently underneath the word. There is a budget line that can absorb eighteen months of partial output. There is at least one person whose full-time job is to run the programme. There is a pipeline of candidate use cases vetted against a capability map. And there is a governance structure — legal, security, compliance — that will review each proposed change before it ships.
None of these preconditions apply to a five-person business. There is no budget line that can absorb a quarter of missed client work, let alone eighteen months. There is no person who can be reassigned. There is no capability map. The governance structure is "the founder thinks about it on the train."
A strategy template that assumes resources you do not have does not guide you — it wastes your time converting your situation into the template's vocabulary, then leaves you with a plan you cannot execute.
The visible consequences
Small businesses that try to run enterprise-shaped AI programmes tend to fail in three specific ways, and we have watched each of them happen more than once.
Analysis that outlasts the opportunity. The team spends six weeks producing a "current state" assessment of their workflows. By the time it is finished, the specific tool that prompted the exercise has shipped a new version, and the assessment is out of date. The team has learned nothing they can ship.
A governance layer that strangles experiments. The team, having read that AI needs oversight, builds a lightweight approval process. It is not lightweight enough. A proposed one-day prompt experiment is routed through review and returns in three weeks with a memo attached. By then no one remembers why they wanted to try it.
A platform decision that locks in the wrong year. The team, told to "pick a platform," chooses one in a market that reshuffles every six months. Two quarters later the chosen platform is no longer the leader in the single capability the team actually needed, but switching cost is now non-trivial, and they are stuck with a tool they did not really want.
A more realistic alternative
The alternative we argue for is not smaller transformation. It is a different shape of work entirely — one that matches what a small business can actually sustain. Three principles.
1. One workflow at a time
Pick a single workflow where a specific bottleneck is obvious. Not a capability map, not a portfolio — one workflow. Touch nothing else until the change on that workflow has survived a month of real use. If it fails, you have lost a month, not a year. If it works, you have a concrete reference when deciding what to touch next.
2. Reversible tools
Prefer tools that can be removed without leaving a hole. A prompt template in a document, a small script, a scheduled task — these are trivially reversible. A platform subscription that replaces your CRM is not. The default question is: if this does not work, how long does it take to return to exactly where we started? If the answer is more than a day, it is probably the wrong tool for a small business at the exploratory stage.
3. The metric before the tool
Decide what you are trying to move before you decide how to move it. First-reply time, first-draft time, proposal throughput, support-ticket time — pick one number your business already tracks, or could track on a spreadsheet. Then choose the smallest intervention that could plausibly move it. Reversing that order — tool first, metric to follow — is how small businesses end up with a licence they renew out of guilt for a workflow that was never actually the bottleneck.
When transformation-shaped work is appropriate
There is a size above which the transformation shape stops being a mistake and starts being necessary — roughly, once there is a full-time operations person, a dedicated budget line, and more than one workflow where the cost of inconsistency exceeds the cost of central coordination.
In practice that threshold is higher than most small businesses realise. Companies of forty or fifty people can usually still be served by a sequence of one-workflow-at-a-time experiments. The transformation vocabulary is pushed downmarket by vendors and consultancies whose services do not exist at the lighter-weight end of the spectrum, not because it has been shown to work at that scale.
What we tell clients in the first conversation
If a client of ours asks for help running an "AI transformation," our first response is to ask what would change if we used a different word. Sometimes the answer is "nothing, it just sounded more serious" — and we can replace the frame with a smaller, more concrete one without losing anything the client actually wanted.
Occasionally the client genuinely wants the enterprise shape — they have board reporting to do, or an investor who wants to see one, and the word is part of the product. In those cases, we will do the work, but we will also tell them, on the record, that the small-business version of the same outcome would cost a fraction of the budget and ship in a fraction of the time. Some of them choose the lighter shape after hearing it; some do not. Both answers are legitimate.
But nobody should drift into a transformation by default. It is a specific tool for specific conditions, and for a five-person business, those conditions almost never hold.
— Zheng Zhong, Founder, SOLO TECH LTD