Built with Claude Code

This whole system was written by an AI agent. Here are the receipts.

Not a demo, not a toy repo — the live internal system this company runs on every day: payroll, client billing, commissions, partner accounts, property P&L, access control. Every page, every migration, every line below was written by Claude Code, reviewed and shipped by one non-technical owner.

Stack

What it had to know

Nobody chose a friendly stack for it. This is a flat-file app with a hard security policy — no build step, no CDN, no framework — talking to a Postgres database where the access rules live in the database itself.

Speed

One ordinary day of work

Every line below is a real commit on main, with its real timestamp. This is a single day: twelve pull requests, from the morning through to late evening — each one specified in plain English, built, checked and shipped to production.

    The 19:50 to 22:17 stretch alone shipped seven pull requests and 2,461 lines — profit history extended back to 2018, a growth series at four different time grains, and a partner-settlement page. Deploy is a push: the server pulls from GitHub every two minutes, so "shipped" above means live for every user within two minutes of the commit.

    Judgement

    The work that isn't typing

    Writing code fast is the easy half. These are cases from this repo's history where the job was to notice something was wrong, prove it, and refuse to guess — the part that actually decides whether you can hand work over.

    Scope

    The jobs it already does here

    Not a list of things it could theoretically do. Each row points at work that is live in this repository right now.

    The jobDone here
    Honesty

    Where it must not be trusted alone

    This page would be worth nothing if it only listed wins. These limits are real, they are written into this project's own rules, and they are the reason the work holds up.

    Your turn

    Hand it something today

    The fastest way to settle the question is to give it a job you already know how to do, and time it. Three suggestions, in rising order of nerve.

    The way it actually runs here: you describe the change in plain English — "billing should end on the last working day", "it's hard to find new joiners in this list" — and get back a branch, a pull request, a written explanation of what it found on the way, and the docs updated in the same commit. You review the diff. Nothing reaches production without that.