When to Stop Configuring HubSpot and Start Writing Code
Six signs you have reached the end of what configuration can do, and what the custom layer costs to own. Including the copyright clause most businesses meet for the first time here.
When to stay in the platform
Four cases, and they cover more ground than most people expect.
The process is still changing. Do not encode something in code that will be different in six weeks. Configure it, let it settle, build it when it stops moving.
It runs occasionally. A monthly manual step that takes ten minutes does not need a build. Ten minutes a month is two hours a year. Weigh that honestly against a system to maintain.
The native feature is coming. HubSpot ships constantly. Building something they will release natively next quarter is the most expensive kind of correct decision.
Nobody would own it. If there is no plausible owner in twelve months, the honest answer is not to build it. An unowned system is a liability with a nice interface.
Two calls, worked through
The one that stays in the platform. A services business wants a deal to advance automatically when a contract is signed, and has been told it needs a custom integration. It does not. The signature tool already writes back to the CRM. The actual problem is that three people each built a pipeline and nobody agreed which stage means signed. That is a design problem wearing a limitation costume, and the fix is a morning of deciding, not a build. Rule out your own setup before you rule out the platform, because most of the time it is your setup.
The one that does not. A business bills on recurring contracts with mid-term variations, and needs to report contract value as at any date in the past. A custom object holds the contract fine, and what a custom code block can actually do covers most of the arithmetic around it. The wall is when the report builder itself hits its limit: reporting what a value was three months ago needs history nothing is storing, and no amount of configuration produces a number that was never recorded. That is genuinely the end of the road, and the honest version of that conversation includes the part where somebody owns that code next year.
Same pattern both times. The question is never whether the platform can do it. It is whether the thing you are missing is a decision, a field, or a system, and those have very different price tags.
How to make the call
Three questions, in order.
Recognise more than two of those six?
The workaround usually became the process without a decision.
Is this a limitation or a design problem? Most "HubSpot cannot do this" is actually "our setup cannot do this". Rule the second one out first, because it is cheaper and it is usually the answer.
How often does it run and what does it cost when it fails? High frequency and high consequence justifies a build. Low and low does not, no matter how annoying it is.
Who owns it in a year? If you cannot name them, do not build it yet.
Answer all three and the decision is usually obvious. The businesses that get this wrong are almost never the ones who asked the questions and got them wrong. They are the ones who never asked, and drifted into a custom layer one workaround at a time.
The clause to sort out before anyone writes a line
Configuration never raises the question of who owns the work, which is why most businesses meet it for the first time at exactly this decision. Under IP Australia's default rule, a contractor owns the copyright in code they were commissioned to write unless the contract assigns it to you. So the build you paid for is not automatically yours, and neither is the right to have someone else maintain it.
Get the assignment written into the agreement before the work starts, and be specific about what it covers: the code, the prompts, the documentation, and any custom objects and schema that come with it. We set out who owns the system once we hand it over in full.
Not sure whether your portal is misconfigured or genuinely out of road?
That is the question we answer most often, and the answer is configuration more often than a dev shop would tell you. When it genuinely is code, building it and handing it over properly is our AI engineering work.
We are Neighbourhood. We build the AI and the revenue system it runs on. AI and RevOps engineering for Australian teams. Diamond HubSpot Partner, 17 HubSpot Impact Awards.
Torn between another workflow and a custom layer?
Whoever owns the code in two years is the real question.
Give us a shout and tell us what's broken.