Skip to content
Private beta

AI-native invoicing SaaS

An EU tax-compliance invoicing SaaS I built on my own. Claude agents wrote most of the code. I set the direction, reviewed every change and merged it.

Anonymised on purpose: no name, link or screenshots.

  • 100%of pull requests reviewed and merged by me. Nothing merges itself
  • 100%of CI gates seen failing on purpose before they count
  • ~90%fewer failing dependency audits once the audit gate was in place
GatesClaude reviewClaudeorchestratorClaude writer 1Claude writer 2Claude writer 3another roundMereview and mergeStagingClaude QAChispi, watching
ClaudeorchestratorClaude writersGatesClaudereviewanotherroundMereview and mergeStagingClaude QA
a piece of worka gate: red first, then greenanother round with Claude

The product

What it is

An invoicing product for freelancers and small businesses, built to comply with a European country's mandatory real-time invoice reporting regime: invoices are reported to the tax authority as they are issued, and the records can't be changed afterwards.

Claude agents wrote most of the code, in every layer: database, API, web apps, infrastructure and tests. It runs as a private beta on a staging environment. Nobody pays for it yet, and it has never been promoted to production.

What it covers

  • Invoices, corrective and simplified invoices, quotes and delivery notes
  • Customers, a product catalogue and expenses
  • AI-assisted document capture (OCR + LLM)
  • Tax calculation and periodic tax reports
  • PDF templates and email delivery
  • Bank reconciliation through open banking (simulated on staging)
  • Subscription plans and billing
  • Several tenants on one platform, each isolated from the others
  • Real-time reporting to the tax authority, with tamper-evident, append-only records

Scale

The size of it

This is a big product, and that is the point: one person directing agents covered all of it, in every layer.

  • Apps

    The product, an admin console, a landing site and the API, plus background workers and a tax-authority mock.

  • API

    Hundreds of endpoints behind the web apps.

  • Screens

    Product, admin and landing, each a full app with its own flows.

  • Database

    A large relational schema in PostgreSQL.

  • Row-level security

    Hundreds of policies keep each tenant's data apart.

  • Background work

    Workers and scheduled jobs outside the request path.

  • Triggers

    Many of them guard records that must never change.

  • Tests

    Tens of thousands, across backend, frontend and end to end.

Integration categories

  • Payments
  • Email
  • Open banking
  • Tax authority
  • EU VAT number validation
  • Object storage
  • Authentication
  • Caching and queues
  • AI document capture
  • Bot protection
  • Observability
  • DNS, CDN, VPN and TLS

The work behind it

What it actually took

Claude wrote most of the code. Getting to code I was willing to merge was the hard part, and that part was mine.

  1. 01Many rounds with Claude

    Work often took several rounds. I pushed back on output that looked right but wasn't, and kept going until it met the bar. Code that compiles is where review starts.

  2. 02Designing the pipeline as a product

    I designed the multi-agent, multi-session setup and kept improving it as it failed in new ways: how work is split, how agents stay out of each other's way, and what has to pass before anything merges.

  3. 03Owning the domain

    Tax-compliant invoicing has rules an agent can't guess. Understanding them and deciding how the product handles them was my job. The compliance subagent checks the work. It doesn't make the calls.

  4. 04Owning the architecture

    Tenant isolation, records that can't change, how money is rounded, how releases reach staging. I made those decisions, and the agents worked inside them.

  5. 05Being the quality bar

    Nothing merged without my review. Every pull request went through me, one at a time.

Who does what

One developer, a team of Claude agents

I set the direction and made every product call. Claude sessions wrote most of the code in parallel, and nothing reached the main branch without passing the gates and my review.

Diagram of the agent team. I direct an orchestrator, Claude acting as project manager. It runs several Claude writer sessions in parallel, each in its own git worktree. Their pull requests go through the CI gates, then a review by a read-only Claude reviewer, with a tax-compliance specialist called in when a change touches money or tax. I merge one pull request at a time. The change deploys to staging, where a Claude QA session tests it.

Me

Direction, product decisions, final review and every merge.

Claude as orchestrator

Works as the project manager. It plans and hands out the work and keeps an eye on everything that runs.

  • Continuous loop
  • Shared memory
  • Plans and assigns

  1. Writers

    Several Claude sessions at once, each in its own git worktree. A cap on how many run together keeps the machine stable.

  2. Gates

    84Seen redThen green

    Executable checks in CI. A gate only counts once I have seen it fail.

  3. Review

    • Reviewer
    • Compliance expert

    A read-only Claude reviewer checks every pull request before I do. A compliance specialist joins when a change touches money or tax.

  4. Merge

    Me

    I merge one pull request at a time. Nothing merges itself.

  5. Staging and QA

    Staging

    A failed deploy rolls itself back. A Claude QA session tests staging in a real browser.

  1. Rules and memoryWhat the agents must know and must never do, versioned with the code.
  2. SkillsSkills for the work that keeps coming back.
  3. The orchestration loopClaude keeps the work moving and checks the plan against what actually happened.
  4. GatesExecutable checks. A check only counts once it has been seen red, and every bug fix must come with a test that fails on main.

Evidence

How I measured whether it worked

Agents produce a lot of code quickly, so the question I kept asking was how I would know it was correct. The answer became four rules.

  1. Three proofs per gate

    A check doesn't count until it has passed three proofs. One of them is breaking the code on purpose and watching it go red.

  2. Mutation before trusting green

    A passing suite says little until mutations show it can fail.

  3. Predictions before measurements

    I write down what I expect before I measure, so the result can prove me wrong.

  4. A regression test for every fix

    It has to fail against main. If it passes on the broken code, it doesn't prove the fix.

Mutation testing on the tax calculator

After I fixed which tests the run selected, most of the surviving mutants were gone. The run got a little slower.

The pipeline, before and after moving to an orchestrated multi-agent workflow

Before
a sample of pull requests from a window before the change
After
every pull request merged in a window of the same length after it
MeasureChange
Merge throughputHigherbetter
Size of the largest pull requests (90th percentile)36% smallerbetter
Median pull request sizeAbout the samea little larger
Time from opening to merge, medianLonger, merges were serializedworse

After moving to an orchestrated multi-agent workflow, more pull requests merged and the largest ones got 36% smaller, while the median time to merge went up because merges were serialized. That row is there because it's true.

The comparison is observational, not controlled. The two windows count different populations, other things changed at the same time, and the later window was dominated by a run of bug fixes merged one after another.

I don't quote test coverage. I haven't measured it, and I have seen a green check that tested nothing.

Pace

The pace

How the work moved along.

Merge activity

Illustration, not real figures.

  • In parallel

    Several Claude sessions at once, each in its own git worktree and on its own piece of work.

  • One reviewer

    Every pull request went through me, and I merged them one at a time.

  • Steady

    Merges landed often. The work moved forward one pull request at a time.

Tools

Stack

  • Backend

    • Python
    • FastAPI
    • Pydantic v2 (strict)
    • async SQLAlchemy
    • Decimal money

  • Frontend

    • TypeScript (strict)
    • React
    • Vite
    • Tailwind
    • shadcn/ui
    • TanStack
    • Zustand
    • Zod

  • Data

    • PostgreSQL
    • Tenant isolation in the database
    • Immutable records

  • Infrastructure

    • Terraform
    • Kubernetes (K3s)
    • CDN and DNS
    • Private network (VPN)
    • Metrics, logs and alerting dashboards

  • Delivery

    • CI pipelines
    • Self-hosted runners
    • Staging with auto-rollback
    • Promotion workflow

  • Testing

    • pytest
    • Real-database tests
    • pgTAP
    • Vitest
    • Playwright
    • mutmut

  • Payments

    • Card payments and subscriptions

  • AI in the product

    • Document capture with OCR and an LLM

  • AI tooling

    • Claude Code: orchestrator, writers, reviewer, compliance, QA

Where it stands

Private beta

A small, invite-limited private beta on staging. No paying customers, no real submission to the tax authority yet, and no production release.

What's missing for production

  • Registration with the tax authority to submit invoices on behalf of users
  • Refunds and payment disputes for subscriptions
  • Production infrastructure and the first promoted release

Want to hear more about how it was built?

If you're hiring for AI-native product engineering, I'm happy to walk you through the architecture, the agent setup and the trade-offs in a call.

Why it has no name here

I keep the product anonymous on this site, so there's no name, link or screenshot. I'm glad to go into the details in a conversation.

Chispi's noteEvery gate on this page had to fail on purpose before it counted.