Most HubSpot implementations that go badly do not go badly because the team picked the wrong tool or the wrong consultant. They go badly because someone compressed a phase. The implementation arc has five, Discovery, Design, Build, Launch, Optimize, and each ends with an artifact the team will defend. Skip the artifact and the next phase rests on conversation rather than commitment. The cost shows up two months later, when Build re-opens decisions that should have closed in week two.
Why this matters now
The HBR brief on why digital investments fail to create value made the point plainly: the failure mode is not the tooling, it is the failure to redesign how the commercial organization generates insight, makes decisions, and coordinates action. A HubSpot implementation is one of the few moments inside a B2B SaaS company where that redesign is forced into the open, schema, pipelines, ownership, reporting, all on the table at once. The five-phase methodology exists because the redesign is the work. The platform configuration is the artifact at the end.
Discovery
Discovery is the phase teams compress most often, and where compression is most expensive. The job is not to talk to people. The job is to leave with a written artifact the entire team has signed off on, pipeline definitions, named owners for every object, an integration map, in-scope and out-of-scope use cases, and the success criteria the implementation will be measured against. Two weeks is a fair budget. One week produces a Design phase you have to redo.
What bad looks like, a Discovery deck that lists the tools in use, a few interview quotes, and a vague set of goals. Nobody disagrees because nothing is specific enough to disagree with. Design then discovers the disagreements one decision at a time, in front of a developer waiting on direction.
Design
Design is where the schema decisions live. Every object that will exist in the production portal: Contact, Company, Deal, the custom subscription object, the portfolio object if there is one, gets defined here, in writing, before anything is built. Properties get a data type, a picklist if relevant, an owner, and a one-sentence definition. Pipeline stages get entry criteria, exit criteria, and a definition of what the stage actually means. Association labels get spelled out. The deliverable at the end of Design is a schema document plus a workflow inventory the team can read end-to-end without asking questions.
What bad looks like, Design that happens inside the HubSpot UI by clicking. Properties get added live. Pipeline stages get renamed three times. The schema document, if it exists, lags the build by a week. Three months later, nobody remembers why the deal stage "Verbal" exists, and the only person who could answer has left.
Build
Build is the sprint phase. Done well, it is a two-to-six-week sequence of small, scoped, reviewable deliverables: schema deployed to a sandbox, workflows wired, integrations connected, reports stood up, permission sets configured. The cadence that holds is weekly, a working session to confirm the next slice, a build sprint mid-week, a demo at the end. The cadence that does not hold is the every-other-week check-in where the build team disappears and reappears with a finished portal nobody has seen.
Build only works if Discovery and Design held. If they did, Build is execution against a list. If they did not, Build is arguments dressed up as standups. The diagnostic test, in any given Build week, how many decisions are getting re-opened? If the answer is more than one or two, the work upstream was not finished.
Launch
Launch is cutover, training, and the first ten days. Cutover is a Friday, preferably one before a quiet week, and it is rehearsed in a sandbox before it happens in production. Training is delivered against the post-build system, not the legacy one, and it is delivered to the people who will actually use the system, not just the leaders who scoped it. The first ten days are a hypercare window, the build team is on call, the user-facing issues get triaged in hours rather than days, and the small fixes that show up in real usage land before the team forms muscle memory around workarounds.
What bad looks like, a Launch that happens on a Wednesday because the calendar said it had to, a training deck recorded once and circulated as a video, and a build team that demobilized the day after cutover. By week three the workarounds are habits, the workarounds are now the system, and the Optimize phase will be unwinding them rather than improving on them.
Optimize
Optimize is the phase nobody plans a budget for. The implementation gets scoped through Launch; Optimize is treated as someone's part-time admin work. That is the mistake. Every HubSpot instance accumulates, new properties get requested, workflows get edge cases, reporting needs evolve, the team learns what they actually want to see versus what they thought they would. Optimize is the phase where those signals get triaged on a cadence, monthly is right for most companies, rather than absorbed into the daily noise.
What bad looks like, Optimize is whatever the senior ops person can get to between fires. Six months in, the system has drifted from the documented schema, nobody has audited the workflows since launch, and the next person to join the team inherits an instance that is two-thirds original design and one-third improvisation. The optimization budget that nobody planned is now the migration project nobody wanted.
Pattern from the field
A B2B SaaS team at the back end of Series A came in for a HubSpot implementation on a six-week timeline. Discovery was scoped to four days. We pushed back and ran it for two weeks. The artifact was a document covering pipeline definitions, ownership, integration scope, success criteria, and a list of use cases the team agreed were out of scope for v1. Design took three weeks and produced a schema document plus a workflow inventory. Build was a clean four-week sprint: weekly demos, no decisions re-opened. Launch was a Friday cutover with a one-week hypercare window staffed by the build team. Optimize started thirty days after launch on a monthly cadence and is still running. The piece worth naming, the team's first quarterly business review on the new system did not require a manual data cleanup. That is what a Discovery that did not get compressed buys you, ten months later.
Resolution, picking the engagement model that maps to each phase
The five phases do not have to live inside one engagement type. Different phases reward different shapes of support. The mapping that holds up across most B2B SaaS engagements:
- Discovery is a workshop or a tightly scoped project. It needs senior attention, an outside perspective, and a deliverable the internal team will sign off on. It does not need a long-running retainer.
- Design is a project. The deliverable is a schema and workflow document, the budget is fixed, the timeline is two to four weeks. Treat it as one.
- Build is a project or an embedded engagement, depending on how much of the configuration work the internal team can absorb. If you have a HubSpot admin in seat, project shape works. If you do not, embed someone for the duration.
- Launch is a project with a hypercare tail. Scope the cutover, the training, and the first ten days as one block. Do not rely on the build team's goodwill to staff the tail.
- Optimize is where retainer or fractional support earns its keep. Monthly cadence, scoped hours, a defined backlog. The mistake is buying a retainer before Discovery is done; the other mistake is letting it lapse the day after Launch.
- Cross-phase: if the internal team does not yet have a senior RevOps function, a fractional embedded role across Discovery, Design, and Optimize is often the right shape. Build stays a project.
- Stage check: at seed and pre-Series A, project shape is almost always right, the internal team is not yet ready to absorb a retainer. From Series B onward, the retainer or fractional model usually pays back inside two quarters, because Optimize stops being someone's side gig.
Where Checkpoint comes in
The five-phase methodology is the spine of every HubSpot and CRM engagement we run at Checkpoint. Greenfield implementations run the phases in order. Brownfield migrations start Discovery with the audit. Redesigns lengthen Design and shorten Build. The phases stay; the proportions change. If you are scoping an implementation now and the timeline does not name all five, talk to us before the kickoff. We do this work as HubSpot implementation, as part of GTM strategy, and as embedded RevOps support across the stack.
Sources
- Sinha, Shastri, Lorimer. "Why Your Digital Investments Aren't Creating Value." Harvard Business Review, February 16, 2026. hbr.org
- Lemkin, Jason. "Which CRM Should You Use in 2026/2027? Follow the Agents." SaaStr, April 6, 2026. saastr.com