Skip to content
Understand the system

What do you actually own?

A product built quickly with AI coding agents is rarely documented and often not fully understood by anyone, including the person who prompted it into existence. This is where we start.

What this covers

Getting to a description you can trust

An inventory of what runs

Services, jobs, scheduled tasks, external dependencies and the things nobody remembers deploying.

An architecture description

How the parts relate, where the data lives, what talks to what, and which of those connections are load-bearing.

How it is deployed

Where it runs, how a change reaches production, and what happens today when something goes wrong.

Where it is fragile

The parts that would hurt most if they failed, named before they fail rather than afterwards.

How it goes

From “I am not sure” to a description on paper

  1. You tell me what you think you have

    In your own words, including the parts you are unsure about. Being unsure is the normal starting position.

  2. The system gets read, not guessed at

    Either by me, or by an AI agent running a prompt I wrote for exactly this, with the evidence requirements that keep it honest.

  3. You get a description you can hand to anyone

    Short enough to read, specific enough to act on, and correct enough to argue with.

When this is worth doing

Probably not yet if

The product is two weeks old and you built all of it this month

You already have current architecture documentation you trust

The only thing you need is one specific bug fixed

Worth doing if

AI agents wrote most of it and nobody reviewed all of it

People have come and gone since it was started

You are about to make a decision that depends on how it works

You need to explain the system to an investor, a buyer or a new developer

Start with the area that worries you most

Pick the level of involvement that fits, describe your product, and we begin there.