How the work stays organized
I run By Flip's Design with tools I built for it: design boards that turn decisions into work, local models that draft the code, and one loop that lands it.
Design boards
Every design question gets a board in my console: the options, a recommendation, my pick, and work items that each say when they're done. An item is closed with screenshots of the live page, at desktop and phone width, attached as proof.
Local models draft the code
A spec becomes a lane. A local model drafts each file in order, runs the compiler or the tests on it, retries with the errors, and opens a draft pull request with a scorecard for every file: a 30-billion-parameter coder on a ThinkPad, a 9-billion-parameter model on a Mac. A Claude agent then reviews the pull request and fixes whatever is still red inside it. Two recent API lanes passed 75% and 74% of their files on the first draft.
One landing loop
Pull requests land one at a time through one lander. Every 15 minutes a check looks for work. A green pull request is merged, deployed, and proven by reading the new commit back from the app's health check. A red one is fixed inside that pull request, never by opening a second.
Four machines at home
A Raspberry Pi is the always-on router and never runs anything heavy. A Mac is the main coding machine. A ThinkPad drafts with the biggest local model and builds the deploys. A fourth machine is a spare development and CI seat.
- First-draft pass rate
- 75% and 74% of filesthe scorecards of API PRs 1077 and 1081
- Landing check
- Every 15 minutesthe landing loop
- Machines
- 4the build mesh