Problem

Small exam-prep and credentialing programs track cohorts, exams, and completions in spreadsheets and office documents that cannot answer a question a semester later: which blueprint, which exam version, who was enrolled, who signed off.

Constraint

Two people, nights and weekends, no funding, one anchor customer whose course was already running on the standalone pipeline. Every feature had to survive the question of whether it made the record more defensible.

Decision

Treat the exam blueprint and the exam membership as the data model, not the UI. #430 replaced admin-password auth with exam_members and exam_blueprints; #445 and #451 built the semester orchestrator and a public syllabus viewer on top of them; Phase 2 (#2316) made credential blueprints first-class data rather than configuration.

• A shared admin password

  It is how the first version worked. It cannot say who did what, so it could not survive an audit question, and real memberships replaced it.

• A generic LMS integration

  Programs do not lack courseware; they lack a defensible record of who was certified against which blueprint.

What shipped

An exam generator, a public landing page, self-serve sign-up and login, memberships and blueprints, a semester orchestrator with a public syllabus viewer, and Phase 2 credential blueprints as data. Pre-launch.

What I'd do differently

The landing page was the second merge, and the launch push was shelved by July (#1921). Credential blueprints became first-class data two months later (#2316), which is the order it should have gone in from the start: schema, then product, then the page that sells it.

If you ask me about this

How do you decide what not to build?

I ask whether it makes the record more defensible. The launch push waited. The blueprint model did not.

What is the hardest part of building with a partner?

Agreeing on the one thing the product is for. Once we said a defensible record, every argument got shorter.

Evidence

1. Heddle exam generator + /crss/bank Supabase hardening

   #281 · 2026-04-20 · feature

2. Add /heddle public landing page

   #367 · 2026-05-15 · feature

3. heddle: self-serve sign-up + login at /heddle/login

   #371 · 2026-05-15 · feature

4. heddle: exam_members + exam_blueprints, replace admin-password auth

   #430 · 2026-05-17 · feature

5. heddle: semester orchestrator + public /syllabus (foundation)

   #445 · 2026-05-18 · feature

6. heddle: orchestrator step 7 — publish + public /syllabus viewer

   #451 · 2026-05-18 · feature

7. docs: shelve the Heddle launch push + shutter the /lcl roadmap

   #1921 · 2026-07-09 · docs

8. Heddle Phase 2: credential blueprints as first-class data

   #2316 · 2026-09-03 · feature