HubSpot Implementation: When to Use a Consultant vs. When to Hire In-House
Read Time 18 mins | Written by: Vinayak Bhagat
At some point in every HubSpot rollout somebody asks whether the company should hire a HubSpot person. It usually arrives as a budget question, phrased as can we afford one, and it is usually answered as a seniority question, with a debate about whether the role is an admin, a manager or a director. Both framings miss the thing that actually decides it, which is the shape of the work.
Some of the work in front of you is a project. It has a beginning, a definition of done, and a burst of demand for a wide range of specialties that you will not need again for a long time. Some of it is a job. It recurs every week, it never finishes, and it depends far more on knowing why your portal is configured the way it is than on knowing every corner of the platform. Hiring a person for the first kind leaves them underemployed and bored into leaving once the build is over. Outsourcing the second kind leaves nobody in the building who remembers why anything is the way it is.
So the useful question is not consultant or hire. It is which side of the line each piece of work sits on, and who should own each side. Build work ends. Run work does not. Hire for the side that does not end.
Should we hire a HubSpot administrator or use a consultant?
Sort the HubSpot work actually in front of you into build work, which is bursty, wide and ends (migration, architecture, integrations, the reporting model, the launch), and run work, which is continuous, narrow and never ends (data hygiene, workflow maintenance, user support, the reporting cadence, change requests). Use a consultant or partner for the build, because hiring for bursty work is how you get a bored specialist who leaves. Hire for the run, because that is where institutional memory lives. Most companies need both, in sequence, with the handover treated as a deliverable rather than an afterthought. If your run work does not yet fill a role, a fractional administrator or a retainer is the honest answer, not a full-time hire.
The Build / Run Line
Every piece of HubSpot work sits on one side of a single line. On one side is work that ends. On the other is work that recurs. Three tests place any item, and they are worth asking in this order, because the first one settles most of them.
1. Does it end? Build work has a definition of done: the data is migrated, the objects are modeled, the integration is live, the dashboards exist. Run work has a cadence instead: weekly, monthly, whenever sales changes the process. If you cannot write down what finished looks like, it is run work, however much it is currently dressed up as a project.
2. Does it need range or context? A migration needs someone who has seen a dozen migrations, knows the failure modes of your source system, and can model objects, write the integration and design the reporting layer in the same month. That is range, and you need it briefly. Keeping the portal trustworthy afterwards needs someone who knows why the lifecycle stages are defined the way they are and which team asked for the workflow that everyone now complains about. That is context, and it only accrues to someone who stays.
3. Who notices if nobody does it this month? When build work stalls, the project visibly slips and somebody escalates. When run work stalls, nothing visible happens for a quarter. Then duplicates creep in, the workflows drift away from the process, the reports stop being believed, and you are reading our guide to the signs your HubSpot instance needs a CRM audit and recognizing all five. Work that fails silently is run work, and run work needs an owner on payroll.
Build work: bursty, wide, and finished
Migrating from the old CRM, deciding how companies, contacts, deals and any custom objects relate, connecting billing or the ERP, designing the lead routing and the first layer of automation, building the reporting model and the executive dashboards, and getting through the launch itself. It demands several specialties at once for a short period, and then it is over. Our realistic implementation timeline describes what this looks like week by week; the point here is that it has a last week.
Run work: continuous, narrow, and never finished
Keeping the data clean, maintaining workflows as the sales process changes, onboarding new reps and answering the questions they ask in week two, producing the reporting on its cadence and checking it before it is circulated, triaging the change requests that arrive from marketing and sales every week, and periodically asking whether the portal still matches how the company actually sells. None of it is glamorous, all of it recurs, and the moment nobody owns it the portal starts to lie.
The one thing that is always in-house
Deciding what the CRM is for. What a qualified lead means, what the pipeline stages represent, which numbers the leadership team will run the business on. No consultant can make those decisions for you, and a partner who offers to is selling you a portal that will not be trusted. This is not a hire and it is not a project. It is a responsibility that belongs to whoever owns revenue, and if it is unassigned, neither a consultant nor a new administrator will fix what follows.
Where Common HubSpot Work Falls
Treat this as a starting position. Your own sort will differ at the edges, and the point of doing it is that each placement becomes a decision someone made rather than a default nobody chose.
| Work | Side of the line | Why it falls there |
|---|---|---|
| Migration from the previous CRM | Build | Wide range of skills for a few weeks, then never again on this system |
| Object and property architecture | Build | Decided once and expensive to change; needs someone who has seen it go wrong elsewhere |
| Billing, ERP or accounting integration | Build, with a run tail | The connection is a project; watching it every month afterwards is a job |
| Reporting model and executive dashboards | Build, then run | Designing the model ends; producing and checking the numbers on a cadence does not |
| Lead routing and first-layer automation | Build | A designed system with a definition of done, tested before launch |
| Data hygiene and duplicate management | Run | Recurs forever and fails silently; nobody escalates a duplicate |
| Workflow maintenance as the process changes | Run | Needs to know why the workflow exists, which only someone who stays will know |
| User support and rep onboarding | Run | Arrives every week and is answered best by someone inside the company's own process |
| Change requests from sales and marketing | Run | Continuous, small, and the place where portals quietly drift away from the process |
| Periodic audit and re-architecture | Build, recurring | Bursty and wide again, and the case where outside eyes are worth paying for |
When to Hire, When to Use a Consultant, and When Both
Hire when the run load is real
If you can list run work that recurs every week and nobody currently owns it, you are looking at a job description, not a project brief. The tell is not the size of the portal or the size of the company. It is that the same categories of work keep arriving, that they need someone who knows the history, and that they fail silently when they are not done. Write the role around the run work you have actually listed, not around the platform's feature list, and you will hire the right seniority almost automatically.
Use a consultant when the work is a build
A migration, an integration, a reporting model, a launch. The work needs range for a short time, and hiring for it means paying a full-time salary for a burst and then either inventing work to justify the seat or watching a capable specialist leave. Our implementation guide already lays out the difference between implementation, consulting and figuring it out yourself, so we will not repeat it here. The point on this side of the line is simpler: buy the build, and buy it with the handover written into the scope.
Both, in sequence, with the handover as a deliverable
The most common right answer for a mid-market company is both: the build outside, the run inside, and a deliberate handover between them. That handover is where most arrangements fail, because it is treated as a training session rather than a deliverable. It should produce a written record of why the portal is configured the way it is, an administrator who has made changes under supervision rather than watched them being made, and a list of what to leave switched off and why. The go-live checklist is a reasonable skeleton for that record. If the partner leaves and the institutional memory leaves with them, the build was not finished, whatever the invoice says.
When Not to Hire, and When Not to Use Us
Ontrac Solutions is a HubSpot Diamond Partner, so read this section knowing what we are. It is also why it is here: a partner that only ever recommends a partner is not giving advice.
Do not hire when the run load does not yet fill a role
If the build is done and the recurring work adds up to a part of a week rather than a week, a full-time hire is the expensive way to feel safe. A fractional administrator, a retainer with a named person, or a trained owner inside an existing team covers it. Hire when the inventory says so, not when the anxiety does.
Do not use a consultant for work that is run work forever
Paying project rates for a standing operating load is the costly way to avoid a hiring decision, and it guarantees that the person who understands your portal best is not your employee. If the same partner has been maintaining your workflows every month for a year, that is a job you have outsourced, and it is worth asking whether it should be.
Do not use a consultant, including us, until the decisions are made
If nobody has decided what a qualified lead is or which numbers the business will run on, a build partner can only implement a guess, and you will pay to change it. Settle the ownership of those decisions first. It costs nothing and it is the single biggest predictor of whether the portal is trusted a year later.
Do not confuse a build partner with a staffing arrangement
If what you actually need is a standing bench of HubSpot administrators, that is staffing, not consulting, and the two are bought differently. The same distinction applies more sharply to AI and data roles, where scarcity changes the answer; our post on staff augmentation for AI and data projects covers that sort, and we will not restate it here.
What Drives the Cost on Each Side
We are not going to quote salaries or day rates. They vary by market and by month, and any figure written here would be wrong for your city by the time you read it. What does not vary is what moves the number on each side of the line.
The in-house side is driven by the seniority the run work genuinely requires, the ramp time before the person knows your process well enough to be trusted with it, the training and certification you fund, the management attention the role consumes, and the cost of the role turning over, which is highest precisely when the person was doing bursty build work that has run out.
The consultant side is driven by the breadth of scope, the number and awkwardness of the integrations, the volume and condition of the data being migrated, the number of teams being onboarded, and whether the handover is written into the scope or left to goodwill. A quote that is cheaper because the handover is missing is not cheaper.
The cost that sits on neither side, and that both arrangements can produce, is nobody remembering why. A portal whose configuration nobody can explain gets rebuilt rather than maintained, usually within a couple of years, and that rebuild is the largest HubSpot cost most companies ever incur. It is avoidable on either side of the line, and only by deciding who holds the memory.
Where to Start
Start with an inventory, not a job description and not a request for proposals. List the HubSpot work actually on your plate this quarter, every item, however small. Mark each one build or run using the three tests. Estimate the recurring hours on the run side honestly, and read the answer off the totals rather than off a feeling.
If the run hours are real, write the role around that list and hire for it, and buy the build separately with the handover in scope. If the list is almost entirely build, scope the project and resist the hire until the run work exists to justify it. If the list is short on both sides, a fractional arrangement is the honest answer and there is no shame in it.
Whatever the totals say, name the owner of the decisions before you do anything else. That is the one line on the inventory that never moves.
The Build / Run Inventory
This article gives you the line. The inventory is where your own work gets sorted: every HubSpot item on your plate this quarter listed, each one marked build or run against the three tests, the recurring hours totaled, and a page for the question nobody asks in the sales meeting, which is who holds the institutional memory if the partner relationship ends. It is the part an article cannot do for you, and it is what turns a hiring debate into a decision with numbers attached.
We do the build, and we hand it over on purpose.
Our HubSpot practice takes the build side of the line: migration, architecture, integrations, the reporting model and the launch, with the handover written into the scope from the first conversation. We will also tell you, from the inventory, when the run side is already a job and you should be hiring rather than talking to us. That is a shorter engagement and a better outcome, and it is the one we would rather have.
Talk to us about the lineFrequently Asked Questions
Should a mid-market company hire a HubSpot administrator?
Hire when the recurring work justifies it, not when the platform arrives. If you can list run work that comes back every week, such as data hygiene, workflow maintenance, user support and the reporting cadence, and nobody owns it, that is a role. If the work in front of you is mostly a build, such as a migration or an integration, buy it as a project and revisit the hire once the run work exists.
What does a HubSpot consultant do that an in-house administrator cannot?
Range, briefly. A consultant has seen many migrations and integrations and can model objects, connect systems and design the reporting layer in the same month, then leave. An administrator who stays builds something different and equally valuable: the institutional memory of why the portal is configured the way it is. The two are not competing for the same work; they sit on different sides of the build / run line.
Can one person do both the build and the run?
Occasionally, and it is usually the wrong plan. Someone senior enough to run a migration alone is underemployed by the run work that follows and tends to leave once the interesting part is over, taking the memory with them. Someone right-sized for the run work is stretched by the build. Buying the build and hiring for the run, with a real handover between them, is the arrangement that survives contact with the second year.
When should the consultant relationship end?
When the build is finished and the handover is complete: the configuration is documented, your own administrator has made changes under supervision, and the reporting is produced and trusted without the partner in the room. Keeping a partner on for periodic audits or the next build is sensible. Keeping one on because nobody inside can explain the portal means the handover did not happen, and that is the thing to fix.
Keep Reading
→ HubSpot Implementation Consulting for Mid-Market — which kind of outside engagement you actually need, and the method we run.
→ The Realistic HubSpot Implementation Timeline — what the build side of the line looks like week by week.
→ Signs Your HubSpot Instance Needs a CRM Audit — what happens when the run side has no owner.
This article is general guidance on team design for a CRM program and is not employment, legal or financial advice. Staffing decisions depend on your market, your obligations and your own circumstances. Evaluate them with appropriate advisors.
