02 / the working method

clear decisions. working systems.

The work should get easier to understand as it moves forward.

Four stages connect a useful problem to software that can be operated.

understand the constraints.

Start with the people using the system, the outcome they need, and the conditions the work has to respect. Existing software, data access, ownership, and operational limits all belong in the conversation.

what you can inspect: A shared problem statement, constraints, and open questions.
what we need together: Your current workflow, the desired change, and what already exists.

define the shape.

Map the system and the critical paths. Make the scope, interfaces, permissions, and failure cases explicit. For AI workflows, define evaluation examples and the decisions a person must review.

what you can inspect: Architecture decisions, a sequenced scope, and acceptance criteria.
what we need together: Decisions on priorities, tradeoffs, and access to the necessary systems.

build. inspect. verify.

Implement in reviewable increments. Walk through the real workflow, test the important behavior, and inspect the result on the devices and environments that matter. Keep unresolved issues visible.

what you can inspect: Working software, verification evidence, and an issue record.
what we need together: Timely review of the product behavior and feedback from the people using it.

prepare it to operate.

A release is a transition into operation. Document deployment, access, monitoring, recovery, and ownership. Agree on the handover and any continuing engineering support before calling the work complete.

what you can inspect: Source and system documentation, runbooks, and a handover plan.
what we need together: A named system owner and decisions on release and ongoing support.

working principles

the standard is
in the details.

make tradeoffs explicit.

Every system has limits. Write down what a choice buys, what it costs, and what would change the decision.

keep people in control.

Automation needs clear permissions, review points, and a useful recovery path when the unexpected happens.

leave evidence.

Use reproducible checks and observed behavior. A passed build, a tested workflow, and a remaining limitation are different things.

next / make it concrete

let’s define the work.

scope a project

You don’t need a polished specification.
A real problem is a useful place to start.