Why the spec is the product

Something fundamental changed in how software gets made, and I think most of the industry is still catching up to what it means.

For my whole career, implementation was the bottleneck. Ideas were cheap - everyone had a notebook full of them - but turning an idea into working software took teams, budgets, and months. So we built an entire industry around the expensive part: frameworks to write code faster, methodologies to coordinate the people writing it, companies whose whole business was renting out the people.

Then AI agents got good. Today I hand an agent a precise description of a feature and get back a clean, working implementation in minutes - code I would have been proud to write myself, at a pace no team can match. The expensive part collapsed in cost.

What did not collapse is knowing what to build. Ask an agent to "build a CRM" and you get a demo: a contact table, a pipeline board, something that photographs well and falls apart on contact with real work. The difference between that demo and a product is hundreds of decisions. What happens to a converted lead's owner? When is a lock released if the browser crashes? Which fields does the quote copy from the opportunity, and which does it deliberately not? Nobody writes those decisions down, because they used to live in the heads of the team that spent months implementing.

There is no team spending months anymore. So the decisions need another home.

The pair

That is the idea behind 66IDEAS. Each product here is published as a pair:

The specification - functionality, UX, and architecture, written completely enough that a human team or an AI agent can build the product from it. This is the valuable part. It is where the hundreds of decisions live.

The reference implementation - working, self-hostable software built from that spec. Because a specification nobody has built is a wish, not a spec. The implementation is the proof that the decisions hold together.

Both are MIT-licensed. You can run the reference implementation as-is, or take the specification and build it on whatever stack you trust - Google Firebase, SAP BTP, Microsoft Azure, or anything else. The spec deliberately does not care.

What this changes about contributing

It also inverts the usual open-source contribution model. In this repository, pull requests are welcome on the specification - and only there. The reference implementations follow the spec. If the code disagrees with the spec, that is a bug in the code.

This sounds restrictive until you see what it protects: every implementation stays a faithful proof of the design, instead of drifting into a codebase whose behavior nobody can state anymore. And it puts collaboration where the value is. Improving an acceptance criterion helps everyone who ever builds from the spec, on every stack, forever.

The first one

The first product is CRMTHREE, a complete CRM: accounts, contacts, leads, a configurable pipeline, quotes, orders, invoices, tickets, SLAs, a knowledge base, deal rooms, AI briefings, even gamification. Sixty-plus user stories with acceptance criteria, a UX spec, an architecture spec, and a machine-readable data model - plus a reference implementation you can self-host.

Less. But better.