Systems we have built and run
Each case study says what we measured and what we did not. Client names appear only with written permission; where a name is withheld, we say so up front.
An operations platform for a tax-services firm
Client name withheld at the client's request. The firm is affiliated with our founder, and we say so because you would want to know. Figures are from our own validation runs in May and June 2026.
The challenge
A US tax-credit recovery firm ran its billing from a spreadsheet one person maintained by hand. Refunds were spotted in IRS account-monitoring emails, matched to fee rates in the accounting system, invoiced, and chased, with every step living in someone's inbox. The firm needed the numbers to come from systems, not memory, without changing how its accountants work.
Our solution
We built an operations platform that reads the accounting ledger in QuickBooks Online read-only, parses IRS alert emails into de-duplicated refund records, reconciles them against fees, and drives follow-ups on a schedule. A second service pulls IRS transcripts through the IRS e-Services application-to-application API. Inbound mail is routed with Claude, with a person approving anything that would create an invoice or send a message.
Our approach
We rebuilt the manual spreadsheet from source data first and compared it to the original, client by client, before anything went live. Email routing was tested by replaying thousands of historical messages, never by sending test mail to real inboxes. Every action that touches money starts in dry-run.
Measured
- 1.00Median ratio of refunds detected from IRS alerts to the firm's hand-kept ledger, across 151 clients
- 4,126Historical emails replayed to test inbox routing before it read live mail
- June 2026IRS transcript retrieval live in production
Key facts
- Refund records de-duplicated from thousands of raw alert lines, because the same refund echoes across many IRS emails
- Payment detection is designed as two passes: a fast model routes, and a second model must confirm before anything can trigger billing
- Runs on Railway with Postgres, a scheduler, and a browser worker for a partner portal that has no API
What we did not measure: hours saved per week. The firm has not been running on it long enough for that number to be honest.
Stack
- Python
- FastAPI
- PostgreSQL
- Playwright
- QuickBooks Online API
- Microsoft Graph
- IRS e-Services API
- Claude
- Railway
Have a back office that runs on spreadsheets and inboxes?
Talk to us about itA fleet of AI coding agents with a human gate
Our own system, built and rebuilt through 2026. It runs every project on this page. No client code or names appear in anything we show about it.
The challenge
AI coding agents are fast and wrong in predictable ways: they call a job done because one test passed, wander into files they do not own, and stop silently when they hit a rate limit. Running many at once multiplies the speed and the mistakes, and token costs climb with every session.
Our solution
A job queue that starts one Claude Code session per job, each in its own git worktree of the target repository, each metered. Automated checks run on every branch and fail first. A senior engineer is the gate: nothing merges, deploys, or deletes without one.
Our approach
Each failure mode got its own check, and the checks live in the same branch as the work so they cannot be skipped. Health checks look for the exact response we expect, and a bare success code does not count.
Measured
- 1Isolated git worktree per job, so parallel agents cannot overwrite each other
- 0Merges or deploys without a person
- Every branchCarries its own cost, printed where the reviewer sees it
Stack
- Claude Code
- git worktrees
- GitHub
- Playwright
- Railway
Want this speed on your product, with the same gate?
Start a projectA read-only production-readiness scanner
Our own tool, built and hardened in September 2026. It is live on this site.
The challenge
Apps built fast, especially with AI app builders, tend to ship the same handful of problems: keys in the browser bundle, a service-role key exposed to users, database tables any visitor can read, missing security headers, and environment or git files left public. Owners rarely know until someone else finds them.
Our solution
A single TypeScript module with no dependencies, behind one API route. It loads a page the way a browser does, reads the scripts it loads, and checks for that list of problems. It returns a ranked list of findings and a grade.
Our approach
The scan proves as little as it needs to. An early version read a real row to show a table was open; the shipped version reads nothing and only checks whether the table answers. Acceptable-use terms went live before the route did.
Measured
- 0Writes to the site it scans
- SecondsPer scan, with a hard time limit in the code
- 0Results stored, unless you ask us to email them to you
What we did not publish: a scan count. It is shown only when it is read from data with a date.
Stack
- TypeScript
- Next.js route handler
- Railway
See what it finds on your app
Scan my app