Do you need CPQ? Build, buy, or use what you already have

6 minutes. One coffee should do it.

A lot of teams asking whether they need CPQ software don't have a missing tool problem. They have tools they already own that aren't joined up, so check what's already in the building before you choose between building and buying.

Build or buy sounds like a two-option question, but it has three real answers, and nobody sells you the third one.

What does CPQ actually solve?

CPQ stands for configure, price, quote, and it's sold against a very familiar mess: quoting that's slow, manual and full of handoffs. A salesperson works out the package, someone checks the price, a quote goes out, and somewhere in there the deal goes quiet.

That was the picture at Properti. Sales was quoting customers manually, and the sequence went spreadsheet, email, follow-up, follow-up again, eventually a payment link, eventually a signed agreement, eventually an onboarded customer. Every step was a handoff, and every handoff was a place where a deal could stall.

So the problem CPQ promises to fix is real. I'm not arguing it isn't. The question worth asking is whether the fix has to be a new product, or whether the pieces are already sitting in your stack waiting for someone to connect them.

Why is "build or buy" missing an option?

It's missing an option because the useful framing is build, buy, or use better what you already have. Most internal tooling decisions get set up as build vs buy, and that third option quietly drops off the list.

It drops off for boring reasons. It isn't exciting, there's no launch, and nobody sells it to you. No vendor is going to book a demo to tell you your CRM is fine and you just need to use it properly. In my experience it's the right answer more often than the other two.

The way I'd put it: most internal tooling problems at established companies are not tooling shortage problems. They're tooling under-utilisation problems. Working out which one you've got is judgement work, not procurement work, and you don't get there by reading G2 reviews. You get there by understanding what's already in the stack, why it's there and what it could do if someone actually invested the time.

I've seen the same diagnose-first pattern play out elsewhere at Properti, when a pile of project boards turned into a data audit rather than another tool.

What did not buying CPQ look like at Properti?

It looked like a quote-to-pay flow built on the Stripe and HubSpot setup Properti already had, with no new vendor added. The full write-up is in the Properti quoting case study, but here's the shape of it.

The obvious move was to evaluate CPQ vendors. Buy PandaDoc or DocuSign, problem solved in a quarter. Salesforce CPQ and GetAccept were on the usual list too. The market is full of products promising to sort out quote to cash.

Instead I looked at what was already in the building. Stripe and HubSpot had been core to Properti for five years, and both were already wired into billing, the deal pipeline, customer records and finance reporting. Both were also being underused. Adding a third vendor wasn't the move. Making the two already there do the work properly was.

So I built three layers, tied together with a quoting interface I designed and built myself:

1. 1.A quote builder. Sales could configure a Properti package, apply discounts, set terms and produce a customer-facing quote in under five minutes. It pulled product, pricing and customer data straight from HubSpot and pushed the quote back to the deal.
2. 2.Document generation. Branded PDF quotes matching Properti's design language, attached to the HubSpot deal record automatically and emailed to the customer with a tracked link.
3. 3.Payment and acceptance. Stripe Checkout linked from the quote. The customer accepted the terms and paid, the HubSpot deal moved to Won, the customer record updated and onboarding kicked off, with no human involvement past the initial send.

What changed: the end-to-end system went into production, at least four manual steps came out, and there was no new vendor, no retraining and no data migration. The CFO didn't have to learn a new tool, and the sales team didn't have to retrain. The decision itself is written up as Not buying CPQ.

What cost does a vendor demo leave out?

It leaves out the integration cost, which stays invisible right up until you pay it. The pitch never includes it. The implementation always does.

At Properti, adding a new SaaS to a five-year-old operation would have meant migrating customer data, retraining the sales team, rebuilding finance reports and building two new integration layers, one from the CPQ tool to HubSpot and one from the CPQ tool to Stripe. That's a lot of work before anyone sends a single quote.

There's a quieter cost too. Every customer, deal and stage already lived in HubSpot, so pulling that data into a CPQ tool to generate a quote, then pushing the result back, is a synchronisation problem nobody actually wants. Stripe was already the payment system of record. Customers already paid through it, subscriptions already lived there, and the CFO already trusted its reporting. Trust in finance reporting takes years to build, and it's not something I'd swap out lightly.

Then there's the people side. Five years of institutional knowledge should be respected, not bypassed. People knew how HubSpot and Stripe worked, and a new tool means new training, new errors and a fresh round of "how do I do that again" moments.

How can you tell if you actually need CPQ?

You can tell by working out whether you're missing a capability or just missing the connections between tools you already pay for. These are the questions I'd run through before booking a single demo:

1. 1.Where does your customer and deal data already live? If it's already in your CRM, a new tool mostly adds a place to sync it to.
2. 2.What's your payment system of record, and does finance trust it? If the answer is yes, think hard before putting something new between a quote and that system.
3. 3.Is the problem a missing capability, or tools that aren't connected? Manual handoffs between systems you already own are usually a wiring job, not a shopping trip.
4. 4.What would a new tool cost in migration, retraining and rebuilt reports, not just licences? Price the implementation, not the subscription.
5. 5.Is your pricing genuinely beyond what your current tools can express? If the honest answer is yes, that's a real gap, and it points towards buying.

If you get to the end and the only gap is that nobody has joined the dots, you probably don't need CPQ. You need someone to own the joining.

When should you buy CPQ?

You should buy when there's a real capability gap, no one to own a build, or pricing your current stack can't handle. Strong opinions, loosely held, and I'd rather make the best case for buying than pretend it doesn't exist.

The first one is the obvious one. If your products, packages or approval paths are complex enough that your existing tools can't represent them properly, forcing it is false economy. Buy the thing built for the job.

The second is ownership. What worked at Properti worked because someone could design, build and own the flow end to end. If nobody on your team can do that, or nobody will maintain it once it's live, a vendor's product with a vendor's support behind it might be the more responsible call.

The third is when your current tools aren't actually load-bearing. The argument for staying put leans on years of data, trust and habit already sitting in the stack. If that isn't there, the integration cost argument gets a lot weaker.

None of this makes CPQ bad. The point is the diagnosis, not the product category. Some teams genuinely need it. Plenty just need to use what they've got.

Anyway. The tool you already own won't wire itself together either.

Common questions about CPQ

Do you need CPQ software?

Often not. If your quoting problem comes from tools you already own not being connected, better use of those tools can fix it without a new vendor. Buy CPQ when there's a genuine capability gap.

What's the alternative to buying CPQ?

The alternative is to make better use of the tools you already have. At Properti that meant building a quote-to-pay flow on the existing Stripe and HubSpot setup instead of adding a third vendor.

Can HubSpot and Stripe handle quote to cash without a CPQ tool?

At Properti they did, with a custom quoting interface on top. Quotes pulled data from HubSpot, branded PDFs were attached to the deal, and Stripe Checkout handled payment, with the deal moving to Won and onboarding triggered on payment.

What's the hidden cost of buying CPQ?

The hidden cost is integration: migrating customer data, retraining the sales team, rebuilding finance reports and building new integration layers to your CRM and payment system. The vendor pitch rarely includes it.

When is buying CPQ the right call?

Buying is the right call when your pricing or configuration is beyond what your current tools can express, when nobody can own a build, or when your existing stack isn't trusted or embedded enough to be worth building on.

Facing the same build or buy call?

If you want the short version, the decision is on Not buying CPQ, and the full build is in the Properti quoting case study. If your team is about to start evaluating CPQ vendors and you'd like a second opinion on whether you need one, get in touch.