Startup
Studio

Why this exists

What it has built

One framework, five cloned teams, five products in parallel

These are real attempts rather than demos, and they run at the same time. Each one has its own team, cloned from the same framework, so what any one of them learns the rest inherit.

The problem it solves

Copies fall behind, and it's hard to keep track

The easiest way to picture it is as a handbook that everyone works from.

When one project needs a different rule, the obvious thing to do is photocopy the handbook and change that one page. And it works, on the day you do it.

Meanwhile the original handbook keeps improving. Someone fixes a mistake, adds a lesson, drops a rule that turned out to be wrong. Your photocopy gets none of it, and nothing warns you. You usually find out months later, when that project repeats a mistake everyone else fixed ages ago.

It happens the other way round as well. Someone learns something useful and writes it in the margin of their own copy, because that's the copy in front of them. Nobody else ever sees it, and the next time handbooks are handed out the note is gone.

The model

One shared handbook, printed fresh for each project

So nobody photocopies anything. Each project keeps one short page of its own, listing the few things that are true there and nowhere else.

When a project needs its handbook, it gets printed fresh: the shared one and its own page together. Change either of them and it simply prints again.

A handbook that's reprinted every time can't go out of date, so there's nothing to keep track of.

write it once → every project reprints → nobody else does anything

There's one question I ask to decide where anything new goes. Would another project benefit from this? If yes, it belongs in the shared handbook. If no, it belongs on that project's own page.

Keeping the handbook worth reading

Three ways a project can differ, and only one needs your sign-off

A project's own page ends up holding three different kinds of thing, and at a glance they all look equally important. They aren't. Two of them you can just write down. The third can quietly undo a rule that every other project still follows, so it's the one worth stopping for.

Exceptions go at the top of the page rather than buried at the bottom, because a rule you've switched off is no use to anyone who never reads that far.

One check lists every exception across every project and flags anything nobody owns or that's overdue for another look. If nobody owns it, nobody can say why it's there, and nobody will ever dare turn it back on.

Safety checks are the one thing that can never be switched off this way. Allow it once and every awkward review becomes an exception.

The team

A full product team, not a single assistant

Each role is written to fight for its own goal first. Security argues for safety, design argues for the person using it, and the tech lead argues for shipping. They're told to make their strongest case with evidence and not to concede just to be agreeable.

That's the point. When every side is properly argued, what comes out is a real middle ground rather than whichever opinion happened to be voiced first. Where they genuinely can't agree, it goes up to the PM, who decides on the spec rather than on who pushed hardest.

Four checks have to pass, with proof, before anything goes out, and nobody signs off their own work. You can't see the thing you missed in something you just built.

Using it

Install once, then tune only what genuinely differs

1. Install the shared teamPut the shared handbook where your tools look for it, and every project has the full team from then on.
2. Write a stack card, once per projectSay what it's built with, how it works, and which shared rules don't apply here. Skip it and sixteen roles will each assume something that was only ever true of a different product.
3. Build the project's teamPrint it. What comes out is generated, so keep it out of version control. Edit it and your change disappears the next time it prints.
4. Improve the base whenever anything is learnedWrite it into the shared handbook, keeping what's general and dropping what was specific to you. Then it's everywhere.

How work reaches the team

Everything goes through a kanban board, the same way you'd run it in Jira or Asana. You write a ticket with a title and a description, and the description is where the real requirements live. The board is the only queue, so nothing gets built that you didn't ask for and nothing you asked for quietly gets lost.

The agents drive the board themselves from the terminal, moving tickets along and appending what they did, what they decided and anything they had to assume as they go. So the ticket becomes the history of that piece of work rather than something you reconstruct later.

They take it as far as UAT on their own. Then it stops, and you're the tester, exactly as you'd be in any product business. That's the one part I've never automated and don't intend to.

The board is called the Startup Studio Kanban and it's in the repo under board/, spec and working code both. Take it, it's the same one my projects run on.

# the whole workflow
studio -Status              # what exists, what has drifted
studio -Doctor              # the same, plus the fix for each
studio -Sync                # push the base out, rebuild everyone
studio -Tune    -Project X  # start a project's layer
studio -Compose -Project X  # rebuild one project

A check at the start of every session reprints a project if the shared handbook has changed, so nobody has to remember to do it.

Closing