Skip to content
Build and change

Change it without breaking it

The hard part of changing a working product is not writing the code. It is knowing what the change touches, what order to do it in, and how to tell whether it worked.

What this covers

From an intention to something that shipped

Work broken down

A goal turned into tasks that can actually be started, with an order that has a reason behind it.

Acceptance criteria

Written before the work starts, so finished means finished rather than demonstrated.

Migrations and risky changes

Staged, with a way back. The plan includes what happens when the second step fails, because sometimes it does.

Delivery

On the top level I build and ship it myself. Below that, I plan it and check what your team delivered.

How it goes

Short cycles with something working at the end

  1. A goal small enough to finish

    Agreed before anything starts. Large goals get cut until one of the pieces can be completed.

  2. The solution gets designed

    What it touches, what could break, and what will be done about that, decided before the first line.

  3. It gets built

    By your team under my direction, or by me with AI coding agents, depending on your level.

  4. It gets checked against the task

    Not against the demo and not against the impression. Against what it was supposed to do.

What this needs from you

This will not work if

The goal changes every week and nothing is allowed to finish

You want a fixed price for an open-ended product

Nobody can answer questions about the business rules

This works well if

You can say what the next meaningful result would be

You are willing to ship in pieces rather than all at once

You want the reasoning written down as you go

You would rather be told about a risk than surprised by it

Start with the area that worries you most

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