Build Your Own Linear

This morning I finished thinking through a feature out loud, said "add this to HQ," and a spec appeared on the board my cofounder reads. Business reason, acceptance criteria, a full PRD attached, and a line in her activity feed so she'd know it landed. I never opened the tool. I was in a different project entirely, talking to Claude about a signup wizard.

That board is called Founder HQ, and it has exactly four users. Me, Jessica, my Claude, and her Claude.

We're a two-person company, and every tool in this category is built for a company we aren't. Jira wants sprints and story points. Linear wants a team. Notion wants you to design your own tool inside their tool, which is how every Notion workspace becomes an abandoned museum of templates. Half the entities that need to read our project board aren't people.

Meanwhile our real system was Slack threads, voice notes, and my head. A decision would get made in a call, referenced three weeks later, and neither of us could find where it lived. The company had state, but the state had no address.

So HQ is a page in our playground app with a Supabase database behind it. Two boards, product and blog. An initiative is a card with a memo. Docs render from structured JSON through one component, so every doc looks like it belongs to the same company. Instead of notifications there's a feed called "Since you last looked." Jessica wrote five initiatives onto it in her first sitting. That was the moment it stopped being my prototype and became our board.

The part that makes it work is that the AIs are first-class users. Both machines carry the same skill file, which is a document that teaches Claude how the board works, what a memo has to contain, how docs are structured, who the author is on which machine. When I say "add this to HQ," my Claude knows the drill. The feed is the shared timeline all four of us trust. Most of my building happens as parallel AI work, the kind I described in The Blog War Room, and HQ is where all of it reports back to.

This is the part no off-the-shelf tracker can have. The Claude that writes a spec onto our board is the same Claude that builds the feature, it works in the codebase every day, so a PRD arrives already naming the controllers it touches and the validations that will break. Linear sits outside the work, asking to be kept updated. Ours is in the work.

How a feature moves

This week we turned it from a board into a process. Nothing gets built without landing on HQ first. Not as bureaucracy, as a forcing function. A feature moves through three stages, and the same agent carries it the whole way.

The first stage is intake. I say "add to HQ" and an initiative appears with a memo in a fixed shape. The business reason comes first, why this is worth building, a paragraph, not a feature description. Then a quick overview. User stories only when the feature has real actor confusion, otherwise they're ceremony and we skip them. And always acceptance criteria, written as a checklist under a heading called "Done means."

That heading is doing more work than it looks like. The board parses it and renders the checklist as live progress on the card itself. Which means the acceptance criteria are the status. There's no separate field where someone types "80% done" based on vibes.

The second stage is the spec. Every initiative that's actually getting built gets one attached PRD, and the PRD is a living document. It gets edited in place for the whole life of the feature, never forked into a v2. Every change appends a dated line to a section at the bottom called "Decisions & changes," newest first, so anyone reading the spec can see what moved and when. It's the same discipline as The Captain's Log, applied per-feature.

The third stage is the build, and this is where the loop closes. The same Claude that wrote the spec writes the code, so every decision made while building, every descope and reversal, flows straight back into the PRD it came from. The spec doesn't rot behind the work because the thing doing the work is the thing maintaining the spec. Then a human ticks the boxes.

Two rules keep the whole thing sane, and both of them are about trust.

First, the AI never puts anything on the board unprompted. Claude can analyze a feature all afternoon, conclude it's buildable, and it still waits for one of us to say the words. A shared board only works if everything on it is intentional. The moment agents start filing their own ideas, the board becomes an inbox, and inboxes are where attention goes to die.

Second, the AI never ticks a Done-means box. Claude can build the feature, verify it, and tell me "criterion three looks complete, here's the evidence." The tick is mine. Done is a human judgment, and the day that stops being true, the checklist stops meaning anything.

The Playbook

Stop configuring tools built for teams of forty. A board for a small company is a page, a database, and a feed. Ours took an afternoon of prototyping, and custom internal software is now cheaper than SaaS onboarding.

Give it a memo standard and keep it fixed. Business reason, overview, stories only when they earn it, acceptance criteria as a checklist. The consistency is the feature.

Make the acceptance criteria the status display. If the card renders the checklist, nobody ever writes a status update again.

Write the skill file so your AI is a real user of the board, not a copy-paste intermediary. Then set the two trust rules, nothing lands unprompted, and no box gets ticked by anything that doesn't have a pulse.

The first initiative through the full flow went up today. It's called "Remove Industry from Wizard," it has nine acceptance criteria, and every box is still empty, waiting for a human.