Somewhere between the third quote and the second week of interviews, most people trying to hire a HubSpot developer discover the same thing. Every candidate says yes. The person who builds beautiful landing pages says yes, the person who writes coded workflow actions says yes, and the person who has spent four years building CRM integrations says yes. They are all telling the truth, and only one of them can do the thing you need.
That is the actual difficulty here, and it is not a difficulty of supply. "HubSpot developer" is a single job title stretched across four separate engineering disciplines that share a platform and almost nothing else. There is no certification left that distinguishes them, the platform's app development model changed materially this year, and the published rate data covers a kind of work that may have nothing to do with your project. This guide is about telling the four apart, working out which one your problem needs, and vetting a technical hire when you are not technical yourself. If you have not yet decided whether the work is engineering at all, the guide to hiring a HubSpot consultant covers the configuration side first.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
What a HubSpot Developer Actually Does
Four jobs, one title. Read these and pick the one that describes your problem before you write a job post or a brief, because everything downstream depends on getting this right.
Content Hub developer
Websites, landing pages, themes, templates and custom modules, built with HubL, HubSpot's own templating language, alongside HTML, CSS and JavaScript. This is front-end work and it is the largest of the four populations by some distance, because it is where HubSpot's developer community started. If your problem is that the site is slow, the templates are rigid, or marketing cannot build a page without a ticket, this is your hire.
Integration developer
Code written against HubSpot's CRM APIs to move data between the portal and other systems: the billing platform, the ERP, the warehouse, the support desk. The visible part is small and the invisible part is most of the job, because authentication, rate limits, retries, deduplication, conflict resolution and failure alerting are what separate an integration that works in a demo from one that survives two years unattended. This is back-end engineering.
App and UI extension developer
Building on HubSpot's projects platform: private and public apps, and the UI extensions and app cards that render inside HubSpot's own interface, written in React. This is how you put data from another system directly on a contact record rather than making a rep open a second tab. Note that UI extensions for private apps require an Enterprise subscription, so check your tier before you scope anything here.
Automation developer
Custom coded actions inside workflows, written in JavaScript or Python and running in HubSpot's own serverless environment. This is the smallest scope of the four and often the right answer to a problem that sounds much bigger. A twenty-line coded action can replace a fourteen-step workflow chain nobody understands, and it is worth asking whether your integration is really an integration before commissioning one.
Do You Need a Developer at All?
Worth thirty seconds before you spend anything, because the cheapest developer is the one you did not need to hire. A great deal of what gets described as a development problem is a configuration problem wearing a technical costume.
Signs the work is genuinely engineering
Two systems disagree and a person reconciles them by hand. A monthly export to compare HubSpot against billing or the ERP is an integration that does not exist yet. No amount of portal tidying closes that gap.
The objects you care about sit outside the marketplace connector. The native app syncs contacts, companies and deals, and your business runs on line items, quotes, tickets, subscriptions or a custom object. There is no setting that extends a connector's object coverage.
Something has to happen in seconds rather than overnight. A closed deal that must provision an account, a failed payment that must pause a sequence. Scheduled syncs cannot express urgency, and that is an architecture question rather than a settings question.
The same field is edited in two systems and both edits matter. Field-level ownership is the point where mapping tools stop and code starts, and it is the single most reliable indicator on this list. The data mapping guide covers where that boundary sits.
You need something rendered inside HubSpot that HubSpot does not render. Support history, usage data or account health on the contact record itself, rather than in another tab a rep will not open.
If none of those are true and the complaint is that reporting is a mess or the pipeline is inconsistent, you want a consultant rather than a developer, and you will get a better outcome for less money. If several are true, keep reading.
What "HubSpot Certified Developer" Means in 2026
This is the part that catches people out, and it is worth being precise about because the answer has changed.
There is no current HubSpot certification for developers. HubSpot retired its Design Certification in September 2018, explaining at the time that the content was too broad to serve either marketers or developers well, and built the CMS for Developers certification to replace it in early 2019. That replacement was itself sunset on May 30, 2025, with HubSpot noting that the course "has hit a point that significant revisions are needed to keep up with the pace of Content Hub's updates." Existing certifications remain valid until they expire.
So when a profile or a proposal says HubSpot certified developer in 2026, it means one of three things. It is an expiring CMS for Developers credential, earned before mid-2025 and covering templating rather than integration. It is one of the free HubSpot Academy marketing or sales certifications, which take between two and eight hours and demonstrate product vocabulary rather than engineering ability. Or it is a firm-level Solutions Partner accreditation, which is genuinely meaningful because HubSpot reviews documentation from real customer projects to grant it, but which belongs to a company rather than a person and is gated to Platinum tier and above. The partners guide covers how those tiers and accreditations actually work.
None of this means credentials are worthless. It means the credential layer that used to do your filtering for you is gone, and the filtering now has to happen in the conversation. That is what the vetting section below is for.
The Platform Changed in 2026, and It Is a Free Currency Check
HubSpot moved app development onto its projects platform this year, and it did so with a hard cutoff rather than a gentle nudge. The ability to create new legacy public apps through the developer platform interface was disabled for accounts created on or after May 26, 2026, and disabled for existing accounts by June 23, 2026. All new public app development now happens on the projects-based platform, which uses a CLI workflow and supports UI extensions, app cards and deployment tooling. Existing legacy public apps are unaffected and continue to run as they always did.
The same is true in the other direction. Because the projects platform has moved quickly, with UI extension support expanding across app settings and app pages through 2026, a candidate who is actively working on it will have opinions about it, usually including some complaints. Fluent complaint is a better currency signal than fluent enthusiasm.
Where to Hire a HubSpot Developer
Four routes, and the honest way to choose between them is to ask how long the thing you are building has to keep working without you.
Marketplaces and referrals give you the fastest start and the lowest cost, and for a theme build, a set of modules or a coded workflow action that is exactly right. The weakness is not skill, it is what happens in year two. An unattended integration will outlive most freelance relationships, and expired tokens do not announce themselves.
A bench, cover when somebody leaves, and a commercial relationship with HubSpot. Two things to check before signing. Many HubSpot agencies are primarily marketing shops that subcontract technical work, so ask who is actually writing the code. And confirm whether the technical work is protected when a campaign deadline arrives, because incentives decide that, not intentions.
Narrower than an agency, more resilient than a freelancer, and usually priced as a defined scope with a written definition of done. The right shape when the job has a finish line and then needs to keep running afterwards. Ask what maintenance looks like before you ask what the build costs.
The only route that accumulates institutional memory, and the cheapest per hour over several years. It is also a hiring process, a salary and a long ramp, and it fails predictably when a company hires one generalist to cover all four specialisms. Most teams do better with an internal owner plus outside specialists for the engineering.
One route worth naming separately because people ask about it: HubSpot does not publish a directory of individual developers. The Solutions Directory lists partner companies, ranked by a tier that is calculated largely from sold and managed subscription revenue. It is a useful place to find firms and a poor place to find engineers.
What It Costs to Hire a HubSpot Developer
Published rate data for HubSpot developers exists, and reading it without context is how projects get mispriced.
Upwork's published guidance for HubSpot freelancers puts the median at 25 dollars an hour, within a typical range of 15 to 40 dollars. That figure is real, and the page is specific about the work it covers: CRM cleanup, workflow creation, email setup, dashboard building and general portal support. For that work the rate is entirely fair.
The trap is assuming it extends to the second and third specialisms on this page. Portal configuration and integration engineering are different labour markets, priced differently everywhere, and the reason is the failure mode rather than the difficulty. A badly built dashboard is visibly wrong on the day it ships. A badly built integration works in the demo, works in week one, and then quietly drops a subset of records for a month because nobody handled a rate limit response. One of those is a rework. The other is a data problem you find out about from a customer.
A single blended hourly rate quoted across templating, integration and app work is not a bargain. It is a sign that whoever quoted it has not noticed the difference.
More useful than the rate is the pricing model, because the model decides who carries the estimation risk.
| Model | You are buying | Carries the risk | Best when |
|---|---|---|---|
| Hourly | Time | You do | Scope genuinely cannot be defined yet, such as a discovery spike |
| Project (fixed fee) | A defined outcome | They do | The build has a clear finish line and a written scope |
| Monthly retainer | Ongoing capacity | Shared, and often nobody | Something is live and needs maintaining, with written deliverables |
| In-house salary | A person | You do | The work is continuous and central to how you operate |
For a build with a defined end, prefer a fixed fee. It moves the estimation risk to the only party actually qualified to estimate, and it removes the structural oddity of hourly billing, which quietly penalises the developer who works faster because they have built it before. For anything that runs unattended afterwards, a maintenance arrangement is not optional. The custom HubSpot integration guide covers what a build should include and what the ongoing half actually costs.
How to Vet a HubSpot Developer Without Being Technical
You do not need to evaluate code to evaluate an engineer. These six questions have answers you can score on shape, and the difference between somebody who has shipped and maintained integrations and somebody who has not is obvious within a sentence or two.
Six questions and what a good answer sounds like
"What happens when HubSpot rate limits you?" A good answer mentions backing off and retrying rather than failing, and often mentions that the CRM search endpoint is limited far more tightly than the general API, which is what a naive build hits first. A weak answer is a reassurance that it will not be a problem.
"Which system owns each field, and what happens when they disagree?" The correct answer hands the question back to you, because it is a business decision rather than a technical one. Somebody who answers it confidently on your behalf is about to make that decision without you.
"What happens when somebody deletes a record on one side?" Deletes, merges and duplicates are where integrations actually break, and the answer tells you immediately whether somebody has run one in production. Experienced people usually have a story here rather than a policy.
"Private app or public app, and why?" There is a real answer, which turns on whether this is for you alone or for distribution, and on which tier you are on. Any clear reasoning is a pass. Not knowing the distinction exists is disqualifying for integration work.
"How would I know if this broke at 3am on a Sunday?" Monitoring and alerting are the difference between an integration and a script. If the answer is that you would notice, what they are proposing to build is a script.
"Show me something you built that is still running, and tell me how you know." The strongest question on the list, because it filters for durability rather than delivery. A portfolio proves somebody shipped once. Knowing the current state of a two-year-old build proves somebody maintained it.
Red flags
Signs of a developer who has shipped and maintained
- Asks which of the four jobs this is
- Pushes field ownership decisions back to you
- Talks about failure handling unprompted
- Has opinions about the projects platform
- Names what is out of scope
- Asks who maintains it after go-live
Signs to keep looking
- Says yes to all four specialisms equally
- Quotes one blended rate for everything
- Leads with a certification badge
- Portfolio is entirely websites for an API project
- No answer on monitoring
- Wants to host it on their own account
The most reliable positive signal is a candidate who asks which of the four jobs your project is before quoting. It is the question somebody who has been burned by the mismatch learns to ask first.
What to Agree Before Any Code Is Written
Short section, high consequence. Three things belong in writing before work starts, and they cost nothing to agree at the beginning and a great deal to fix later.
The repository is yours
Code lives in a repository your company controls from day one, not one you are handed a copy of at the end. The difference matters most in the case where the relationship ends badly, which is exactly the case nobody plans for.
The credentials are in your accounts
Private app tokens, OAuth clients and any third-party API keys sit in accounts registered to your company, with your developer holding access rather than ownership. The common failure is quiet: eighteen months on, the token has expired, and the only person who could rotate it is unreachable.
Somebody is named for when it changes
Configuration does not rot. Integrations do, because the platforms at both ends keep shipping. Endpoints get deprecated, tokens expire, and a field somebody adds in HubSpot on a Tuesday can break a mapping. A build with no maintenance arrangement is not finished, it is just not broken yet. The custom integration guide covers what that ongoing half should include.
Need the integration specialist, not the website one?
If your project is the second job on this page, connecting HubSpot to billing, the ERP, the warehouse or the support desk, that is a specific discipline rather than a general HubSpot skill. StackTie builds custom HubSpot integrations for a fixed fee and maintains them on a flat monthly retainer, with the repository and the credentials in your hands from day one. Live in 14 days or your money back. Book a free audit and we'll tell you plainly which of the four jobs your project actually is, including when the answer is that you do not need a developer.
The Bottom Line
The hardest part of hiring a HubSpot developer is not finding one. It is that four different engineering professions answer to the same title, and the market has no mechanism left to sort them for you. Decide first whether your problem is templating, integration, app work or a coded action, and treat that decision as the most valuable thing you do in the whole process.
Do not lean on credentials to do the filtering, because there is nothing left there to lean on. HubSpot retired its Design Certification in 2018, sunset the CMS for Developers certification that replaced it in May 2025, and has not published an individual developer credential since. Firm-level accreditations still mean something and are gated to larger partners, so their absence at a small specialist tells you nothing at all.
Read the rate data for what it covers rather than what it is titled. Prefer a fixed scope with a written definition of done over an open hourly rate, and treat a single blended rate across templating and integration work as a signal in itself. Then agree the three unglamorous things before anybody writes code: your repository, your credentials, and a named owner for the day HubSpot changes something. Integrations do not fail on the day they ship. They fail eighteen months later, and who you hired decides whether that is a phone call or an archaeology project.
