I sat in a meeting last month where someone drafted a board paper with Claude on their phone, then walked out into a building where the power had been off since morning. Both of those things are now normal in the same afternoon.
That gap is the thing almost nothing written about AI accounts for. The advice is not wrong. It is written for a company with assumptions your company does not have, and the assumptions are invisible because the people writing have never had to question them.
I train founders and run programs for small businesses in Uganda. Here is what breaks when you take the standard advice and drop it into a business that is not in San Francisco.
Assumption one: you have people to redeploy
Most AI adoption writing is about freeing capacity. Automate the reporting, move the analyst onto something higher value.
A four person company has no analyst. The founder is the analyst, and also the salesperson, and also the person who goes to the bank. There is no capacity to free, only a person who is already doing six jobs badly and would now do seven.
The useful framing for a small team is not what to automate. It is which of the six jobs is being done worst, and whether a machine doing it at eighty percent is an improvement on a tired human doing it at fifty.
That is a different question, and it has a different answer. Reporting is usually the wrong first target, because nobody was reading the reports. First drafts of customer emails are usually the right one, because those were being skipped entirely.
Assumption two: the meter is not running
Every good AI workflow I have read assumes abundance. Run it again. Generate twenty and pick one. Have a second model review the first.
All of that is correct and all of it assumes the subscription is a rounding error. For a founder paying themselves out of what the business made that month, a serious AI seat is a real share of take-home pay. So they ration.
Rationing looks responsible and it produces thinner work. You stop at the first answer instead of the third. You do not ask the model to check itself. You skip the round where you argue with it and it changes your mind. The output is worse for reasons that have nothing to do with skill, and the gap never shows up in any benchmark.
If you are advising someone in this position, the honest advice is to use it less often and much harder. Fewer, longer, better prepared runs. Assemble the context before you start. Save the output the moment it lands.
Assumption three: the lights stay on
In Kampala, power and fiber both cut without warning, sometimes for a full day. A long working session is not only a cost in tokens. It is a bet that the line stays up.
This changes the shape of the work. Anything that depends on an unbroken two hour session is fragile here. Anything that can be done in fifteen minute pieces, with state saved to disk between them, survives.
I now design every long process this way, and it has made the work better even on days when nothing fails. Checkpointing forces you to say what “done” means at each stage.
Assumption four: someone can tell whether the output is right
This is the one that worries me most.
AI made building possible for people who were never going to hire a developer, a designer or an analyst. That is real and it is good. But it produces far more than any of those people can evaluate, and the gap widens every month.
The work moved from producing to judging, and judging is the part nobody was trained for. A confident wrong answer looks exactly like a confident right one. The failure mode is not an error message. It is a document that reads well and is subtly untrue.
What I tell people now is to keep the judgment and hand over the hours. The professionals I train who do best delegate production and hold on to the calls they would be embarrassed to get wrong. The ones who struggle do the reverse, because judgment is the tiring part, so they hand that over first and carry on doing the typing. Then they cannot tell when the output is wrong, because knowing that was the expertise they were being paid for.
Five things I would actually do
Five things, from watching this go right and wrong across a lot of small businesses.
Start where the work is currently not being done at all. Not the thing you do badly. The thing you skip. Follow ups that never get sent, proposals that never get written, the monthly summary nobody has produced since March. There is no quality bar to clear, because the current output is nothing.
Price year two at the full rate before you build the habit. Most people are on a trial or an introductory tier and have never done that arithmetic. Decide now whether the workflow survives the real price, because unwinding a dependency is much harder than not starting one.
Budget per decision, not per month. A subscription feels like a fixed cost. It behaves like a variable one, because the thing that changes is how often you reach for it.
Put a number on the output gap. If you are stopping at the first answer to save money, that is a cost. Measure it before you record it as a saving.
Make every check prove it can fail. I had a guard in a pipeline for weeks whose condition could never match anything. It passed cleanly through about 180 runs and had never once fired. Nothing was broken, nothing alerted, and the system reported success while the world disagreed. If you cannot name the input that would turn a check red, you do not have a check.
The honest summary
The technology arrived everywhere at once. The conditions for using it well did not.
If you are running a small business outside the places this advice is written in, you are not behind. You are solving a harder version of the problem with fewer of the inputs, and most of the published playbooks quietly assume you have those inputs already.
Start by being clear about which ones you actually have.
That is what the AI Readiness Check is for. Twelve questions, four minutes, scored out of 48, no email required and the result is on screen: founderwise.io/ai-readiness/
It will not tell you which tool to buy. It will tell you whether the thing you are about to automate is ready to be automated, and what it costs you if you are wrong about that.
If you would rather talk through your own setup with someone who works in these conditions, book a strategy call: cal.com/pirwot/strategy-call