In 2023, we built CommercePro because HubSpot was where businesses could manage their customers. Marketing, sales, service and reporting all lived there. Commerce didn’t. Orders lived in one system, customer data in another, payments somewhere else again, and sitting between them was an integration whose entire job was to make different versions of the same customer eventually agree with each other.
We thought there was a better way, so we built commerce natively inside HubSpot. Three years later, we still believe exactly the same thing. We’ve just realised commerce was only the beginning.
Today, CommercePro, as an application, becomes part of Natively Labs its development company, alongside our new Natively AMS application. Two products solving very different problems, built around the same idea: put the capability where the customer data already lives.
Every business running commerce alongside a CRM pays a tax for it. You just won’t find it on the P&L.
It’s the order that exists in the store, but hasn’t yet reached the CRM. The customer who calls five minutes after buying something, while the service team can see who they are, but not what they just bought. The refund processed on Tuesday that turns up somewhere else on Thursday. Or the spreadsheet someone exports because two systems disagree, and nobody is quite sure which one is right.
None of this means the technology is broken. That’s almost the problem. It works well enough, and because it works well enough, businesses get very good at working around it.
The obvious answer was another integration. We could have built CommercePro as another commerce platform and connected it to HubSpot. That would probably have been easier. Instead, we built it inside HubSpot.
Commerce records live in HubSpot. Workflows happen in HubSpot. Reporting happens in HubSpot. Your customer service, sales and marketing teams are looking at the same customer and the same activity. There isn’t a commerce database sitting somewhere else waiting to sync with the CRM overnight. There’s just the customer record.
That distinction became much more important than we expected, because once you start looking for unnecessary systems, you see them everywhere.
Commerce was just where we encountered the problem first.
When we started working more closely with membership organisations, we saw exactly the same architecture wearing a different outfit. The CRM knew about communications. The association management system knew about membership. The events platform knew who attended. The payment platform knew who paid. The finance system knew whether the money actually arrived. And the people running the organisation were somehow expected to know all of it.
Want to know which members are due for renewal, attended two events this year, and haven’t engaged with the last three emails? That should be a segment. In plenty of organisations, it’s a project.
So we applied the same thinking that created CommercePro. What happens if the membership functionality lives inside HubSpot too?
That became Natively AMS. Memberships, renewals, events, subscriptions, payments, engagement and the member portal, built around the same records the organisation is already using for marketing, service, automation and reporting.
It wasn’t another system to integrate. It was a way to remove most of the integrating in the first place.
Once CommercePro was no longer the only product, something became obvious. CommercePro wasn’t the company. It was the first product.
Because the idea behind CommercePro had very little to do with commerce itself. The bigger idea was that businesses have spent years solving software problems by adding more software. Need ecommerce? Add a platform. Need membership management? Add an AMS. Need events? Add another platform. Need the systems to talk? Add an integration. Need that integration to do something more complicated? Add middleware.
Each decision makes sense on its own. Put enough of them together and you end up with a very sophisticated collection of software and a team of people spending far too much time keeping it all connected.
We’re interested in removing systems from that equation.
That’s why Natively Labs exists.
Natively Labs is the software company behind CommercePro and Natively AMS. CommercePro brings commerce into HubSpot. Natively AMS brings association management into HubSpot. And whatever we build next will have to pass the same test.
Does it remove a system rather than add another one? Does it put useful data closer to the customer record? Does it allow HubSpot to do more of the work without another database, login or integration sitting beside it? And, most importantly, can we build it genuinely natively?
If the answer to that last question is no, we’re probably not interested.
Native gets thrown around a lot in software. For us, it’s less of a feature and more of a constraint.
We can’t solve a difficult feature by putting another database behind the scenes and syncing the result back. We don’t want another login, another admin interface or another place your team has to go looking for information. Sometimes that makes building things harder. Sometimes something that would be straightforward to build as a standalone application takes considerably longer to build properly inside HubSpot.
That’s the trade-off.
What you get in return is something even a very good integration can never completely reproduce: one record. The order someone placed this morning, the membership they renewed last month, the event they attended last week, the support ticket they opened yesterday and the email they clicked ten minutes ago can all sit against the same person.
Not synced later. Not reconciled overnight. Just there.
Businesses don’t need more integrations. They need fewer systems that require integrating.
That was the argument behind CommercePro. It’s the argument behind Natively AMS. And it’s the one thing every product we build under Natively Labs will have in common.
Very little, which is exactly how we wanted it.
CommercePro is still CommercePro. Same product, same pricing, same roadmap and same team. Your HubSpot portal, installed app, store, support and contract don’t change. The only real difference is that CommercePro now sits under Natively Labs alongside Natively AMS.
There’s nothing to migrate, reinstall or reconfigure.
Natively AMS is our association management product built natively inside HubSpot. It gives membership organisations the functionality they would traditionally look to an AMS for, including memberships, renewals, events, subscriptions, payments and member experiences, without creating another disconnected system of record beside the CRM.
It’s the second product from Natively Labs and, in many ways, the product that made us realise we needed Natively Labs in the first place.
CommercePro proved that commerce didn’t need to sit outside the CRM. Natively AMS proved that the same thinking could extend much further.
We’re not going to invent a list of future products so we can put more boxes on a website. We have a much simpler filter.
We look for industries where a core operational system sits beside the CRM and an integration is expected to keep the two aligned. Usually there are spreadsheets involved. Usually someone on the team has developed an alarming amount of institutional knowledge about which system to trust. And usually the organisation has been dealing with it for so long that it has stopped looking unusual.
That’s interesting to us.
If the functionality can live genuinely natively inside HubSpot, we want to know whether the second system needs to exist at all. If it can’t be built natively, we don’t build it. That rule has already cost us ideas, and it will probably cost us more.
Today, that thinking has produced two products: CommercePro and Natively AMS. Now they have a company built around the idea that created them both.
Companies rarely end up with complicated technology because somebody made one terrible decision. They get there through ten perfectly sensible ones. A platform for this. A system for that. An integration between them. Another integration when something changes. A spreadsheet to cover the bit neither system quite handles.
Five years later, nobody can answer a simple question about a customer without opening three tabs.
We think there’s a better default. Build the capability where the customer record already lives, or don’t build it.
We didn’t rename the company because we changed our mind. We renamed it because we finally realised the idea was bigger than CommercePro.
And now it has a name.