What "build" actually means in a connected-systems project

In any project with distinct research, design and build phases, "build" is the stage that gets the most attention and the least understanding — clients often assume it's simply where the agreed design gets typed into code, when in practice it's where a large share of the real decisions actually get made.

What actually happens during build

Translating an agreed design into a working system means resolving dozens of small decisions the design phase couldn't fully specify: how exactly an edge case should behave, what happens when two pieces of data genuinely conflict, how a system should respond when something expected is missing. These aren't failures of planning — they're the normal, inevitable detail that only becomes visible once something is actually being built rather than described.

Why this stage benefits from staying connected to the client

A build phase that runs in isolation, with no check-ins until a "finished" version is presented, risks drifting from what was actually needed — not because anyone made a mistake, but because real use surfaces questions the original brief didn't anticipate. Regular, lightweight check-ins during build catch this early, when a course correction is cheap, rather than at the end, when it's expensive.

What to expect as a client during this stage

Not silence until delivery — a reasonable amount of two-way clarification as genuine edge cases and decisions surface. A build phase with zero questions back to the client is more often a sign that assumptions are quietly being made than a sign that everything was perfectly specified upfront.