How I build

Document uploads in 50RH were marked live, and every upload failed. Using the live app on 3 Aug 2026 showed it, and the fix took five steps, done by 4 Aug. Since then, shipped means I’ve seen it working live, not that it merged.

That is the method in small: get to production fast, then check it there. The rest of this page is how one person does that across several products.

Plan, audit, build, review

Feature work runs through four steps. AI does most of the work inside each one, and I start every step after the plan.

1. Plan. Once a week a planner reads the roadmaps of 50RH, Lantern and this site, checks each candidate against the code as it actually is, and ranks what to build next. It has run on a schedule since 27 Aug 2026, and all it writes is a plan.
2. Audit. Before any code, a separate AI reviewer reads the chosen spec and asks whether it’s the right change, whether it’s complete, and what will bite during the build. It answers go, go with changes, or hold.
3. Build. The change is built in its own working copy as a draft pull request, exactly as the audited brief says, with the tests the brief names.
4. Review. A code review before anything merges. Changes to sign-in, database migrations and billing get a fuller look.

I don’t approve every merge by hand. A session I started may merge once the code review is clean and the change adds tests. That rule dates from 8 Aug 2026, and sessions have been able to act on it since 22 Sep 2026. Public copy, including every word on this site, is never merged by the agent that wrote it. And by standing rule, nothing that runs on a schedule merges anything: clio’s scheduled jobs only write reports.

From intake to release

The four steps above carry a change from plan to merge. Around them is the whole lifecycle, and each stage below has a real example. Where my record is thin, I say so.

1. Intake. For Lantern, once the first prototype worked, I wrote down three untested guesses about who would pay and an interview plan that asks about past behavior and never pitches, and set a rule to build nothing new until those interviews say otherwise. None of them has happened yet.
2. Prototyping. A prototype runs on seeded data until it has earned real users: Lantern is a guided demo around a made-up family, with a “Viewing as” switcher that redraws each screen for every family role. A written bar says what it must clear before a real family signs in.
3. Code review. Every change gets the review step above, and a second AI model from another vendor can read it too. I check each of that model’s findings against the code before I act on it: in DeHoardMe, its headline finding on a change to the payment code was wrong.
4. Stacked pull requests. A large change goes out as small pull requests stacked on each other, so each diff holds only new work. The first screens of 50RH’s repair-job workflow went out as four, merged in order on 3 Aug 2026, and clio’s mission-control console went out the same way.
5. QA. I had AI write browser tests for 50RH’s public bid, entry and invite links and a manager’s daily loop, with accessibility scans that forced real fixes, such as a page language the whole app was missing. Video is the thin part: the only recording so far is a walkthrough of Lantern’s seeded demo, made on 30 Aug 2026.
6. Release candidates. DeHoardMe goes to its beta testers as numbered TestFlight builds. Build 15 couldn’t be made while the iOS archive on main was failing, so I fixed the archive first. 50RH has no staging environment yet: a backend pull request with the preview label gets its own temporary service, though not its own database, and a merge to main deploys straight to production.
7. Release. A release ends when I’ve seen it live. For 50RH’s What’s new panel I merged the backend first, checked in production that its new route answered, asking for a sign-in rather than saying “not found”, and only then merged the app.
8. Educational materials. DeHoardMe’s Build 15 notes tell beta testers in plain words what changed, and correct three promises from Build 14’s notes that the app couldn’t keep. 50RH’s product tour walks through each stage of a job in real screenshots from the demo account.

Tests and guards

Each product’s checks run where its code lives. The counts move, so each one carries its date.

• 50RH. Every pull request runs the test suite before it can merge, and it runs again after the merge to main. The latest runs on main, read 5 Oct 2026, passed 3,139 tests: 1,865 in the backend, 1,209 in the app and 65 on the marketing site.
• Lantern. Every pull request runs the typecheck, lint, the full test suite on a scratch database and a production build. The suite had 95 tests on 30 Sep 2026. Its integration tests run against a database that also holds a second, fully populated family, so a query that forgets which family it’s in fails instead of passing by luck.
• DeHoardMe. Backend tests run on every pull request and every push to main that touches the backend. There were 218 when the change that reworked Expert scans merged on 1 Sep 2026. Every push to main also checks that the iOS app still builds.
• clio. The suite runs on every pull request and every push to main. Its own docs listed 1,015 tests on 3 Oct 2026.
• WPHostGuy has no automated tests. Instead, most of its pull requests say what was checked by hand, and some say what wasn’t. After a deploy, the files on the server are checked against the repo, every page is loaded and a test enquiry is sent.
• Small tools. ccf, a small command-line tool of mine, had 15 tests on 5 Oct 2026, and I run them by hand. No CI runs them.

Some checks exist to catch a product saying something untrue, and the same kinds turn up in product after product:

• 50RH’s marketing tests fail if the copy says 50RH verifies, vets or guarantees a contractor, or if the unfinished sensor hardware comes back to the main navigation.
• In DeHoardMe, a test fails if the repo’s own docs deny a check that the payment webhook actually makes.
• In clio, a plain script compares the docs with the code, and a test holds it in CI.
• Backups are proven by restoring them. 50RH’s monthly drill restores the newest backup into a throwaway database and checks it. The scheduled drills on 1 Sep and 1 Oct 2026 passed. WPHostGuy’s backups were proven by a test restore on 5 Oct 2026.
• A second AI model reviews changes. In Lantern it reviews on request and never blocks a merge. In DeHoardMe, since 17 Sep 2026, every pull request that changes code gets one before it merges, re-run after fixes for up to three rounds. An empty answer is posted as no review, not counted as one.

How I use AI

AI writes most of the code. In 50RH, 604 of the 761 commits on main in 2026, up to 4 Oct, carry an AI co-author line. That’s the point, not a caveat: it’s how one person runs several products.

I hand AI the weekly plan, the audit, the code and its tests, a first review, and the first draft of this site’s copy. What stays with me: what to build, the go or hold after an audit, using the thing live before I call it shipped, the words that go public, and every call where I go against the analysis.

The call

The analysis said: to save build minutes, stop running 50RH’s backend tests after each merge to main.

I decided: keep the safety nets, and raise the overage cap instead.

I closed that pull request within about a minute and restored the type check that runs after merges. That was 9 Aug 2026.

A few more of the calls, each with its date:

• In 50RH, I made the wording checks on tenant notices advise rather than block (10 Aug 2026).
• In 50RH, I won’t pay about $400 a month to test an integration until a customer on that plan brings a key (11 Aug 2026).
• In DeHoardMe, I froze new work instead of shipping the next feature its plan called for (4 Oct 2026).

I check the AI’s checkers too. Six known-stale lines were planted in clio’s docs, with the answers kept outside the repo. The monthly AI self-audit found 0 of the 6, and it had no verified findings in three cycles. I retired it on 1 Oct 2026 and put the plain script in its place.

Cost gets the same treatment. clio’s cost line once printed only a job’s last call: one job showed $0.024466 when it had really cost $0.089145. The fix shipped on 11 Aug 2026. Every scheduled clio job has a spending cap per run, and a model with no known price is refused. The scheduled checks cost about $0.42 in the 30 days to 5 Oct 2026, read from clio’s cost ledger. That doesn’t include the flat monthly AI subscription the planning and building run on.

Nothing an AI job proposes as a fact is used until I copy it into the reviewed set by hand. There is no command that promotes it automatically, by decision.

How this site is checked

This site is held to the same rules as the products. Its tests fail when:

• a number written in figures on a product page or on one of these pages doesn’t sit inside a sentence that a listed source quotes exactly, or a source quotes a sentence the page doesn’t have;
• a number is tucked into a component’s settings, where no quote can reach it;
• a build-log entry is dated in the future, runs past 160 characters, holds a web address or names no record behind it;
• a product’s status isn’t one of the six words: live, beta, shipped dark, prototype, in discovery, paused;
• an image has no record of where it came from, or changed after it was reviewed;
• a link leads to a page the site doesn’t have, or to a part of a page that isn’t there;
• a page ships any script but the analytics loader, a color is written outside the design tokens, or a color pairing falls short of its contrast in either theme.

The number check is tested against files that are wrong on purpose. An unsourced number planted in a product’s text, in a clock entry, in each field a reader sees and in a page’s description is reported every time. The count on the home page comes from a script that counts merged pull requests, and it always shows the day it was read.

CI runs all of these tests on every pull request. On 6 Oct 2026, all 199 of them passed. An agent may draft the words here, but every word a visitor reads is mine to approve.