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.

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?

Run the 20 primitive project ideas through the four-question screen strictly and the ranking changes a lot. Several technically attractive ideas turn into weak projects. The economic buyer is unclear, free infrastructure already solves the problem well enough, or the moat amounts to “ours is smaller.”

So Statefile, Lease, BareQueue, TTL, Count, Remember, Freeze and probably ConfigLog go out at this stage. They all solve real engineering problems, but the money question is poor. Redis, SQLite, existing Go libraries, message queues, object storage, Git and cloud infrastructure already give acceptable answers. A tiny implementation might make a respectable GitHub project. “Simpler and smaller” doesn’t tell you who eventually writes a meaningful check.

Temporal KV is a key-value database where a key doesn’t just have a current value. The database automatically remembers how that value changed over time.

In an ordinary KV store, you might write price = 100, then later price = 110, then price = 125. Ask for price and you get 125. The earlier values have normally been overwritten. In a Temporal KV store, all three states stay logically accessible. You can ask for the current value and get 125, or ask “what was price at 10:00 yesterday?” and get 100. The basic abstraction stops being key → value. It becomes key + time → value.