What Happens During the Build Phase of a GTM Infrastructure Engagement?
By Mathew Joseph
Most engagement descriptions go quiet exactly where a buyer most wants detail. The proposal explains the diagnosis. It explains the architecture. Then it says the system gets built and skips to the results slide. The part where the system actually becomes real, the part the client is paying for, gets one sentence.
Build is the four weeks where the architecture stops being a document and starts moving revenue data. Weeks three through six. By the end, a working system runs on infrastructure the client owns.
This post walks those four weeks. What gets wired in, in what order, what the client sees on Friday of each week, and how the phase hands off without dropping context. If you read the five-phase overview and wanted the inside of one phase, this is Build.
What is the Build phase of a GTM infrastructure engagement?
Build is the construction phase. It is weeks three through six of a typical engagement, after Diagnose has mapped the failure points and Architect has produced an approved blueprint. Build is where signal detection gets wired in, the enrichment layer starts running, qualification logic is deployed, the CRM schema is rebuilt where it needs rebuilding, outreach automation is connected, and dashboards go live.
The output is not a recommendation or a slide deck. It is a working revenue system running on foundations the client owns. Every credential, every database, every workflow lives in the client’s accounts. I build it there from day one. There is no migration step later because nothing was ever hosted somewhere it would have to move from.
The phase has a fixed shape: four build weeks, each with a defined surface, daily notes to a shared document, and a working demo every Friday. Nothing about Build is open-ended. The architecture decided what gets built. Build decides only how fast and in what sequence.
Why does Build come after Architect and not before?
Because building before the architecture is set is how you get a fast pipeline that compounds bad data. This is the failure mode I see most often in companies that hired a contractor to “automate the outbound.” The automation works. It just automates a broken model, and now the breakage runs at machine speed.
Architect produces the data model, the signal definitions, the qualification rules, and the routing logic on paper, and the client approves it before anything is built. That sequencing is not bureaucratic caution. It is the single decision that determines whether the system that ships is an asset or a liability.
Build is deliberately the phase with the least judgment in it. The hard calls were made in Architect. Build executes them. When a question comes up mid-build that the architecture did not answer, that is a signal the architecture had a gap, and I treat it as one (more on that below). The order is the protection.
What gets wired in during week three?
Week three is the foundation week. Three things get stood up, in this order: the data layer, signal detection, and the enrichment pipeline.
The data layer goes first because everything else writes to it. That means provisioning the storage the architecture specified, applying the schema, and setting up the access controls in the client’s own environment. Signal detection comes second: the triggers that tell the system a company or person is worth acting on, defined in Architect, now connected to their sources and emitting events. The enrichment pipeline comes third, because enrichment only matters once there are signals worth enriching.
By Friday of week three nothing is doing outreach yet. That is intentional. What exists is a system that detects the right moments and attaches the right context to them. The demo that week is a live trigger firing and a fully enriched record landing in the data layer. Unglamorous, and the most important hour of the engagement, because every later week builds on it.
How does the CRM schema get rebuilt without breaking what is live?
Carefully, and never in place. The CRM is the one system in Build that already has live data, active users, and a sales team depending on it every hour. You do not rebuild a schema by editing the running one.
The rebuild runs in three moves. First, the new schema is built alongside the existing one, not on top of it, using the model approved in Architect. Second, data is migrated into the new structure in a staging context and validated against record counts and field-level integrity before anything user-facing changes. Third, the cutover happens in a single deliberate window, with the old structure preserved and reversible until the new one is confirmed stable under real use.
The sales team’s day does not stop for this. The rule I hold is that no one logs into a half-migrated CRM on a Tuesday morning. If a rebuild cannot be made reversible, it is not ready to run, and that gets resolved before the window, not during it.
What does the client see during each Build week?
A shared document that updates daily, and a working demo every Friday.
The daily notes are not status theater. They are short: what was built, what was decided, what is blocked, what is next. A technical stakeholder can read them in two minutes and know exactly where the system stands. The point is that the client is never surprised on Friday, because they watched it happen all week.
The weekly demo is the forcing function. A system that cannot be demoed at the end of the week was not actually built that week, it was described. The demo is how “in progress” stays honest.
Each Friday demo shows one working surface end to end. Week three: a signal fires, a record enriches. Week four: a qualified record routes and an outreach sequence triggers. Week five: the rebuilt CRM under live conditions. Week six: the full system running, dashboards populated with real movement. The client sees the system get more real every week, on their own screens, in their own accounts.
How are decisions made when the architecture meets reality?
Architecture is a model of reality, and reality always has a detail the model did not. A data source rate-limits harder than its docs claimed. A field the model assumed was clean is forty percent null. A routing rule that read clean on paper is ambiguous against three live edge cases.
When that happens, the decision is not made silently inside the build. It surfaces in the daily notes the same day, with the options and a recommendation. Small calls (a field default, a retry interval) I make and log. Calls that change behavior the client can see (a qualification threshold, a routing exception) get a decision from the client, fast, usually inside the day, because the build does not wait well.
What does not happen is scope drift dressed as a discovery. A genuine architecture gap is rare if Diagnose and Architect were done properly. When one appears, it is named as a gap, not absorbed as extra work, and the fix is scoped explicitly. The discipline is that the architecture stays the source of truth, and deviations from it are visible decisions, never quiet ones.
What does “done” look like at the end of Build?
Done is a specific, demonstrable state, not a feeling. At the end of week six, the system detects signals from their defined sources, enriches records against the approved model, qualifies them by the approved logic, routes them by the approved rules, triggers outreach, and reports the whole flow on live dashboards. Every component runs in the client’s environment on credentials the client holds.
Done also means the things that are deliberately not in Build are explicitly named, not vaguely deferred. Build ships a working pipeline. It does not ship lifecycle automation, deal-progression logic, retention monitoring, or expansion triggers. That work is real, and it has its own phase. Pretending Build covers it is how engagements quietly underdeliver while looking complete.
The end-of-Build demo is the full path running once, start to finish, with the client watching. If any segment cannot run live, Build is not done, and the gap is closed before the phase is called closed.
How does Build hand off to Activate without dropping context?
By treating the handoff as a built artifact, not a meeting. The risk at every phase boundary is that the context lives in one person’s head and evaporates when the phase ends. Build closes that gap on purpose.
The handoff is not “here is the system, good luck.” It is the working pipeline plus the decision record that explains why every part of it is the way it is. Activate inherits both, or it inherits half a system.
Concretely, Build hands forward three things: the running pipeline, the daily-notes log with every mid-build decision and its reasoning, and a short map of where the seams are for the next phase to extend (where lifecycle logic will attach, where attribution will read from, where expansion triggers will hook in). Activate is the phase that turns this pipeline into a full revenue system, and it can only do that cleanly if Build handed it the reasoning, not just the result. A pipeline without its decision record is a system nobody can safely change.
Build delivers a working pipeline. Architect decided what it should be. Activate makes it a revenue system, and Transfer hands you the keys. If your outbound runs but nobody can explain why it routes the way it does, the problem is not the automation. It is that the build never produced its own reasoning.