HubSpot app development.
Your product, inside their CRM. If your customers run HubSpot, a listed app is a distribution channel. Public apps, OAuth, CRM cards and UI extensions, built to the marketplace requirements rather than discovered during review.
Built the app. Failed the review.
Marketplace listing has real requirements: scope minimisation, OAuth handling, uninstall behaviour, support commitments and documentation. Teams discover them at submission, after the architecture is set, and rework costs more than building it right would have.
Submitted. Rejected. Twice.
Apps — the reviewWhat a listed app actually requires.
OAuth done correctly
The install flow, token refresh, revocation and multi-portal token storage. Getting this wrong means installs that silently stop working weeks later.
Scopes kept minimal
Request only what the app uses. Over-broad scopes slow review, frighten security teams and reduce installs, and they are hard to reduce once customers have granted them.
CRM cards and UI extensions
Your data on the HubSpot record where the user already works, rather than asking them to open another tab. This is what makes an app feel native.
Webhooks and event subscriptions
Reacting to changes without polling, with signature validation and a processing pipeline that copes with a customer doing a bulk import.
Multi-tenant from the start
Portal isolation, per-portal rate limit budgets and per-portal configuration. Retrofitting multi-tenancy into an app built for one customer is a rewrite.
Listing requirements
Documentation, support commitments, uninstall handling, privacy disclosures and the demo portal. We prepare the submission rather than discovering the checklist at the end.
Engineers, working the way engineers work.
Scope in writing
What is being built, what it will not do, and how we will both know it is finished. Fixed scope where the work is knowable, a sprint rate where it is not.
Build in the open
Version control, a preview environment and a running demo, so you are not waiting until the end to find out what you are getting.
Review against the portal
Tested inside your actual portal with your actual content, at phone, tablet and desktop widths, before anybody calls it done.
Ship and document
Deployed, with the source handed over and a page explaining how to change it. You own what we build.
Built for one customer, listed for everyone.
Most HubSpot apps start as a private integration for a single portal. Turning that into a listed product means multi-tenancy, configuration, onboarding and support — and each of those is an architectural decision, not a feature you add afterwards.
What people ask before they commit.
How long does marketplace approval take?
The review itself is weeks, and the number of rounds depends entirely on how closely the app was built to the requirements. Building to them from the start is the difference between one round and four.
Do we need a public app?
Only if other portals will install it. If it is just your own integration, a private app is simpler, faster and has no review.
What are UI extensions?
React components that render inside HubSpot records and let a user act on your product without leaving the CRM. They are the most valuable and most underused part of the app platform.
Can you maintain the app after launch?
Yes, on a retainer. Platform versions move, requirements change and customer portals do unexpected things, so ongoing ownership matters more here than in most projects.
How long does it take to build?
Eight to twenty weeks for a listed app with CRM cards and a reasonable feature set. A private integration is much faster.
Where people go from here.
Ship it to the marketplace.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.