HubSpot Implementation: Build Order

Why rollouts drag, and what it almost never is

Most rollouts do not run long because too much gets built. They run long because things get built out of order. Every step that arrives before the decision it depends on gets touched a second time later. That second pass appears in no project plan.

For the business this costs more than it looks. While the rework happens, the sales team keeps working the old way, in spreadsheets and in the inbox. A migration that stretches over months loses exactly the goodwill it had in month one. What fails in the end is rarely the software. It is the patience of the people meant to use it.

Our position: Delay is seldom a capacity problem. It is almost always a sequencing problem, which means it can be solved before anyone touches the system.

A HubSpot rollout has four build stages, and they depend on one another. Each one produces the precondition for the next. What breaks when you move one is in the right-hand column.

Start with the data model and the deal pipeline

Before anyone creates a single field, you need to know which things your business actually recognises and how they connect. Do you sell to companies or to sites? Does a contract belong to the customer or to the sale? These questions sound academic. They are the only ones you cannot answer later without taking apart what has been built.

Skip them and you find out after go-live. Someone asks for revenue by site, the structure does not support it, and the fix does not touch one field. It touches every report and every automation standing on top of it.

Our position: We build the data model first because it is the one decision that cannot be added to later. Everything else can be extended. This one has to be replaced.

Three things get settled in this stage. How companies, contacts and deals relate to each other. The stages your deals genuinely move through, rather than the ones that ship by default. And which fields a deal may leave a stage without.

The deal pipeline is not a by-product here, it is the core. It is the one place where your sales process becomes machine-readable, and every report you build later reads it.

Then the sales process, before the first workflow

An automation is a decision in executable form. Build it before the process is settled and you have made that decision silently, usually in whichever way was easiest to build. It comes back the moment someone asks why things work that way.

The business cost is an argument about the wrong object. The team debates workflows instead of the sales process, then changes both. Each of those rounds costs a week and a little more trust.

Our position: The process belongs on paper before it costs money. An hour of clarity in a workshop replaces three days of rework in the system.

What gets decided here is unglamorous and gets skipped most often. Who owns a lead the moment marketing hands it over? What does a stage change trigger, and what should it explicitly not trigger? When is a deal lost, and who is allowed to record that?

The data import belongs late, not early

Bringing the old records across is the most visible part of the project. You can count it, you can show it, and it therefore feels like the right place to begin. That is exactly why it gets pulled forward, and exactly why it is the most expensive step in the wrong position.

The reason is simple. An import fixes where each value lives. If the structure changes afterwards, correcting the model is not enough. You import a second time, you check a second time, and you explain to the team a second time why the numbers moved overnight.

Our position: Two weeks on a nearly empty instance beats importing twice. An empty instance is uncomfortable. A second import is expensive.

Once the model stands, the import itself is almost dull. Companies first, then contacts, then open deals, in that order, because each level needs the one before it. The duplicate rule gets decided before the import, not after. And the honest question in this stage is not what comes across. It is what deliberately stays behind.

Automation and reporting come last

Reports built on a structure that is still moving are wrong the day after go-live. That is not a technical problem but a trust problem. If the first numbers shown to the leadership team are wrong, that trust does not come back with the second set.

So this stage sits at the end, not because it matters least, but because it tests everything before it. A report you cannot build is proof that something is missing in the data model.

Our position: Reporting is not a layer on top of a finished system. It is the acceptance test for the data model, and we treat it that way.

Very little is needed for day one. Three reports have to stand: open deals by stage, closed business this quarter, and where new leads came from. Alongside them, the handful of automations without which nobody can work, usually one assignment rule and one reminder. Everything else waits for week four, when the team is using the system and can tell you what is actually missing.

The measure no proposal mentions: your own time

Proposals quote a timeline and a price. What they leave out is how many working sessions your own team has to supply, and when. That is the variable projects actually hang on. Not the vendor, but calendars.

You can recognise a good sequence by how it concentrates the decisions. It asks a lot of you, but early and in one block, rather than a little at a time across months. That is the difference between a project that runs alongside the day job and one that never finishes.

Our position: Do not ask how long it takes. Ask when you have to decide what, and how many hours that costs. A vendor without an answer has not thought the order through.

That this order of magnitude is real is on the record in our own published client work, including the client's own time investment rather than just the project duration.

The third row is the interesting one. It names not only the outcome but what it cost the client in their own time. That is the number to ask for in every proposal.

Three starting points, three answers

The sequence stays the same and its centre of gravity moves. Depending on where you start, one stage grows and the others shrink. What never changes is the order itself.

What this means for comparing proposals

Two proposals with the same timeline and the same price can describe very different projects. The difference is not in the list of deliverables. It is in what happens in week one.

Put them side by side and look for three things. Does the data import come before or after the modelling decision? Is there a named session at which your sales process gets settled? And does anyone quantify the hours your team has to contribute?

Our position: A proposal with no answer to those three is not faster than the other one. It has simply not asked the questions yet, and you will answer them during the project, under time pressure.

Deep Dive Guide · 14 pages · free

Briefing a HubSpot partner: the questions before you sign

Twelve questions, three clauses and the warning signs in the answers. For the stage between two and five provider conversations, before price decides.

Explore guide →

SalesPlaybook is a HubSpot Diamond Solutions Partner with 39+ five-star reviews in the HubSpot Solutions Directory, and builds in exactly this order. For aumico the CRM was live in under 2 weeks and cut the time for sending quotes by 80%.