CASE STUDY · MY OWN COMPANY · STATUS: IN PRODUCTION

The system I actually run my company on.

Seven departments, one command box, one approval inbox, and a rule the software enforces structurally: it never sends, publishes, books, or spends on its own. Deployed, and used every working day.

Status, plainly. This one is deployed and in daily use. It is also a single-user system, and that user is me. It has never been sold, installed, or operated for anyone else. I have no third-party uptime figures, no client ROI numbers, and no case where someone other than its author has had to live with its decisions.

What you can evaluate here is the architecture and the operating rule — not a track record with customers, because it does not have one.

THE PROBLEM

The work lived in eight places.

I run a marketing company. The work lives in email, the calendar, the CRM, the analytics, Stripe, the content pipeline, the prospect list, and my own head.

Every morning started the same way: twenty minutes of opening tabs to work out what mattered. Not doing the work. Finding the work.

THE SEVEN DEPARTMENTS

Each one owns a job and stops before acting.

In production

Prospect research and outreach

Finds them, researches them, judges fit, drafts the intro, and stops. The send queue needs me.

In production

Content

Drafts per channel against real brand context. Schedules nothing on its own.

In production

Analytics

Pulls the numbers and tells me what changed — not that everything is up and to the right.

In production

CRM

Companies, contacts, deals, tasks, notes, pipeline. Flags what has gone quiet.

In production

Mail and calendar

Three mailboxes and three calendars merged into one surface, with contacts matched across them.

In production

Money

Owed, late, received, held. A read-only Stripe view — the client has no HTTP verb but GET.

And the seventh: a cross-department review that owns no records of its own. It reads across the other six and tells me what actually needs me today. It is the one I open first.

ARCHITECTURE

The approval inbox is the centre, not a feature.

Three things tie the departments together. A natural-language command box on every screen, so there is one place to type what I want instead of remembering where the button is — and it refuses rather than guesses when it is unsure. A single approval inbox holding everything the system wants to do. And an endpoint that lets Claude reach the system directly from a chat window.

The important design decision is the second one. Every department produces something that waits. Nothing has a path to the outside world that does not pass through one queue that I read.

THE RULE

It never sends, publishes, books, or spends on its own.

Everything it produces waits for a human. That is structural — it is not a setting I could disable on a busy Tuesday, and that is the point. The money client has no write verb. The CRM client has no write verb it does not need. The tools that can write are counted, and a test fails if that count changes. Any system I build for you inherits this.

WHAT THIS MEANS FOR YOU

This is the reference architecture.

When I say I would build you department agents, one command surface, and a single approval inbox, I am not describing a diagram. I am describing the thing I open first every morning.

The difference is that yours would have more than one user — which means roles, permissions, and someone other than the author living with its decisions. That is real additional work and I would scope it honestly rather than pretend it comes free.

See what I would build for you.

Start with the Map. Two weeks, $750, and a plan you own either way.

What gets built →

Start with the Assessment The real estate case study