Your own software factory
Your backlog, shipping
while you sleep.
Drop an idea in before bed. A crew of agents refines it, plans it, builds it, reviews it, and opens the pull request. You wake up to a decision to make — not a pile of diffs to babysit. Nothing merges until you say so. The process running underneath is the one the best tech companies ship with — fifteen years of it, packaged for you.
A kanban board with four lanes — Ideating, Planning, Building and Shipping — carrying tasks from a fresh idea through to a pull request waiting for review.
What actually happens between midnight and your first coffee
- 11:47 PMYou
Two sentences and a light switch.
“The CSV export falls over on big accounts — it buffers the whole thing in memory.” You file it the way you'd tell a colleague, in whatever words you have at midnight. No template, no ticket taxonomy, no estimating poker.
- 3:12 AMThe factory
Nobody is awake. Everybody is working.
A refiner turns your sentence into acceptance criteria. A planner writes the plan and gets it approved against them. A builder implements it in an isolated sandbox, QA runs the suite, a reviewer pushes back, the builder goes again. Three rounds. The reviewer stops finding things.
- 8:30 AMYou
One PR. One question. Coffee.
A pull request, already reviewed and QA'd, waiting for your yes. Beside it, one honest question: the fix changes a response's shape, and the reviewer wants you to pick. You answer it in a sentence. The rest of the night needed nothing from you at all.
The inbox
It never merges anything.
You do.
Six gates sit in the lifecycle where a decision genuinely belongs, and none of them opens on its own. Not because the agents are asked politely to stop — because there is no code path that crosses one without a human answer. Skipping a gate isn't discouraged; it is unreachable.
Every ask arrives in one queue with its receipts attached: the plan, the diff, the PR, the full transcript of what the agent actually did. Approve it, reject it with a reason the crew has to answer, or just reply to the question. Then close the laptop again.
- refineplan · diff · transcript
Is this the right problem, stated the right way?
- planplan · diff · transcript
Is this the right approach before anyone writes code?
- mergeplan · diff · transcript
Does this change go into your main branch?
- releaseplan · diff · transcript
Does it ship?
The lifecycle
A process, not a chat window
A chat forgets everything the moment you close the tab, which is why it can't be trusted with anything longer than an afternoon. ampm keeps a real database instead: every task is a row with its plan attached, its history intact, and its place in the tree of work it came from. Retries don't overwrite anything — they land beside the last attempt, because you should be able to ask what happened last time.
Refine before you plan, plan before you build, review before you merge — that discipline wasn't invented here. It's how the best San Francisco engineering orgs actually ship, distilled from fifteen years as an engineer inside them and codified into machinery. You get the institutional knowledge it takes a career to absorb, working for you from day one — and holding the bar even on the nights you wouldn't have bothered.
- Idea
- Refineyour call
- Planyour call
- Build
- QA
- Review
- Mergeyour call
- Released
Your rules
It reads your repo's rules. Then it follows them.
The AGENTS.md you already keep is the whole onboarding pack: your architecture, your code style, how this repo actually ships, the way you like commits and pull requests written. Every agent is told your guidance outranks generic best practice — and each one reads it for its own job. The builder picks up your idioms and your commit conventions. QA finds out how this repo verifies a change and runs that, not some invented checklist. The seat that ships knows what “shipped” means around here.
And when an agent needs a rule you never wrote down, it doesn't guess and it doesn't wing it. It does its best, flags the gap, and walks you through writing it down — so the factory keeps a running picture of what your repo expects, and every seat gets more personal to your codebase the longer it runs. Want one to behave differently? A stricter reviewer, a builder with house rules? That's a markdown file in .ampm/, checked in and reviewed like any other code.
A repository containing an AGENTS.md that every agent defers to, plus optional persona and step files under a dot-ampm directory that add your own instructions to individual agents.
The parts you'd ask about at 2am
Your main branch is never the test bench
Agents work in isolated containers on their own worktrees, with no path to your credentials and no way to push anywhere but a branch. The output of a night's work is always a pull request.
Read exactly what it did
Every turn keeps its full transcript. When a change surprises you, you don't reconstruct the reasoning from the diff — you open the run and read it.
Nothing quietly disappears
A retry is a new run beside the old one, not a rewrite of it. Failures park with the reason attached and wait for you, instead of looping until something gives.
One factory, all your repos
A workspace spans every repo you own, so a change that needs a migration in one and a client update in another is one piece of work with two children — not two tickets you have to keep in sync yourself.
Have a poke around
Three screens, and that's the whole app
There is no dashboard to configure and no workflow builder to learn. You file work, you answer what's blocked on you, and you watch the rest happen. Here it is, with invented data — open the inbox, answer a gate, and watch where the card goes.
Scroll a little further to load the demo
The board
Every piece of work, at the exact stage it's in. Positions aren't decoration — a card's column IS its state.
The inbox
One queue of everything blocked on you, each ask carrying the plan, the diff and the transcript behind it.
Activity
Who's working right now, on what, and what it cost — live, with every finished run still on the record.
Your infrastructure
It runs on your machines, or it runs on ours
The whole factory is one docker compose away: your Postgres, your Docker daemon, your repos, your box. Nothing about your code has to leave a machine you control. Or point the hosted control plane at a worker running on your own laptop and get the same isolation with none of the setup.