How I build
These days, agents write most of my code. I plan and check the work, and I decide what ships. I rebuilt DepthChartIQ this way, from its founder's prototype to a production app with billing, in about nine weeks.
How a change ships
- I write the plan first. It says what the change should do and how I'll know it works.
- Agents write the code on a branch.
- Checks run on the pull request before I look at it. At TradeCanny, that included a fixed set of coaching test cases.
- A second model reviews the change and looks for ways to break it.
- I read the plan, the checks and the review, and I decide what ships.
Status pages
I've started giving the people I build for a live status page. It shows what's live, what's being built and what's coming next. While the work is moving, it updates itself from the running system every two hours, so nobody has to ask me where things stand.
Here's the whole page for Jocasa, a real-time analytics and quant platform on Robinhood Chain that I started building in September.
Model gateways
Every company I build AI features for gets its own model gateway, a small server that sits between its apps and the AI providers. The apps call the gateway instead of Anthropic, OpenAI or Google, and the gateway holds the provider keys, passes each call to the right provider and writes down what it cost. I've stood up a dozen since 2025, and most of them still run.
Vers1ons gives every app that calls the gateway its own key with a hard monthly cap, and for most of those keys, Slack gets an alert before the cap is reached. DepthChartIQ's apps ask the gateway for a kind of model, such as a fast one, instead of a model by name, so swapping a model is a one-line config change and no app has to change with it. If a model fails there, most calls move to one from another provider. The company's AI advisor, Spotter, won't send a model call anywhere else, and for each answer it looks up what its model calls cost in the gateway's ledger.
I also test whether a cap holds when requests pile up. On one of my gateways, I gave a test key a budget of a hundredth of a cent and sent up to two dozen requests at it at once, and spending stopped under the cap. Another test on that gateway found a hole I had missed. A single 1.1 MB prompt crashed it, so now a guard in front of it turns away anything over 256 KB before the gateway reads it.
Setting up a new company's stack
I built tooling that sets up a gateway and everything around it. For a new company it goes from nothing to a working stack: the GitHub organization and repo, hosting, the database, secrets, background jobs, the web app and the gateway. DepthChartIQ took about two and a half hours. Every model the gateway offered had to answer a real request before I called it done, and each shortcut went on a written list with a deadline. The first item on that list moved the company off my own AI keys and onto its own accounts.
Every repo I start from my template gets a gateway as its own service, next to the web app, the worker and the database, and the code that calls it refuses to run without a gateway key.
Setting up teams to ship
I set up each codebase so other people can ship on it. The Vers1ons engineers share a set of agent skills, the written instructions their coding agents follow for jobs like shipping a change. I wrote most of them, and they've written their own too, including the rulebook for the design system and a skill for splitting royalties. One of the engineers built the preview environments: any branch gets one from a Slack command, and it deletes itself after a day.
In DepthChartIQ's first week, I wrote a skill that sets up a new teammate's laptop. It asks before it installs anything and explains what each tool is for as it goes.
Who ships the code now →Who owns the code
Vers1ons, DepthChartIQ and FlipSmart each keep their code in their own GitHub organization, so I describe my part instead of linking it.