Build, automate, harden.

Most important software does not begin with a clean product brief. It begins with a recurring frustration.

Information is copied between tools. A person keeps the real status in their head. A field team fills out paper that someone enters later. A founder has an ambitious AI idea but no clear boundary for what the system should be allowed to do.

The temptation is to jump to automation. That usually makes the underlying confusion move faster.

I use a three-part operating method instead: build, automate, harden.

It is a sequence, but it is not a one-way waterfall. Each stage exposes information that changes the others. Hardening can reveal a weak product boundary. Automation can reveal that the initial workflow was incomplete. Building a usable slice can show that the original problem was stated incorrectly.

The route stays connected.

Build the smallest complete system

"Smallest" and "complete" both matter.

A small feature that leaves the real handoff untouched is not complete. A complete platform that takes a year before anyone can use it is not small.

The right first system changes an actual outcome and establishes the boundaries needed for growth.

That begins by understanding the operation:

Who is responsible at each step?
Where does information originate?
Which record is authoritative?
What does the next person need in order to act?
Which existing tools must remain?
Where do errors become expensive?

Only then should the stack become the center of the conversation.

Building also includes the experience. A technically coherent system can fail if it ignores how and where people work. A mobile field flow and an office planning surface may share data while requiring very different interactions.

The goal is not one interface everywhere. It is one understandable operation.

Automate the stable movement

Once a workflow is clear enough to use, automation can remove repetitive coordination.

Good candidates are usually stable decisions or predictable movement of information:

Carry a verified update into the next system.
Schedule recurring work.
Route a request to the responsible person.
Generate a report from a shared operational record.
Retry a safe operation after a temporary failure.
Surface an exception when the routine path no longer applies.

The exception is as important as the happy path.

If an automated process can fail, it needs a visible state, a retry rule, and an owner. If an action has meaningful consequences, it may need human review before execution. If repeating an action could create duplicate records or charges, idempotency belongs in the design.

Automation should reduce friction without making the operation opaque.

Harden the real system

A demo is protected by ideal conditions. Production is where context is missing, dependencies fail, users behave reasonably in ways the builder did not predict, and releases meet state that already exists.

Hardening means designing for those conditions.

I look for:

Explicit system and authority boundaries
Automated and adversarial tests
Independent evaluation where the builder's assumptions need pressure
Observable operating state
Controlled deployment and post-release validation
Backups with a tested recovery path
Rollback that changes only the intended scope
Clear ownership when a gate fails

The phrase "builder is not tester" is especially important for autonomous systems. The same agent that produced a deliverable should not be the only authority deciding whether the work is correct.

Hardening is not a final coat of paint. It feeds back into the product. If a system cannot be observed, recovered, or evaluated, its design is incomplete.

A field-work example

Imagine an operation using spreadsheets, paper reporting, and several disconnected business tools.

The build stage does not begin by copying every spreadsheet into a new database. It maps the real workflow, identifies the shared record, and gives office and field roles focused surfaces for their work.

The automate stage connects stable information flows. A field update can reach planning and reporting without manual re-entry. Routine paths move. Exceptions become visible instead of disappearing into an individual's inbox.

The harden stage tests incomplete and repeated updates, integration failures, mobile connectivity, and recovery. The team validates the deployed product in its real route and keeps a controlled way back.

The result is not "an automated spreadsheet." It is a clearer operating system.

The method is also a filter

Build, automate, harden helps decide what not to do.

Do not automate a decision nobody can explain.

Do not add an agent where a clear form and a deterministic rule would work better.

Do not build a broad platform when one complete workflow can prove the boundary.

Do not call a release complete before the deployed path is verified.

Do not collect evidence without deciding who will review it.

Each constraint protects the outcome from unnecessary complexity.

What good delivery feels like

At the end of the cycle:

People understand the workflow.
The product supports the real operation.
Routine coordination happens with less effort.
Exceptions have an owner.
Important actions leave evidence.
The deployed system can be observed and recovered.
The next change has a trustworthy foundation.

That is the standard I mean when I say I build systems that hold up in the real world.