The usual hiring signals do not work well for HubSpot development. Partner tier reflects an agency's sales volume with HubSpot, not the quality of its code. Portfolio screenshots show design, not build quality. Testimonials rarely come from anyone who inherited the codebase afterwards.
These nine questions surface what those signals hide. Ask them before you sign anything.
Why it matters: Plenty of agencies list HubSpot as a service and subcontract every project. Others have designed HubSpot sites without ever writing a module.
A good answer names live URLs you can visit, explains what was custom versus theme-based, and mentions something that was difficult about each.
A bad answer shows mockups, offers NDA excuses for everything, or produces sites where the only HubSpot involvement was hosting.
Why it matters: This is the single biggest cost variable. An agency that always recommends custom is optimising for its invoice.
A good answer asks about your requirements before answering, and will sometimes recommend a customised marketplace theme for a project that does not need more.
A bad answer recommends a full custom build before understanding what you need, or dismisses themes as inherently inferior.
Why it matters: Some agencies retain their module library and licence it to clients. Leaving them then means rebuilding your site from scratch — a switching cost you discover at the worst possible moment.
A good answer is immediate and unambiguous: you own everything, and it is written into the contract.
A bad answer involves hesitation, phrases like "our proprietary framework," or a licence that expires if you stop paying a retainer.
Why it matters: This reveals whether the developer has thought about the people who use the site daily. Too few fields and your team calls the developer for every change. Too many and your brand consistency erodes within months.
A good answer describes deliberate restraint — content and imagery editable, spacing and colour locked to the design system — and can explain the reasoning.
A bad answer is "everything will be editable," which sounds generous and produces a site that looks different on every page.
Why it matters: Redirect mapping is the difference between keeping your search traffic and losing it. It is also boring, so it gets skipped.
A good answer mentions crawling the existing site, building a one-to-one URL map, using 301s rather than 302s, avoiding redirect chains, and testing against staging before launch.
A bad answer is any version of "we will set up redirects" without detail, or worse, a plan to point old URLs at the homepage.
Why it matters: Something always surfaces in the first fortnight. Whether that is covered or invoiced should be agreed while you still have leverage.
A good answer defines a specific support window, distinguishes clearly between defects and new requests, and states hourly rates for work beyond it.
A bad answer is vague reassurance, or a mandatory retainer presented as the only support option.
Why it matters: Some agencies build sites that are technically excellent and practically unusable by anyone but themselves. That dependency is sometimes accidental and sometimes not.
A good answer includes a training session, written documentation, and an offer to demonstrate the editor on a live page before you commit.
A bad answer treats training as an add-on, or suggests it is simpler if they just make the changes for you.
Why it matters: Scope disputes are the most common source of budget overruns, and they nearly always trace back to an assumption nobody wrote down.
A good answer is a specific list: copywriting, photography, third-party integrations, content migration beyond an agreed page count, your HubSpot subscription. A developer who has run real projects will answer this quickly, because they have been burned before.
A bad answer is "everything you need is covered." Nothing covers everything.
Why it matters: The person who sells the project is often not the person who builds it. There is nothing wrong with a team, but you should know who is on it.
A good answer names the developer, describes their HubSpot experience, and is open about any subcontracting.
A bad answer deflects to "our team" for every question about who is actually writing the code.
You will get better quotes, and quotes that are actually comparable, if you bring these:
Partner status indicates sales volume through HubSpot, not development skill. It is not meaningless — partners have platform access and support channels — but it should not outweigh demonstrable build quality. Judge the work, not the badge.
A strong freelancer often produces better HubSpot work at lower cost than a mid-sized agency, because you are talking directly to the person building it. The trade-off is continuity: agencies survive individual departures. For a single build, a freelancer is frequently the better value. For an ongoing programme, weigh the risk.
They usually differ because they scoped differently, not because one is overpriced. Ask each to break the quote into layouts, modules, content migration, and integrations. The differences become obvious immediately.
For rates, yes — regional differences are substantial. For quality, no. What matters is timezone overlap for meetings, communication clarity, and whether they can show you work they have actually shipped.
Four to twelve weeks for most marketing sites. Anyone promising a custom build in a week is either using a template they will not admit to, or will miss the deadline.
The best signal is not in any answer. It is whether the developer ever tells you that something you asked for is unnecessary. Anyone who agrees with every request is selling, not advising.
If you want to run these questions past us, get in touch — and feel free to use them on us first.