Build vs buy CPQ on Salesforce: when custom makes sense and what it really costs
Build when your quoting is simple enough to fit in Flows and a few Apex classes and you have a developer who will still be there in three years. Buy when pricing changes more than once a quarter, when renewals and amendments matter, or when the second developer would be the first hire you make for CPQ. Most builds cost more than a package by year two, not because the code is expensive but because every pricing change becomes a deployment. There is a test below.
Which side of the line you are on
- Quotes are single products or short lists, pricing is a price book, no subscriptionsBuild — or use standard Quotes with Flow; a package is more than you need
- Pricing rules change monthly, bundles nest, discounts need approval tiersBuy — every rule change in a build is a deploy
- You bill subscriptions and need renewals, co-terming, prorationBuy — the renewal engine is the part nobody finishes building
- You already built one and it works, but one person understands itPlan the exit now, before that person leaves — playbook
The honest case for building
A build is right more often than vendors admit. If reps quote a handful of products at list price, standard Salesforce Quotes plus a Flow for approvals is a week of work and costs nothing per user. If your catalog is small and stable and your discounting is one number, you do not need a configurator. A package adds objects, a learning curve and a licence line for problems you do not have.
- Simple catalog, stable pricing. Under fifty products, list price with a single discount field, no bundles.
- No subscriptions. One-time sales with no renewals, amendments or proration.
- A developer who owns it. Someone on staff who will maintain it, with a second person who can read it.
- Low change rate. Pricing and product changes a few times a year, not a few times a month.
What a build actually costs
The build itself is rarely the expensive part. The cost is what happens after go-live, when every pricing change is a code change. Here is the cost line that does not appear on the build estimate.
| Cost | In a build | In a package |
|---|---|---|
| Initial build or implementation | Developer weeks; usually 8–16 for anything with bundles and approvals. | Fixed fee where published: Kugamon $30K one-year, $25K multi-year (AppExchange). |
| A pricing change | A ticket, a developer, a sandbox, a deploy. Days. | An admin edits a price book entry or a tier. Minutes. |
| A new bundle | New Apex or Flow logic, tests, deploy. | Configuration. |
| Renewals and amendments | The part most builds never finish; usually spreadsheets on the side. | Subscription objects, renewal opportunities, co-terming, proration built in. |
| The second developer | Required. One person who understands it is a single point of failure. | Not required; any Salesforce admin. |
| Salesforce release upgrades | Yours to regression-test three times a year. | Vendor’s problem. |
| Documentation | Whatever the developer wrote down. | Vendor training materials and release notes. |
| Exit | Untangling Apex from standard objects; 4–8 weeks to a package. | Managed package uninstall; data stays in standard objects. |
None of this is unique to Kugamon; it is the shape of any managed package against any build. What is unique is that the fixed fee and per-user price are published, so the comparison can be run. Put your developer cost against the calculator and the answer usually arrives by year two.
The decision tree
What the people who built one say
The clearest evidence is what teams say after leaving a build. Two themes recur in public reviews of Salesforce-native packages: the speed of going live compared with what they had, and that a non-developer can run it afterwards.
The custom CPQ playbook covers the 4–8 week move: inventory the Apex, design the catalog first, migrate the install base in one pass, run one quote cycle in parallel.
If you build anyway
- Price from standard
Product2andPricebookEntry. A build that invents its own price objects is the hardest kind to leave. - Keep quote data on standard
QuoteandQuoteLineItemwhere you can; custom objects for quotes are a second migration later. - Write the renewal process down before you write the code. If you cannot describe co-terming in a paragraph, you cannot build it in a sprint.
- Two people must be able to deploy it. If that is not true, you have a risk, not a system.
- Set a review date. Re-run the calculator each year with the developer hours you actually spent.
What Salesforce admins say on AppExchange
Quoted verbatim from the Kugamon listing on AppExchange. Reviewer names and dates as published there. Read all 134, including the critical ones →
★★★★★Easy to understand, easy to implement
“This SFDC-native platform is lightweight but powerful, bringing the entire sales process onto one pane of glass. No more disconnected Opportunities and Quotes/Orders, no more fractured approval processes, just more control over everything. Implementation is a breeze.”
★★★★★Great Salesforce Native CPQ Tool
“Kugamon is an awesome tool that I found to be easy to understand and configure for our complex use case. Not to mention, they have a fantastic onboarding process that does a great job of covering every feature.”
★★★★★Clear & Intuitive
“The Kugamon team is incredibly responsive and handle support questions very quickly. It’s clear they genuinely value customer feedback and are always innovating.”
For simple quoting — small catalog, one discount field, no subscriptions — yes: standard Quotes and Flow cost nothing per user. For bundles, tiers, approvals or renewals, a build usually costs more by year two because every pricing change becomes a deployment and the renewal engine is never finished. Model it in the calculator.
No vendor publishes a figure and neither do we; it depends on change rate. The reliable rule is that a build needs two people who can deploy it and regression testing on each Salesforce release. Track the developer hours for a year and compare them with a published implementation fee (Kugamon publishes one).
Yes, typically in 4–8 weeks when the build prices from standard Products and Price Books, longer when it invented its own price objects. The playbook covers inventory, catalog design, install-base migration and a parallel run.
Published prices, your team size
The calculator uses Salesforce’s published Revenue Cloud Advanced price and Kugamon’s published AppExchange price. Competitor implementation figures are labelled estimates.