The Solo Operator Can't Afford Inference

Two of my own memos disagree

I have argued two things on this site that cannot both be fully true. One memo said a single operator, armed with AI, can now build and run a real software business alone: the mom-and-pop SaaS era. Another said AI-native software carries a variable cost of goods that traditional SaaS never had, and that inference eats the margin the multiplier crowd keeps pretending is still there.

Put those next to each other and the seam shows. If inference is heavy enough to compress margins for a funded company with a pricing team, it is heavy enough to sink a one-person business that has no such buffer. The solo operator is the least equipped participant in the market to absorb a variable cost that scales with usage. So either the mom-and-pop thesis is narrower than I stated it, or the margin thesis is. Doing this reconciliation in public is the point. A body of work that never contradicts itself has stopped testing its own claims.

Both hold. They just hold in different places, and the place where they overlap is smaller than either memo implied on its own.

Token intensity varies by orders of magnitude across categories

The resolution is that inference cost per unit of value delivered varies by orders of magnitude across categories, and the two memos were quietly describing different categories.

A scheduling tool that uses a model to parse one email and propose three meeting times spends a rounding error on tokens per transaction. A tool that summarizes a 40-page document on every page load, or runs an agent through a dozen reasoning steps to complete a task, spends real money every time a user shows up. Same “AI-native” label. Costs that differ by two orders of magnitude.

Where inference is a rounding error, the mom-and-pop thesis is intact. The operator can price flat, eat the token cost, and still keep most of the revenue. The AI is ambient. It makes the product possible without dominating the P&L. Where inference is the dominant cost, the margin thesis wins. Every incremental user is a variable-cost liability, pricing has to meter usage to survive, and metering is exactly the operational overhead a one-person business exists to avoid. The fragmentation into thousands of tiny durable software businesses happens on one side of that line and not the other.

Be careful with the numbers here, because the earlier margin memo leaned on specific gross-margin ranges, figures I have not sourced to a standard I would defend at a board table. Treat them as illustrative until I can cite them. The directional claim survives without the exact percentages: a token-heavy product runs a materially lower gross margin than a token-light one, and the gap is wide enough to determine whether a solo operator can live on it.

The mom-and-pop thesis holds only below a token-intensity ceiling

So the mom-and-pop SaaS thesis, stated properly, carries a constraint: a single operator can build and run a durable software business alone in categories where inference cost stays below what a one-person business can absorb without metered pricing.

That bound sorts categories cleanly.

On the affordable side: workflow tools that call a model occasionally, form-fillers, classifiers, routers, anything where the AI touches a transaction once and gets out. A niche CRM that drafts one follow-up email per lead. A booking tool that reads intent from a message. A vertical data-entry product that uses a model to normalize an upload. These spend pennies per user per month on inference, and the operator keeps the rest.

On the unaffordable side: anything with an agent loop, anything that reprocesses large context on every interaction, anything that competes on the depth of its reasoning rather than the convenience of a single call. Coding assistants. Research agents. Long-document analysis. Continuous monitoring that re-runs inference on a schedule. These are real businesses. They are not one-person businesses, because the cost structure demands a pricing function, a cost-control function, and enough capital to survive the gap between usage and collection.

The mom-and-pop era is real. It is smaller than “all of SaaS,” and the boundary is drawn by token intensity, not by ambition.

Falling inference prices will move the line, so watch the cost curve

This bound is not permanent. It moves with the price of inference, and inference has fallen fast enough that betting against further declines has been the losing side of the trade for three years running.

If the cost of a given quality of inference drops another order of magnitude, categories currently stranded on the unaffordable side cross over. The research agent that costs a dollar per run at $0.10 becomes viable for a solo operator to price flat and eat. The bound relaxes, and the mom-and-pop thesis expands to swallow categories the margin thesis currently owns.

So the thing to watch is not model capability. It is the price of a fixed unit of capability over time, the cost to run a benchmarked task at constant quality, tracked quarter over quarter. When that line drops far enough that an agent loop costs what a single API call costs today, the boundary I just drew moves, and I will have to redraw it. Capability announcements are noise for this question. The per-token cost curve is the signal.

Caching and cheaper models shift the line but don’t erase it

The sharp objection: solo operators route around inference cost with aggressive caching, cheaper small models, and prompt engineering that cuts token count. True, and it buys real headroom. But it is a difference of degree, not of category. Caching helps most where inputs repeat and helps least where every user brings novel context, which is precisely the token-heavy work that strands the operator in the first place. Optimization shifts the line without erasing it. The categories that need the most optimization to survive are the ones a one-person business should not be running at all.

The mom-and-pop SaaS thesis holds for the software where the model is a feature the operator can afford to give away, and it fails for the software where the model is the product and the meter never stops running.