It made sense to build it. Here is why it stops making sense to keep it.
A $400M enterprise built its own CPQ system in-house. Three engineers, six months, and a tool that did exactly what the business needed at the time. For two years, it worked. Then the product catalogue doubled. Then international pricing was added. Then a new subscription model. Then compliance requirements changed. Each addition required an engineer. Each engineer was pulled from the core product team. Three years in, the homegrown CPQ had become a full-time maintenance burden, owned by no one, understood by fewer, and holding the entire quoting process hostage. The system did not fail overnight. It failed one feature request at a time.
Where the process breaks down
Building a CPQ in-house feels like the right call at the right stage. Off-the-shelf tools are expensive, rigid and built for someone else's business model. A homegrown system offers control, flexibility and a perfect fit for how the company works today.
The problem is the word today.
Homegrown CPQ systems are built around the current product catalogue, the current pricing model, the current team size and the current sales motion. When any of those things change, and in a growing business all of them change, the system has to change too. Unlike a commercial platform with a dedicated engineering team behind it, a homegrown system only evolves when someone internally has the time and context to evolve it.
That time rarely comes. Product roadmaps take priority. Engineers move to other teams. The original architect leaves. What was once a clean, well-understood system becomes a black box, held together by institutional knowledge that is slowly walking out the door. Every new requirement becomes a negotiation between sales ops and engineering. Every change introduces risk. Every release requires regression testing that no one budgeted for.
The system that was built for control becomes the thing the business has the least control over.
Where revenue quietly leaks
A homegrown CPQ that cannot keep pace with the business creates the same revenue risks as having no CPQ at all, just with more engineering overhead on top.
Feature lag
When a new pricing model, product bundle or regional discount cannot be added to the quoting system without an engineering sprint, the business works around it. Reps quote manually. Sales ops builds spreadsheet patches. The homegrown system becomes partially irrelevant, maintained at cost, bypassed in practice.
Knowledge dependency
Homegrown systems are only as reliable as the people who understand them. When the engineer who built the discount logic leaves, that logic becomes untouchable. No one wants to change something they do not fully understand. The system calcifies. Pricing rules that made sense three years ago stay in production because removing them feels riskier than keeping them.
Integration failure
As the business grows, the revenue stack grows with it. New CRM. New billing platform. New e-signature tool. Each integration with the homegrown CPQ is a custom build, expensive, fragile and maintained by a team that has higher priorities. Over time, integration debt becomes the dominant cost of keeping the system alive.
Opportunity cost
Every engineering hour spent maintaining a homegrown CPQ is an hour not spent on the core product. At scale, this is not a minor inefficiency, it is a strategic tax on the engineering team. The business is paying product engineers to maintain sales infrastructure. That trade-off gets harder to justify every quarter.
Conservatively, a $200M business running a homegrown CPQ spends 15 to 20 per cent more in total cost of ownership than one running a modern commercial platform, once engineering time, integration maintenance and workaround overhead are fully accounted for.
Why legacy CPQ does not solve it either
The natural response to a failing homegrown system is to replace it with an established CPQ. But companies that moved to legacy platforms, tools like BigMachines, early Apttus, Cincom or on-premise SAP quoting modules, often traded one set of problems for another.
Homegrown systems failed because they were too dependent on internal engineering. Legacy CPQ systems failed for the same reason, just with external vendors instead of internal teams. Pricing rule changes still required developers. Implementations still ran nine to eighteen months. Monolithic architecture still meant you could not update one piece without risking everything else.
The fundamental problem, a system that cannot keep pace with a changing business, was not solved. It was just relocated.
What good looks like
The failure of homegrown CPQ is not an argument against building things. It is an argument for building on the right foundation.
ServiceNow CPQ gives engineering teams what homegrown systems promised, control, configurability and fit, without the maintenance burden that kills them. Pricing logic, approval workflows, product configuration and contract generation are managed by business users in a UI, not by engineers in a codebase. When pricing changes, sales ops updates it directly. When a new product bundle is added, product teams configure it without raising a ticket.
For engineering leadership, the case is straightforward. ServiceNow eliminates the integration tax, connecting natively to CRM, billing, ERP and fulfilment without custom middleware. Security and compliance are maintained at the platform level, not by internal teams. And the engineering hours currently spent on CPQ maintenance get redirected to the core product, where they create competitive advantage instead of managing technical debt.
For sales and revenue leaders, the outcome is the same as every other modern CPQ scenario: quotes in under an hour, accurate pricing, automated approvals and clean data into billing. For companies coming off a homegrown system, there is an additional benefit: reliability. A system that works the same way every time, for every rep, without depending on one engineer who still remembers how the discount logic was built.
- AI strengthens consistency. Configuration errors are flagged before quotes go out, margin risk is surfaced in real time, and every rep's quoting judgement starts to look like the best rep on the team.
- Engineering capacity comes back. Product engineers stop maintaining sales infrastructure and return to the work that differentiates the business.
- Change stops being scary. A new pricing model, region or bundle is a configuration task, not a release cycle.
The businesses that built homegrown CPQ did the right thing for their stage. ServiceNow is the right thing for the next one.