Your HubSpot isn’t broken. 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, quietly convinced the software is the problem, asking whether they should rip it out and start again. Almost every time, the software is fine. What broke was a decision made before anyone logged in, and it broke in one of two predictable ways.

There are only two ways a portal goes wrong

We get called into a lot of HubSpot portals that someone describes as broken. Almost none of them are broken in the way people think. The objects are fine. The features work. HubSpot did what HubSpot does. The break happened earlier, before anyone logged in, in a decision nobody wrote down.

In practice it is one of two failures, and they rhyme. Either the portal was built without anyone mapping the real customer journey or asking the people who would live in it every day. Or it was built after consulting exactly one person, who designed a system that fit the inside of their own head and disregarded everyone else who would have to navigate it. The first is an absence of listening. The second is listening to the wrong single voice. Both produce the same thing: a portal that technically works and functionally does not.

The tell is always the same. Ask five people in the business what a given stage, property or lifecycle status means, and you get five answers. That is not a training problem you can fix with a lunch-and-learn. It is a design problem baked in on day one, and no amount of clean-up survives it, which is why the duplicates keep coming back after every tidy-up.

Built for one person, in one person’s head

The second failure 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. The pipeline makes perfect sense, because it is a diagram of how they personally think about deals. The automations fire beautifully, 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 quietly builds a workaround, and the workarounds become the real system, and the CRM becomes the tidy fiction sitting on top. A CRM built for everyone is a CRM built for no one, and this is the same failure wearing a more flattering suit: 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, custom, clearly the work of someone who knew the tool. Underneath, it was so complex and so tangled that it had become hard for even him to remember what half of it meant, or which parts were still in use and which were archaeological. When the person who built a system cannot read it, no one can.

When even the author cannot read it

A portal only one person understands is a liability the day that person is busy, and a disaster the day they leave. But the damage does not wait for them to leave. It shows up as friction, and the friction spreads outward.

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, the ones running ads, the ones syncing data, the ones 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 is not a neutral omission. It is a tax every future collaborator pays, forever, and it turns routine integrations into forensic investigations.

This is the part that makes these builds so costly in hindsight. The original setup can look like a bargain. It is the second, third and fourth interactions with it, by people who were not in the room when it was designed, that quietly burn the hours. A property audit usually makes the scale visible for the first time: we have walked into a portal with hundreds of custom properties, a fifth of them never filled in once, and no living person who could say what they were for.

The bill nobody itemised

People ask what a HubSpot setup costs as if there is one number. There are really 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. The problem is what you are paying those hours to produce.

The second bill is the invisible one: the ongoing cost of a portal that fights the people using it. Every workaround, every report that takes three tabs and a judgement call, every new hire who takes months instead of days to trust the data, every vendor who has to reverse-engineer an undocumented field. It never appears on an invoice, which is exactly why it is 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 to fix what the first payment was supposed to buy. The honest news is that a rebuild is usually cheaper in hours than the original looked, because you are not inventing anything. The expensive part is not configuration. It is figuring out what the business actually needs, which the first build skipped.

A rebuild is mostly listening

Here is the thing nobody selling a HubSpot rebuild wants to say: the build itself is the fast part. Configuring HubSpot to a clear specification is days of work. Arriving at a specification the whole business agrees with is where the time goes, and it is not optional, because skipping it is precisely how the portal got broken the first time.

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. Not because anyone was wrong, but because each of them saw a true slice of a journey no one had ever drawn end to end. The job was to sit with all ten, reconcile the contradictions, and produce the single map the original build never had. Only then does touching HubSpot make sense.

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 is 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. Sequence matters as much as speed, which is the whole argument for doing it in phases rather than all at once.

The fallout nobody logged

The organisational cost of a bad build is easy to underestimate, because most of it never gets attributed to the build. It shows up months or years later, wearing other names.

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 it was executed poorly when the cracks reach them, usually as a number that will not reconcile or a forecast nobody trusts. By then the original decision is old news and the blame lands on whoever is holding the system now, which is rarely the person who broke it.

And there is a specific, brutal 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 a wound. People who had made an uneasy peace with the broken portal now have to relearn something adjacent to it, and in doing so they uncover the next layer down: the inefficiency and the gaps in competence that the first build had quietly buried. Change is hard enough when it is obviously an improvement. It is harder when it looks like the thing that already failed them, 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 corrosive: every reasonable local decision compounds into a mess no single person is accountable for.

How not to pay for this twice

The prevention is unglamorous and almost free, which is why it gets skipped.

Map the journey before you touch the tool, and map it with the people who live in it, not with the one 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 are not doing archaeology. Design for the whole company, not for the mental model of whoever holds the keys, which means someone has to represent the users who are not in the room. And insist on a build that is handed over, documented and legible, rather than one that quietly makes you dependent on its author.

If your portal already has the symptoms, five people with five definitions, reports nobody trusts, a build only one person can explain, the fix is not another clean-up. It is the map that was never drawn. That is unglamorous, mostly listening, and the only thing that actually holds. We do this as a build-to-hand-over engagement for exactly that reason: the goal is a system you own, not a consultant you cannot leave.

Common questions