Build vs buy: why custom revenue systems rarely pay off
Build when quoting is simple, will stay simple, and a developer will own it for years. Buy when the system has to run orders, invoices, payments, subscriptions and renewals: that is where custom builds strain, then break. The quote is the easy part. The people, documentation, maintenance and feature gap that follow are where the cost lives.
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
- The system has to invoice, take payments or collectBuy — billing defects reach customers’ invoices and your financial statements
- 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 version of the argument
Build can make sense for CPQ. A handful of custom objects, a pricing formula and a quote template: a capable Salesforce developer can stand that up. If reps quote a few products at list price, standard Salesforce Quotes plus a Flow for approvals is a week of work and costs nothing per user. A package adds objects, a learning curve and a license 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.
But CPQ is one of the five RevOps workflows. The moment the build has to handle orders, invoicing, payments, proration, amendments, co-termed renewals, tax, dunning and MRR and ARR roll-ups, it stops being a project and becomes a product: one your company owns, staffs, documents and maintains, in competition with vendors who do nothing else.
The quote is the easy part
Build proposals are almost always scoped against CPQ, because CPQ is what sales sees. The workflow doesn’t stop at the quote, and each stage downstream carries more edge cases than the one before it.
| Workflow stage | What a build has to handle, every time | Typical outcome of a custom build |
|---|---|---|
| Lead-to-Close CPQ | Product catalog, bundles and options, tiered and account-specific pricing, discounts and approvals, quote documents, e-signature | Feasible. Version 1 ships, usually late; approvals and document generation are the first cuts. |
| Lead-to-Bill Orders and invoices | Order release, invoice schedules, recurring invoices, charges and credits, US sales tax and VAT/GST, multi-currency | Strains. Tax and credit handling become spreadsheets beside the system. |
| Lead-to-Cash Payments | Gateway connections (PCI scope), saved payment methods, applied and unapplied payments, refunds, receivables roll-ups, dunning | Strains. PCI and gateway maintenance alone justify a vendor. |
| Lead-to-Revenue Subscriptions and assets | Subscription terms, proration, mid-term amendments, upgrades and downgrades, co-terming, asset tracking, MRR, ARR and TCV roll-ups | Breaks. Proration and amendment math is where custom builds quietly produce wrong revenue numbers. |
| Lead-to-Renewal Renewals | Automated renewal opportunities and orders, renewal notice emails, price uplifts, cancellations | Breaks. Renewals are built by hand, missed, or handled outside the system. |
The build outlives the builders
Custom revenue systems don’t fail on launch day. They fail eighteen months later, when the one person who understood the design has moved on and the business needs a change nobody can safely make.
- Version 1 isn’t the feature set you compared it to. The build is justified against a vendor’s current product. What ships is a version 1 with the hard features deferred (approvals, proration, renewals, tax) and no roadmap to close the gap. Meanwhile the vendor ships again next month.
- The builders lose interest, then leave. A billing system is interesting to build and tedious to maintain. The developers who were energized by the new project drift to the next one, or to the next employer. What remains is a system with no champion and a backlog nobody is excited to own.
- Documentation is written last, which means never. Vendors ship help centers, release notes and training because their business depends on it. Internal builds get a README and tribal knowledge. Users learn by asking the person who built it, until that person is gone.
- The technical design becomes a mystery. Triggers, flows and Apex accumulate without an architecture anyone wrote down. Bringing a new developer up to speed means reverse-engineering production: slow, expensive and risky, because the only test environment is the one billing customers.
- The skill set rarely matches the problem. Quote-to-cash that holds up takes revenue-recognition knowledge, tax logic, PCI awareness and years of edge cases from many customers. A strong Salesforce developer is not a billing product team, and shouldn’t be expected to be one.
- Nothing improves unless someone is paid to improve it. A purchased platform gets new features, Salesforce release compatibility and security fixes as part of the subscription. A build gets them only if a team is permanently assigned to maintain it, a cost that rarely appears in the original business case.
The cost benefits aren’t there, even with AI
The build business case usually compares developer hours with license fees. The real comparison is a product team you fund forever against a subscription that includes the roadmap, the support and the release compatibility. Here is what each path pays for over three years, including the lines the original estimate leaves out.
| Cost | In a build | In a package |
|---|---|---|
| Initial build or implementation | 8–16 developer weeks of code for a CPQ with bundles and approvals, and 2–3 quarters to go live once design, testing, fixes and training are counted (our estimate). | A fixed fee where published: Kugamon $15K–$30K by edition, $5K less on a multi-year term (AppExchange). |
| Ongoing maintenance team | Required: at least two people who can read and deploy it. One is a single point of failure. | Not required; any Salesforce admin, with vendor support included. |
| 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. |
| Release compatibility and fixes | Yours: three Salesforce releases a year, gateway API changes and tax-rule changes all land in your backlog. | Inside the subscription. |
| Documentation | Whatever the developer wrote down. | A help center, training and a dated change log (Kugamon’s is public). |
| Knowledge loss | When the builder leaves, the next developer reverse-engineers production. | The vendor’s team and documentation stay when your people move on. |
| Opportunity cost | Developer time spent on billing instead of your own product. | Your developers stay on your product. |
| Exit | Untangling Apex from standard objects; 4–12 weeks to a package. | Managed package uninstall; Product, Price Book, Contract and Asset data stays in standard objects. |
Published pricing. Kugamon publishes its full price list: $65–$125 per user per month depending on edition, support included, a 10-user minimum and a 12-month term. Implementation typically runs ¼–⅓ of annual licensing, so the build-vs-buy math is something you can actually do: see pricing, or put your developer cost into the calculator.
Time to deployment
A build is sequenced: design, build, test, fix, train, then discover the edge cases in production. Kugamon is configured, not coded: 4–8 weeks, admin-led, against a product that already encodes years of edge cases. The revenue team is live two or three quarters earlier (Figure 1).
Administration
A native package is administered by the Salesforce admin you already have, with point-and-click configuration. A build is administered by whoever can read the code, which makes every change a development ticket and every admin dependent on a developer.
Maintenance you can’t defer
Salesforce ships three releases a year. Payment gateways change APIs. Tax rules change. A vendor absorbs all of it inside the subscription. A build absorbs it in your backlog, or doesn’t, and breaks on a schedule you don’t control.
When build is right, and when it isn’t
Build is the right answer when the system is the differentiator and you intend to fund it like a product indefinitely. Revenue operations is almost never that system: nobody wins a customer because their invoice proration logic was home-grown.
| Build makes sense when… | Buy makes sense when… | |
|---|---|---|
| What it is | Your product, or a true competitive differentiator | Critical infrastructure that must simply be correct: billing, subscriptions, revenue |
| Who solves it today | No vendor solves the problem on your platform | A native vendor already solves it on the platform you run, with years of edge cases built in |
| Who owns it | A permanent team you will staff to own, document and evolve it | Your existing admin, with the vendor carrying the roadmap and release compatibility |
| What a defect costs | Little: defects are cheap and visible before they reach a customer | A lot: defects reach customers’ invoices and your financial statements |
| Scope | Narrow, and it will stay narrow | Quote to order, invoice, payment, subscription and renewal, and it will grow |
Other common reasons builds stall: security review and PCI scope land on your team; every Salesforce release is a regression test you run yourself; auditors ask for controls documentation that doesn’t exist; the executive sponsor who approved the build changes roles; the “temporary” spreadsheets beside the system become permanent; and a later migration off the build costs more than buying would have in the first place.
For CPQ alone, four questions decide it (Figure 2).
Buying native keeps what a build promised
The appeal of a build was control: your objects, your data, your admins. Kugamon gives you that without the liability. It runs on Salesforce’s own Product, Price Book, Contract and Asset objects, so your admins extend it with Flow, reports and validation rules exactly as they would a build. Standard packaged functionality, no custom Apex to inherit.
And adds what a build never could
At least one major release a month, with a help center and a public release history. A founder-led US team you can reach. Agentforce-ready native objects and a public AI skills library, kugamon-skills on GitHub. And 150+ companies whose edge cases are already in the product, edge cases your team would otherwise rediscover one at a time.
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–12 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.
For simple quoting — small catalog, one discount field, no subscriptions — yes: standard Quotes and Flow cost nothing per user. Once the system has to handle bundles, approvals, invoices, payments or renewals, a build usually costs more by year two: every pricing change becomes a deployment, someone has to test it against three Salesforce releases a year, and the renewal engine is never finished. Model it in the calculator.
Kugamon’s typical implementation is 4–8 weeks, configured by an admin. Our estimate for a custom CPQ with bundles and approvals is 8–16 developer weeks of code and 2–3 quarters to go live once design, testing, fixes and training are counted. Billing and subscriptions come after that and keep growing.
AI makes writing code cheaper, and code was never the expensive part. It does not decide which proration rule is correct, test amendment scenarios against real invoices, keep a gateway integration PCI-compliant or answer the call when month-end billing fails. AI-generated code still needs an owner, a reviewer, documentation and a maintenance budget.
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–12 weeks: toward the short end 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.
What Salesforce admins say on AppExchange
Quoted verbatim from the Kugamon listing on AppExchange. Reviewer names and dates as published there. Read all 135, including the critical ones →
★★★★★A new bar for RevOps
“As someone who has set up Salesforce CPQ before, I found Kugamon to be much more straightforward and easier to use. It took us just a few weeks to get going, rather than the few months or even years required by other systems.”
★★★★★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.”
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 labeled estimates.