Your HubSpot works. It was built for one person, and it wasn’t you.

There is a particular kind of call we get a lot. A revenue leader, a few years into a HubSpot portal, half-convinced the software is the problem, asking whether they should rip it out and start again. Almost every time, the software is fine. What is costing them was decided before anyone logged in, and it tends to come from one of two early decisions.

Two decisions that set the cost

We get called into a lot of HubSpot portals that someone describes as beyond saving. Almost none of them are. The objects are fine and the features work as designed. The cost was set earlier, before anyone logged in, in a decision that never got written down.

Usually one of two things happened. In the first, the portal was built without anyone mapping the real customer journey or asking the people who would live in it every day. In the second, it was built after consulting exactly one person, who designed a system that fit the inside of their own head and left everyone else to navigate around it. One version comes from nobody listening; the other from listening to a single voice. They end up in the same place: a portal that works on paper but not in the running business, and you pay for the difference.

The symptom is easy to spot. Ask five people in the business what a given stage, property or lifecycle status means, and you get five answers. That gap was designed in on day one. Training will not close it, and neither will a clean-up, which is why the duplicates keep coming back after every tidy-up.

Built for one person, in one person’s head

The second decision is the more expensive one, because it looks like competence while it is happening. A confident consultant or an internal power user gets handed the keys, and they build fast. They know what every field is for, because they invented it, and the pipeline is a diagram of how they personally think about deals. The automations fire cleanly for the one workflow they had in mind.

Then the rest of the company arrives. Sales cannot find the property that marketing swears is essential. Two teams use the same stage to mean opposite things. The custom objects model a process only one person ever ran. Nobody wants to say it out loud, because the thing works for the person who built it, and questioning it feels like questioning their competence. So everyone builds their own workaround, and over time those workarounds become the real system while the CRM sits on top of them as a tidy fiction. This is the first problem again in a smarter-looking form: it was built for one person instead.

We saw the clean version of this at a B2B organisation in Europe. One consultant had designed the portal, and on the surface it was impressive: elaborate and custom, clearly the work of someone who knew the tool. Underneath, it had grown so complex and so tangled that even he found it hard to remember what half of it meant, or which parts were still in use and which were dead. Once the person who built it loses the thread, no one else can pick it up.

When even the author cannot read it

A portal only one person understands is already a liability while that person is still around, and a real exposure the day they leave. The cost does not wait for them to leave, though. It starts as everyday friction that spreads outward from there.

At that European organisation, nothing had been documented: not the logic behind the objects, not what the automations assumed, not which fields were load-bearing and which were abandoned. So every other vendor who touched the stack, whether they were syncing data or building reports, hit the same wall. They could not trust what any field meant, and there was no one to ask who could give a straight answer. Undocumented work becomes a tax that every future collaborator keeps paying, and it turns a routine integration into a slow, manual investigation.

This is what makes these builds so costly in hindsight. The original setup can look like a bargain, and the hours get burned later, on the second and third and fourth pass by people who were not in the room when it was designed. A property audit is usually where the scale becomes visible: we have walked into a portal with hundreds of custom properties, a fifth of them never filled in once, and nobody left who could explain them.

The bill nobody itemised

People ask what a HubSpot setup costs as if there is one number. There are three, and the first is the one everybody quotes.

The visible bill is the build. HubSpot charges a mandatory onboarding fee on its Professional and Enterprise tiers, and most companies also pay a partner or a freelancer to do the actual configuration on top of that. Partners bill this one of two ways: hourly, at agency rates, or as a fixed onboarding package. A genuinely simple portal is a handful of hours. Anything with custom objects, multiple pipelines, lifecycle automation and integrations is tens of hours quickly, and a bespoke multi-team build runs well beyond that. None of that is unreasonable on its own; what matters is what those hours actually produce.

The second bill is the invisible one: the ongoing cost of a portal that fights the people using it. It is every workaround, every report that takes three tabs and a judgement call, every new hire who needs months rather than days to trust the data. It never lands on an invoice, and that is why it usually adds up to the largest of the three.

The third bill is the rebuild, and it is the one that stings, because you are paying a second time for what the first payment was supposed to buy. The better news is that a rebuild is usually cheaper in hours than the original looked, because you are not inventing anything from scratch. Configuration was never where the money went. It goes into working out what the business actually needs, which is the step the first build skipped.

A rebuild is mostly listening

Nobody selling a HubSpot rebuild wants to admit that the build itself is the fast part. Configuring HubSpot to a clear specification takes days. Getting to a specification the whole business agrees with is what takes the time, and you cannot skip it, since skipping it is how the portal came to cost so much in the first place.

At that European organisation it took roughly three months to pin down the actual customer journey, and the reason it took three months was arithmetic. We interviewed ten people and got ten different views of how the business worked. They were not contradicting each other; each of them just saw a true slice of a journey no one had ever drawn end to end. Our job was to sit with all ten and reconcile those slices into the single map the original build never had. Touching HubSpot only makes sense after that.

As a rough shape: a small portal can be re-mapped and rebuilt in a few weeks; a complex, multi-brand or multi-team one takes a quarter, most of it discovery and change management rather than clicks. Anyone quoting you a fast rebuild without asking to talk to your people is about to build you a second portal that fits one person’s head, and you already own one of those. Getting the order right matters as much as moving fast, which is the argument for doing it in phases rather than all at once.

The cost that surfaces later

The organisational cost of a build that skipped the map is easy to underestimate, because most of it never gets attributed back to the build. It surfaces months or years later under other labels.

Senior stakeholders are often the last to know. At implementation, they were told it was done, and done well, and they had no reason to doubt it: the demo looked great and the invoice was paid. They only learn the discovery was skipped when the cost reaches them, usually as a number that will not reconcile or a forecast nobody trusts. By then the original decision is old news, and the cost lands on whoever is holding the system now instead of whoever set it up.

And there is a specific, human cost to the rebuild itself, one that has nothing to do with software. When you reintroduce a team to a new system that necessarily resembles the old one, because the business is still the business, you reopen something tender. People who had made an uneasy peace with the old portal now have to relearn something adjacent to it, and in the process they surface the next layer down: the inefficiency and the gaps the first build had papered over. Any change is hard; one that resembles the system that already let them down is harder still, and it takes real communication to keep a rebuild from being read as just another reorg. This is also why no one owning the shape of the system is so costly: every reasonable local decision compounds into a tangle no single person is accountable for.

How not to pay for this twice

The prevention is unglamorous and nearly free, and that is usually why teams skip it.

Map the journey before you touch the tool, and map it with the people who live in it, rather than only the person most comfortable in the software. Ten short conversations up front are cheaper than a three-month rebuild later. Write down what every object, stage and load-bearing field is for, so the next vendor and the next hire can read the system instead of reverse-engineering it. Design for the whole company, which means someone has to represent the users who are not in the room. And insist on a build that is documented and handed over, so you are not left dependent on its author.

If your portal already has the symptoms, five people with five definitions, or reports nobody trusts, or a build only one person can explain, another clean-up will not fix it. What it needs is the map that was never drawn, and drawing it is mostly unglamorous listening. We do this as a build-to-hand-over engagement for exactly that reason: what you should end up with is a system you own and can run without us.

Common questions