How a product
gets built

Tooling

No tooling — this stage is thinking

LLMs used as a very fast, very wide search engine. Nothing to automate: the output is a yes or a no.

In practice

Pellucid began as two apps in one, with GitHub in between as a black box: an author and an editor working on the same project, the editor raising feedback the author would pick up. The editor view was cut: I have no real insight into what an editor needs, and guessing would have produced a worse tool than none at all. GitHub became Google Drive, because durability mattered less than the destination being somewhere the intended user already understands.

Tooling

Skill for architecture and feature discovery · stages 02–03

One pass that defines what the product is, what it must run on, and what there is to prioritise — so stages 02 and 03 share a single source of understanding. Undergoing polishing and pruning before it gets its public repo.

In practice

Every app is Flutter, because every app is meant to be multiplatform. This site is not Flutter: a static page gains nothing from it. The tooling splits the same way, by purpose rather than preference — Python where it parses code and drives files, JavaScript where the ecosystem is the better fit. And some tooling is not a program at all: where the job is to direct an agent rather than run a process, it ships as a Skill instead.

Tooling

Skill for architecture and feature discovery · stages 02–03

The same discovery pass surfaces the platform and compliance constraints the stack has to satisfy. Judgment still makes the call; prior lessons come from the memory layer.

In practice

• Kalkra: multiplayer was built, then cut from v1. It stays out until there is evidence anyone wants it.
• Gastrotator: bring-your-own Gemini key was a late addition to v1, added precisely so the hobby project could be shared with other people. It is not a service I want to be paid for, and carrying inference costs for everyone would have made it one.
• Pellucid: desktop first, iPad second, two-way sync in 1.2, iCloud in 1.3. Deferred deliberately, not forgotten.
• Aulos: the inverse. It never reaches v1 on purpose. Staying a living codebase is the point, because that is what the framework has to be proven against.

Tooling

Concinnity

Ideas captured into lanes, then ranked head-to-head on an Elo model. Every comparison is stored with rationale and before/after ratings and published as an immutable ranking run, so a scope decision can be replayed months later instead of re-argued. Pending: the discovery pass from stages 02–03 should record its output straight into Concinnity — that hand-off is not built yet.

Everything above exists to make this stage possible. Stages 01 to 04 do not produce a document; they produce an executable brief — a sequenced plan, scoped so agents can be handed disjoint pieces, every feature carrying both its objective and the reason it exists, against an architecture already decided. Given that, the agent can genuinely be let loose.

In practice

For anything headed to a storefront, the stage starts before the code: the gates go up first — static analysis, a size ratchet, structural rules, hermetic tests, coverage — so test-driven development is enforced deterministically from the first token, rather than depending on an agent choosing to be disciplined. Small experiments skip this entirely; process is earned, not default.

Work then fans out rather than queues: a lead model decomposing the brief and dispatching each piece to the cheapest model that can carry it, or a provider's swarm mode where one exists. File-level fences keep parallel agents off each other's work.

This is the only stage I am genuinely hands-off for — my involvement is granting permissions. What comes back is not snippets or a scaffold but one working codebase. With the gates in place it cannot arrive any other way — running is not a hope, it is the precondition of getting through. Which makes it complete enough to argue with. That is precisely what stage 06 needs. You cannot give specific, directed feedback on something you have only imagined.

This is the stage where the model earns its keep.

Tooling

Karst

Agents get a knowledge graph instead of grep: tree-sitter parsing into SQLite, hybrid semantic and lexical search, kept current by a pre-commit hook that re-indexes changed files.

Lore

Hands the agent lessons already paid for elsewhere, so a mistake made once in one project is not made again in another.

ContextHistory

Supplies the accumulated project context, so a fresh agent session begins with the history rather than re-deriving it from the code.

The longest stage, and the one that cannot be delegated. The gates guarantee the code runs; nothing guarantees it is worth using. This is where the product acquires the quality that justified building it — the part no brief can specify, no test can assert, and an agent has no way to know is missing, because everything it was asked for is present and working.

In practice

Pellucid looked like Notepad until this stage. Every widget was in place and everything worked — a text box with a crowd of controls around it. But the entire premise of the app was to get out of the writer's way, and none of that existed yet. The Whisper UI — chrome that recedes as you type and returns when you reach for it — was built here, in the pass after the code already ran.

Stage 05 produced a text editor. Stage 06 produced Pellucid.

The same pass cuts what the first cut over-built. Agents are generous with abstraction and features; most of what gets removed here was never asked for. And it is where defects surface that no gate catches — the ones visible only in how the thing behaves, not in whether it passes.

This page is in that pass now. Stage 05 produced a structure that worked; everything since has been deciding what stays, what gets added, what is cut, and how it should look. You are reading the output of the stage you are reading about.

Tooling

Karst

The same graph makes pruning safe — dependents and dependencies resolve in milliseconds, and a background scanner flags dangerous patterns as they land.

Lore

The direction reverses: what this pass teaches gets written back, so the next project inherits the finding instead of paying for it again.

ContextHistory

Records what changed and why, so the reasoning behind a decision outlives the session it was made in.

A storefront wants far more than a binary. Screenshots at exact per-device sizes for every form factor, an icon set, a name, subtitle, description, keywords and release notes each under a different character limit; privacy, support and marketing URLs; a data-collection declaration answered item by item; an age-rating questionnaire; export-compliance answers — on top of signing, entitlements and sandboxing being exactly right. Miss any one of them and nothing ships.

In practice

Almost none of it is invented at submission time. The reasoning from stages 01 and 02 becomes the description and the release notes. The scope decisions from 03 and 04 are what make the privacy declaration truthful rather than hopeful — Kalkra can answer “Data Not Collected” because multiplayer and telemetry were cut, not because the form was filled in optimistically. The tooling then checks that everything the target store requires is present, and in the shape that store wants, before anything is uploaded.

Then the review itself, which is a negotiation as much as a checklist. An automated scan once flagged an entitlement as unused. It wasn't — I answered with evidence rather than rebuilding, which kept the release date instead of restarting the clock.

Tooling

store-launch-kit

The checklist made executable — a deterministic answer to whether every asset a given storefront demands actually exists, at the right dimensions and within the right limits. Built because assembling one submission by hand cost weeks.