The 60-Day Growth OS Buildout: What Each Phase Actually Looks Like

Day 61 is the test. Not whether the system works, but whether the client team can change a scoring rule without calling anyone. Infrastructure projects are usually measured on what shipped. A Growth OS is measured on whether the organisation is still operating it in March.

Sixty days is enough, given the right sequence and honesty about what the client supplies. Here is the calendar.

Days 1 to 8: definition, which is the expensive part

Nothing gets built for the first week and a half. What happens instead is an event plan and a data dictionary. The event plan lists roughly twenty events describing how a buyer moves through your world, what each answers, and who owns the definition. The data dictionary states one written meaning per metric, agreed across marketing, sales and finance. The agreement is the deliverable; the document is only the artefact.

Precondition: a named decision-maker who can settle a disagreement between sales and marketing without escalating. If that person does not exist the project stalls here, and better to know in week one.

Client hours: twelve to sixteen, in two working sessions plus review. Both heads must be in the room: delegated definitions bind nobody.

Days 9 to 22: the signal ledger, because everything reads from it

Server-side event capture on your own domain, events resolved to accounts where legitimately possible, consent recorded on the event itself, one schema every downstream system reads. The signal ledger is first because a dashboard without it is a set of tool exports that disagree, and an agent without it acts on inconsistent data.

The work is a capture endpoint, a warehouse schema, a transformation layer, backfill where history exists, and reconciliation against whatever you used before. Reconciliation always finds something: expect a week where the ledger and the ad platform disagree by eight per cent.

Preconditions: event plan signed off, technical access to the site and tag manager, and the data protection review complete or running.

Client hours: eight to twelve, mostly a developer plus whoever knows why that strange redirect exists.

Days 20 to 32: the command centre, so you can see the machine

Once the ledger exists, numbers can be shown honestly, because they come from one place with one definition. The command centre is one screen per role: cost per customer and payback for the CEO, stage conversion and channel efficiency for marketing, a live queue of accounts showing intent for sales.

This comes before the agents deliberately: you have to see the machine before anything acts on it, and the views are how you find the leak, which decides which agent to build first.

Preconditions: the ledger producing data for a week, and a decision inventory: who decides what, how often, from which number. Without it you get forty tiles nobody opens.

Client hours: six to eight, mostly reviews where someone says "that number is wrong" and is right about the definition rather than the data.

Days 30 to 42: the repository and the review process

Copy, sequences, audience rules, scoring rules and the four context files (company, ICP, product, proof) move into Git with review gates and automated checks. Merges deploy to the site, the ad platforms and the CRM.

The context files are the most underestimated item and the reason this phase slips. Writing down what the company does, who it serves, what the product does not do and which claims are provable forces decisions the company has avoided. They become the guardrail the agents check themselves against.

Preconditions: someone senior enough to approve the proof file, meaning what you may and may not claim. Legal is often involved, the second most common source of delay.

Client hours: fifteen to twenty, the heaviest phase.

Days 40 to 52: the agent loop, under approval

Now the recurring work can be handed over: enrichment into the ledger, outbound drafting into a review queue, audience sync, creative fatigue detection, budget shifts inside guardrails, reconciliation. Each agent reads the ledger, checks the context files, drafts into the repository, and a human approves anything that leaves the building.

Two or three agents in sixty days, not ten. Each needs a permission model stating what may run alone, what needs approval, what is never allowed, plus a named owner and a weekly sample review.

Preconditions: the repository populated and the permission decisions made. Those are business decisions, not technical ones.

Client hours: six to ten, mostly permissions and the first sample reviews.

Days 50 to 60: enablement and a dated handover

Documentation shipped as part of the build, not afterwards. The weekly rhythm defined: what gets checked Monday, what gets reviewed Friday. Every component assigned to a named role. And a handover date, with the access transfer done on it.

Precondition: a role identified to own the system afterwards. If the answer is "we will figure that out", the system degrades within two quarters.

Client hours: eight to twelve for training and shadowing. Across the engagement that is roughly fifty-five to seventy-five client hours over nine weeks. Anyone quoting a buildout that costs the client nothing is describing a system the client will not own.

The three things that actually slip the timeline

CRM access. Not the decision to grant it, the mechanics: an administrator on holiday, a sandbox that does not mirror production, a three-week security review for a connected app. Ask in week one even though it is not needed until week three. It is the most common slipped milestone and entirely avoidable.

Legal and data protection review. Server-side capture, consent handling and processor agreements need review, and in Germany that is not optional. The mistake is starting when the ledger is ready. Run it in parallel from day one.

A definition nobody will own. Marketing wants a qualified lead defined one way, sales another, and neither concedes because compensation depends on it. The project cannot move past the data dictionary. The only fix is a decision-maker who imposes an answer, which is why that is the first precondition listed. A provider who ships two definitions instead is taking your money to encode a dysfunction.

What is deliberately not in scope in sixty days

A full CRM migration, which is its own project. Every integration you own, rather than the four to six that matter. A full attribution rebuild across historical data. Ten agents. A new website. Content at volume. Also out of scope: the second-order work that only becomes visible once the ledger is live, because you cannot scope what you have not seen.

The honest framing: sixty days buys the foundation, two or three working loops on top of it, and the ability to build the rest yourself. It does not buy a finished marketing organisation. Teams expecting that call the project a disappointment even when everything shipped, a scoping failure rather than a delivery one.

One further limit. The timeline assumes a company with a repeatable motion. Below roughly twenty people, before product-market fit, sixty days of infrastructure encodes an offer that will change. The five-component sequence still applies, but the calendar should be longer and the first phase a manual pilot.

Frequently asked questions

How long does it take to implement a Growth OS?

Sixty days is realistic for the foundation: a first-party signal ledger, role-specific command centre views, a repository holding copy, rules and context files under review, two or three agents under human approval, and a dated handover with documentation. It is not enough for a CRM migration, every integration you own, or a full historical attribution rebuild. A company without a repeatable motion should expect longer.

What does the client team have to do during a Growth OS buildout?

Roughly fifty-five to seventy-five hours across nine weeks: definition sessions where marketing and sales agree metric meanings, technical access and deployment support from a developer, reviews of the command centre views, writing the four context files (the heaviest item at fifteen to twenty hours), permission decisions per agent, and training at handover. Neither the context files nor the definitions can be outsourced.

What usually delays a Growth OS implementation?

Three things. CRM access, where the delay is mechanical rather than political: administrators on holiday, sandboxes that do not mirror production, security reviews for connected apps. Legal and data protection review, which should run in parallel from day one rather than starting when the ledger is ready. And a definition nobody will own, usually of a qualified lead, where compensation depends on the answer.

What should be built first in a Growth OS?

The signal ledger, once the event plan and data dictionary are agreed. Everything downstream reads from it: dashboards without it are tool exports that disagree, and agents without it act on inconsistent data. The command centre comes second so the team can see the machine before anything acts on it, then the repository so agents have context to check claims against, then the agents, then enablement.