Two questions from Gera: should we pull pieces like the landing page out of the main app, and what are the biggest speed and cost wins still on the table?
Oct 30, 2026 · research only, nothing in CI changed · nothing ships before Fede's 48-hour watch ends (Oct 31, 22:40 CT)
Keep one repo, but stop treating every change the same. A change to the marketing site should take a short, cheap path. Today it waits in the same line as a change to Clara, and that's the real problem, not where the code lives.
One repo and one path for every change.
CI looks at which files a change touches. Marketing-only? It skips the heavy product tests and goes straight through.
The code stays in this repo, but the marketing site gets its own Vercel project. It only builds when its own files change.
Move the website into its own repo with its own CI.
| Piece | Pull it out? | Why |
|---|---|---|
| Dev tools, scripts, evals | smart routing instead | They're about 16% of the merge-line tests, roughly 1 minute. Teach CI to skip them when a change doesn't touch them, which gets the same result without moving anything. |
| Several merge lines, one per area | not possible | GitHub allows one merge line per branch. Ours already tests 8 groups at once, so it isn't the bottleneck. |
| Several deploy clusters | already done | Web, the 6 Lambdas and the renewal worker already deploy separately and at the same time. |
| CI's own plumbing | yes, shrink it | This is the part that's actually overbuilt: 93 workflows, one 7,642-line config file, and about 76,000 lines of tests that only check CI itself. 53 of the last 200 changes were to CI plumbing. |
Sources: file counts and change counts from git on origin/main, Oct 16–30; CI timings from about 40 recent deploys and the GitHub Actions job logs.
Fede's work already cut the wait roughly in half. A change used to take about 2 hours from opening to live. Today it's about 73 minutes, and about 21 minutes from approval to live. The items below are what's left.
| # | What | In plain words | Time saved | Money | Effort |
|---|---|---|---|---|---|
| 1 | Fix one slow check on every PR | One safety check ("mutation controls") averages 5 minutes and has taken 35. It's about a fifth of all PR computer time. | 3–4 min on average, up to 30 on bad days | saves | Small |
| 2 | Stop Vercel building the app twice | CI builds the app, then Vercel builds the exact same thing again from scratch before publishing. Publish CI's copy instead. | About 5 min off approval-to-live | saves a little | Medium, prove it first |
| 3 | Split the merge line's slowest job | One big batch of tests sets the pace for the whole merge line. Run it in 2–3 pieces at once. | 2–3 min | About the same | Small |
| 4 | Smart routing (tab 1) | Marketing, docs and tools changes skip the product tests. | 15+ min for those changes | saves | Small |
| 5 | Fewer CI runs per change | Each change runs CI about 4 times before it merges (about 1,050 runs a day for 270 merges). PR runs are about 80% of what CI costs. | None | biggest cost lever | Medium |
| 6 | True emergency lane | Your pick: an urgent fix skips the merge line, tests and review, and goes live once it builds. Still capped at 3 a day, needs an incident note, and risky files are blocked. Fede reviews this one first. | Emergency fix in 10–12 min (today 30+) | None | Medium |
| 7 | Something that takes charge when main breaks | Today a bot posts a note and names a fixer. Nothing acts. The plan: one place decides "main is broken", merges pause, every agent gets told, and if nobody fixes it in 30 min the bad change is undone automatically. | Stops the slow, costly stalls | None | Larger |
| 8 | Put a real dollar number on CI | Nobody tracks CI spend today. About $75 a day is last week's estimate against the $65 target. A daily number on the factory page lets every change above be judged in dollars. | None | Makes cost visible | Small, do it first |
Sources: GitHub PRs and workflows on origin/main; Fede's plan page ci-two-hours-2026-10-29; the 20:54Z checkpoint numbers.