The process
03 / 04
Build.
My job is to turn an identified problem, an approved design, and a defined set of boundaries into a tool that works inside the business that asked for it.
Turn decisions into capability
This is where the idea becomes tangible.
Connections begin moving real information. Rules encounter exceptions. Interfaces meet the people expected to use them. The quality of the build depends on how faithfully it carries the reasoning that came before it.
Editorial image
new capability fitted to existing work
01 · Fit the operation
Build around the business that already exists
Custom work earns its place by fitting the operation. I build around the systems, habits, and responsibilities your team already understands whenever they remain useful. That takes different forms: placing a capability inside an existing platform, connecting applications that have never shared information, or creating a focused tool for a job that current software handles poorly.
The form changes with the engagement. The principle does not. Your people should not have to compensate for the tool by inventing new manual work around it. Information should move with purpose. Controls should appear where decisions happen. The build should respect the security, privacy, and ownership choices established during Design.
This also keeps the work right-sized. I build the capability we agreed to solve, with enough structure to support its intended use. Features that belong to a later need do not quietly enter the project and consume the budget meant for the current one. If construction reveals a worthwhile opportunity outside the approved scope, I bring it to you as a decision rather than treating it as permission.
A build you can inspect
MODULES
Working capability
INTERFACES
Decisions in context
CONNECTIONS
Representative data
CHECKPOINTS
Feedback while change is easy
02 · Make progress visible
Make progress visible
The checkpoints depend on the size and nature of the project. They take the form that suits the work: working modules, interface reviews, integration tests, sample outputs, or controlled demonstrations using representative data. Each checkpoint gives you a chance to confirm that the behavior matches what you approved and that the tool still feels natural in context.
Your feedback matters most while the work remains easy to change. A button in the wrong place can expose a misunderstanding about who makes a decision. An output that needs constant interpretation reveals that the logic is incomplete. These are useful findings. I would rather resolve them during construction than preserve them for launch.
A long silence followed by a finished product asks you to trust too much.
03 · Test the promises
Test what the tool will be asked to do
Testing should reflect the promises of the design. I check the ordinary path, the known exceptions, the integrity of information moving between systems, access controls, failure behavior, and the conditions the tool is expected to handle. An AI-assisted capability also needs evaluation for the quality and consistency of its outputs, along with clear limits on where human review remains necessary.
No test can prove that software will encounter every future condition. It can establish that the agreed behavior works, foreseeable failures are handled responsibly, and known risks have been made visible. I document what has been tested and what still depends on the live environment.
Build ends with working capability prepared for a controlled rollout. Its final form ranges from a focused automation or internal application to a private AI system or a connection between tools already in use. Its value comes from the same place in every case: it solves the diagnosed problem in the shape you approved, without asking the business to become something else first.
Image placeholder · 02
Working capability ready for rollout
Replace with Garrett’s supplied component-testing image.
