Building with AI · Part 7

The Pivot: a life decision expressed as a licensing table

Posted July 2, 2026

For most of this year there was a business plan. A real one: ADRs, four named offerings (a build Factory at $5K-$25K, an Ops Toolkit subscription, a Launch Kit, Migration Assurance programs), a "prove it, then sell it" gate requiring instrumented dogfood runs before any selling began, even a brand strategy - because "aidd" loses every search to pharma's AI-drug-discovery acronym. Six months of prove-first work produced the proof.

On Monday, I retired the whole thing.

Why: the cost wasn't money

The decision record (ADR 0003) is unusually honest for the genre, and the operative sentence isn't about market sizing:

"A life centered on sales/marketing is itself an unacceptable cost, regardless of profit. Profit is welcome; profit bought with a salesperson's life is not."

The retired plan depended on a founder-led sales motion: outreach, pilots, a pricing ladder, list-growth. The named offerings weren't bad products. They were, as the ADR puts it, "the sales life being rejected." Six months of "prove it, then sell it" produced the proof and no appetite for the selling.

The replacement got written the same day: open-source both flagships now; defer any commercial question to a future low-touch model. Any future money must be inbound and self-serve. The entire commercial funnel is one sentence on a website inviting licensing inquiries by email. The maintenance floor is a good README, real docs, responsive issues, and not pulling a license rug. No outreach. No content calendar.

The licensing table

The substance of the pivot is three deliberate asymmetries:

Spernakit → MIT. A template exists to be copied and to produce apps the user owns. Any restriction on that defeats the point. Openness is the product working.
aidd → FSL-1.1-Apache-2.0. The orchestration loop is the differentiated engine: free for any use except building a competing product, and every version automatically becomes Apache-2.0 two years after release. FSL beat BSL because its single competing-use clause blocks both copy-as-competitor and hosted-competitor out of the box. And since FSL is license text, not DRM, the product ships with no enforcement code, no checkout flow, no account system.
The .aidd/ contract → open spec. Anyone may emit or implement the format. Protect the engine, not the format.

One more rejected temptation deserves a note. Rebuilding aidd on Spernakit before release, for narrative symmetry? Rejected. Partly because the payoff was marginal, but decisively because it violates aidd's own doctrine: the design doc forbids forcing the template onto mature codebases where replatforming isn't the goal. The honest claim is "aidd orchestrates Spernakit apps," not "aidd is one." When your tool's philosophy starts vetoing your marketing instincts, the philosophy is real.

Release prep also killed a sacred cow. Yesterday the entire LTS freeze apparatus - the baseline snapshots, the lockfile guard, the surface diff, all of it from the May 5 sealing - got deleted. The freeze hadn't held (v3.9, v3.10, and v3.11 each shipped as an openly-flagged "exception"), and the guards had become the number-one recurring gate failure in every session. Deleting governance is harder than deleting code; it feels like admitting the policy was wrong. It wasn't. It was right for a season, and knowing which season you're in is the actual skill.

The scrub: fresh-history publish

The release scans found no live secrets in either repo. What they found was subtler: private-fleet leakage. App rosters, sibling project names, machine paths, internal hostnames, a 23,000-line dogfooding changelog. Two years of a private life embedded in git history, not just the working tree.

Scrubbing history is an unbounded problem. The decision converted it into a bounded one: fresh-history publish. Each project ships as a brand-new public repository with a single squashed "Initial public release" commit built from a scrubbed snapshot. The private repos keep their full history as frozen archives. The public repo becomes the going-forward source of truth. And a pre-commit re-leak guard rejects private slugs, internal hosts, and machine paths from ever sneaking back in. One decision, and the historical leak, the metadata leak, and the future-leak risk all collapse into a one-time snapshot job plus a standing gate.

Even the scrub had a lesson in it. The blunt .aidd/ exclusion pattern matched at any depth and silently dropped the shipped scaffolding's .aidd/ directory - the one part of the tree that was supposed to go public. A fresh-clone gate caught it before push. Every filter is a bug until something diffs its output.

The first public tag keeps the real version number: v2.93.0, not a cosmetic 1.0. The changelog and feature history are real, and honesty about maturity is cheaper than theater.

The afternoon of the clean VM

Yesterday: CI and release automation went in (SHA-pinned actions, a Release job that only fires when CI passed on the tag), the repos went live under fresh history, and then came the test no amount of dogfooding could substitute for: install everything on a fresh Windows 11 VM.

One afternoon found four crash-on-clean-machine bugs:

The CLI crashed on every command. A bash-detection probe ran at module load, and it turns out Bun.spawn throws on a missing binary instead of returning a nonzero exit, skipping every carefully-written fallback gated on exit codes.
Launched runs died before their first heartbeat when git was absent, for the same throw-not-exit reason.
A seed-row race on first launch turned concurrent page loads into a UNIQUE-constraint 500.
The bundled scaffolding/ template directory listed itself as a discoverable project on fresh installs.

All four fixes shipped this morning in v2.94.0 - a release cut, fittingly, by the release automation's own first end-to-end run. The pattern behind them matters more than the fixes, though. Every one was an assumption aidd had been allowed to keep because every machine it had ever run on was mine. "It works on the machine it was built on" is a tautology, not a test. One afternoon in a fresh VM found four failure modes that two years of dogfooding structurally could not.

The repos are public, the automation works, the clean machine boots. What remains is the receipts: proving, in public, that the tool does what the README says. The plan is written up and queued - four apps, four creation lanes, four stacks, every failure filed as a bug against the release. No silent manual fixes allowed. If the tool is real, it'll survive. If it isn't, I'd rather find out on camera than have a user find out for me.