AI changed that calculus. Now companies are seriously considering, and in some cases building, internal versions of products they would have bought without a second thought a few years ago. The cost to build has dropped enough that the question is no longer absurd. But the cost to own hasn't changed at all.
What changed
AI-assisted development collapsed the up-front cost of building software. Models write the boilerplate. What took weeks of setup takes hours. The same team that couldn't justify a three-month internal project can now ship something functional in days.
This has a lot of people asking a natural question: if we can build it faster and cheaper than before, why pay a vendor every month? Why not own the IP? Why not control our own roadmap?
The logic tracks, and that's why so many teams are exploring it. I've had conversations with multiple companies over the last few months who have or are considering building their own CRM. In each case, none of them had accounted for what it would cost to own and maintain beyond the initial build.
The hidden costs of building
But cost to build is only half the picture. The cost to own is the other half, and most teams miss it.
Building a replacement for an existing SaaS product means taking on everything that product handles for you. That's a longer list than most teams realize.
Support. A SaaS product has a support team. Yours will need one too — or your engineers will answer tickets instead of building product. Every bug, every "how do I..." question, every permission issue lands in someone's lap. That burden gets absorbed one way or another — either by a dedicated support person or by your engineers answering tickets instead of building product.
Security and compliance. SOC2 audits, penetration tests, vulnerability management, data encryption at rest and in transit. These don't go away because the product is internal. If you process customer data, your internal tool inherits every compliance requirement your business faces. A SOC2 audit for an internal tool isn't cheaper than for a vendor — the auditors charge the same either way.
Permissions and access control. Everyone needs role-based access, audit logs, and the ability to grant and revoke access. The first version never has them. The second version takes three months longer than planned. The third version has them, but nobody trusts them yet.
Onboarding every new hire. When you use a standard tool, new employees either already know it or can learn it from thousands of tutorials, certification programs, and community forums. When you build custom, every new person needs to learn your system from scratch. That cost repeats with every hire, every contractor, every intern. Over the life of the company, it exceeds the build cost several times over. And unlike a vendor tool, your custom system will never have a certification or a YouTube tutorial.
Integrations. Your new internal tool needs to talk to every other tool in your stack. Every API change at every vendor breaks something. Over a three-year period, you will spend more on integrations than you spent on the initial build.
On-call. When it breaks, it's your team's responsibility. There is no vendor SLA. No escalation path.
Feature requests. Your team will have opinions about what the tool should do. That feels like a benefit, but is it really? When do the features stop getting built? Sometimes having roadblocks is actually a good thing.
Budget. A new internal product means new costs: support staffing, infrastructure, security tooling, compliance audits, ongoing development. These get distributed across your organization in ways that are hard to track, which means they rarely surface in the build-versus-buy decision.
A good SaaS vendor spreads these costs across thousands of customers. Your internal version concentrates them on your team. The ongoing maintenance, compliance, and staffing often exceeds the initial build cost within a year. Do the math: build cost vs. three years of operating cost. The SaaS subscription wins almost every time — and you get the vendor's improvements for free.
When it makes sense
There are two cases where building makes sense despite these costs.
First, when the thing is wholly unique to your business. Your core differentiator — the workflow that makes you money that no off-the-shelf tool can replicate. A custom pricing engine for a unique business model. A proprietary risk model. A workflow that is itself the product.
Second, when no adequate off-the-shelf product exists. This is rarer than most teams assume. The SaaS ecosystem is mature. Most problems have been solved by someone.
Everything else should default to buy. Your engineering team's time is better spent on things that make your business unique, not on rebuilding features a vendor already ships better.
The real question
The real question isn't whether to replace HubSpot. It's what you can build around the tools you already have. Buy the platform for the foundation, build the custom layer for the stuff that makes you different. You get standard infrastructure from a vendor that handles the boring stuff, plus custom workflows that match how your business actually runs.
That approach sidesteps every hidden cost I've raised. You're not building the foundation — you're inheriting it from the vendor. They handle support, compliance, integrations, and the whole ecosystem. Your team doesn't have to change how they work, because the platform stays the same.
The platform stays. The custom stuff gets built on top. That's what Part 3 covers.