The cheapest AI app to run is one where the user’s own machine does the work. Your server hands out files, the browser downloads a small model once, and every inference after that happens on the visitor’s GPU or CPU. You pay for static hosting. That’s it.

This used to be a demo trick. In 2026 it’s a reasonable way to ship a real tool. WebGPU now runs in Chrome, Edge, Safari 26 and up (iPhone and iPad included) and Firefox on Windows and Apple Silicon Macs. Transformers.js v4 runs vision, speech, embedding and classification models on WebGPU and falls back to WebAssembly when there’s no GPU path. The pieces are boring enough to build on.

A zero-permission Android app could ask Microsoft Authenticator for a work account’s tokens, say it was Teams, and get them. Mail, files, calendars, chat. The bug is CVE-2026-80097, Microsoft scores it 8.6, and it is fixed in Authenticator for Android 6.2606.4246 and later. Microsoft published the advisory on September 8. The researchers at Enclave, who call it AuthMask, put out the full write-up on October 23, and that is the part app developers should read.

If you build AI features alone and can’t afford a surprise bill, the model you pick matters less than where it runs and who triggers it. Get those two right and inference costs nothing or close to it. Get them wrong and a free tier runs dry by lunch, or a paid API quietly eats your month.

What follows is the reasoning I’d give any solo builder, worked out the long way: by throwing ideas at the wall and watching most of them fail one test or another.

A useful software primitive gives another program a clear operation to depend on. Its explanation can fit into a sentence because its boundary is narrow: append an event, validate a proposed change, compute a difference or reserve a unit of capacity. Its value grows when the behavior behind that sentence is dependable enough that replacing it would mean recreating a substantial set of guarantees.

Easy to explain should describe the interface, not the difficulty of the work. “Store a value under a key” sounds simple until the user asks about durability, concurrency, ordering, limits and recovery after a crash. Those details decide whether the component belongs in a real system. A short description is a promise to make complexity manageable at the boundary, not permission to leave the difficult behavior undefined.

If your iOS app sells anything digital in the US, you can send users to your own web checkout today and Apple takes nothing from that sale. That has been true since the contempt ruling in Epic v. Apple in April 2025, and it still holds while a court works out what Apple may charge instead. Apple’s opening bid is 15%. Epic’s answer is close to zero.

For developers the window is open now, and it won’t stay free forever. What you build in the meantime should hold up whichever number the court lands on.

Given the direction of AltSql, BareProxy, Precomputing and the VPN primitives work, there is still a surprisingly large design space for projects that are smaller than platforms but more fundamental than ordinary applications. The best candidates have a very simple sentence behind them: “X currently requires a framework, service or stack; this does the essential 10% in one tiny binary, library or file.”

Look for primitives that can begin as a credible 2,000–10,000-line Go project, have an immediately understandable demo, and later sit underneath commercial products rather than needing to become a SaaS business immediately. Here are twenty directions that fit that model.

The most promising territory for a small team isn’t another large framework. It’s the opposite: infrastructure software you can explain in one sentence, ship as one binary or embed as one library, run with almost no operational burden, and that solves one irritating problem unusually well. SQLite and nginx are the right mental models because their appeal is architectural, not just functional: small surface area, predictable behavior, few dependencies, easy deployment, and usefulness far beyond the original use case. (More on that in the SQLite and nginx pattern as a product strategy.)

This list deliberately leaves “tiny version of Redis, Kafka or SQLite” territory behind. That was the first list of 20 primitives. The more interesting search space is a primitive that introduces a new operation, one developers might eventually feel should have existed all along. Some research paper or niche project has probably explored pieces of these. They’re meant as category-level concepts, not smaller copies of familiar products.

Forty primitives

1. Reach. Store a current state plus transition rules and continuously maintain which states are reachable from here: REACHABLE(current_state). A database answers what is; Reach answers what can happen. Uses: AI agent safety, workflows, infrastructure, manufacturing, cybersecurity attack paths.

The Counterfactual Store does resemble a Markov chain at the conceptual level. Both deal with states and the possible transitions between them. But a Markov chain is mainly a mathematical model for probabilistic transitions: given that I’m in state A, what’s the probability the next state is B, C or D? And the classic Markov property says the next-state probability depends on the current state, not the full history.

The Counterfactual Store is deterministic branching, not probabilistic transition. If the current application state is A, you create a hypothetical A′, change something, propagate the consequences, inspect the result and throw it away without touching A. No probability needs to be involved anywhere.

One direction that feels genuinely different from the earlier list of 20 primitives is a Counterfactual Store. Adjacent ideas certainly exist. Provenance databases, event sourcing, probabilistic databases, simulation systems and version control all touch pieces of it. But as a deliberately tiny infrastructure primitive, there’s no established category built around this exact abstraction.

Normal databases answer “what is true?” Temporal databases, and Temporal KV, add “what was true?” A Counterfactual Store adds a third basic question: what would be true if X were different?