How to build a B2B quoting tool

Most B2B sales still run on a spreadsheet that one person guards with their life. Someone fat-fingers a discount, the margin quietly disappears, and nobody notices until the finance team asks why the deal lost money. A quoting tool fixes that by turning pricing from tribal knowledge into something the whole team can use without breaking it.

What it is and who it is for

A B2B quoting tool (sometimes called CPQ, for Configure, Price, Quote) lets a salesperson build an accurate, branded quote in minutes instead of hours. It takes products, quantities, and discounts, applies your real pricing rules, and produces a document the customer can accept.

It is for companies whose pricing is not a fixed price tag. If you sell tiered subscriptions, volume discounts, custom configurations, or anything that needs sign-off above a certain discount, you are the audience. If your pricing fits on a menu, you do not need this yet.

The one core job it must do well: produce a quote that is correct. Correct price, correct discount, correct totals, correct terms. Everything else (speed, design, integrations) is secondary to the number being right. A pretty quote with the wrong total is worse than no tool at all, because people will trust it.

The MVP feature set

Resist the urge to model every pricing edge case on day one. Ship the spine first.

Build first:

• A product and price catalog (SKUs, list prices, units).
• A quote builder: add line items, set quantity, see live totals.
• A discount engine with guardrails (percent or fixed, with a maximum a rep can apply alone).
• An approval step when a discount crosses a threshold.
• PDF generation with your branding.
• A shareable quote link with accept and decline.
• Basic roles: rep, manager, admin.

Build later:

• CRM sync (HubSpot, Salesforce, Pipedrive).
• E-signature and contract terms.
• Multi-currency and tax logic.
• Quote versioning and renewal quotes.
• Bundles, dependencies, and configurable products.
• Analytics on win rates and discount leakage.

The MVP should let one team replace their spreadsheet. That is the bar. If you are still finding the sales process itself, treat this like any other MVP for a startup and keep the catalog small.

The hard parts

This is where quoting tools eat budgets. Three things consistently get underestimated.

Pricing rules are a real domain, not a form. "Apply a discount" sounds simple until you hit overlapping rules: a customer-tier discount, a volume break, a promotional override, and a manager exception, all on the same line. Which one wins? Do they stack? Rounding alone causes arguments, because a percentage off a per-unit price times quantity can differ by a cent from a percentage off the line total, and finance will notice. You need a clear, ordered evaluation model and a way to show why a price came out the way it did.

Quotes must be immutable once sent. If a customer accepts a quote, the numbers they saw are the numbers you are bound to. But your catalog keeps changing. So a quote cannot just reference live prices. It has to snapshot them. This is the mistake people regret most: they build quotes that read from the current catalog, then a price change silently rewrites quotes that were already sent.

Here is the shape we reach for. Snapshot the price onto the line item at the moment it is added:

create table quotes (
  id            uuid primary key default gen_random_uuid(),
  number        text unique not null,        -- human-facing, e.g. Q-2026-0142
  account_id    uuid not null references accounts(id),
  owner_id      uuid not null references users(id),
  status        text not null default 'draft', -- draft|pending_approval|sent|accepted|declined|expired
  currency      char(3) not null default 'USD',
  valid_until   date,
  created_at    timestamptz not null default now()
);
 
create table quote_line_items (
  id            uuid primary key default gen_random_uuid(),
  quote_id      uuid not null references quotes(id) on delete cascade,
  product_id    uuid not null references products(id),
  description   text not null,               -- snapshot, not a live join
  unit_price    numeric(12,2) not null,      -- snapshot of list price
  quantity      integer not null check (quantity > 0),
  discount_pct  numeric(5,2) not null default 0 check (discount_pct between 0 and 100),
  line_total    numeric(12,2) not null       -- computed and stored at write time
);

Note unit_price and description live on the line item, not as a join to products. The product table can change all it wants; the quote stays frozen. Store money as numeric, never floats, and decide your rounding rule once.

Approvals are a workflow, not a checkbox. A discount over the threshold should route to the right manager, block the quote from being sent until they act, and record who approved what and when. When a deal goes sideways six months later, "who signed off on this 40 percent discount" is a question someone will ask. Build the audit trail from the start.

The stack we would reach for

Nothing exotic. Quoting tools reward boring, reliable choices.

• Next.js and TypeScript for the app. The quote builder is interactive and benefits from a typed end to end model, since a money bug is the whole point of failure here. This is our default for web app development.
• Node API with PostgreSQL. Pricing is relational and transactional, and Postgres gives you the numeric type, constraints, and row-level locking you want when two reps touch the same quote. The pricing engine itself lives in plain, well-tested TypeScript functions, not buried in the database or the UI.
• A real PDF pipeline. Render quotes server-side (a headless browser or a library like React-PDF) so the document matches what the customer saw on screen. Treat the PDF as a generated artifact, not the source of truth.
• Background jobs for PDF rendering, emails, and CRM sync, so a slow third party never blocks a salesperson clicking "send."

When the time comes to wire in CRM, billing, or e-signature, that is a focused API and backend engineering job rather than something to front-load into the MVP.

Rough timeline and cost

These are ranges, not quotes (pun intended). The single biggest variable is how gnarly your pricing rules are.

• Simple pricing (flat tiers, one discount type, one approval level): a usable internal tool in roughly 6 to 10 weeks.
• Moderate (volume breaks, multiple discount types, multi-step approvals, branded PDFs, one CRM integration): roughly 3 to 5 months.
• Complex (configurable products with dependencies, multi-currency and tax, e-signature, deep CRM sync, analytics): 6 months and up, and worth phasing.

A small senior team lands a solid MVP somewhere in the low-to-mid five figures, with moderate builds climbing into the mid five to low six figures. The cost driver is almost never the UI. It is the pricing logic and the integrations. A vague "it depends on the deal" pricing model is the most expensive thing you can hand an engineering team, so the discovery work to pin down your rules pays for itself.

What to watch out for

• Letting reps type free-text prices. The moment a price field accepts anything, your catalog stops meaning anything. Constrain prices to the catalog and discounts to rules.
• No discount ceiling. Without a hard cap and an approval gate, margin leaks one "just this once" at a time. This is the number one reason companies build these tools.
• Live prices on saved quotes. Covered above, but worth repeating because it is silent and ugly. Snapshot everything.
• Floats for money. Use decimals. Pick a rounding rule. Test it.
• Building configurable products too early. Bundles with dependencies are genuinely hard. If most deals are simple line items, ship those and add configuration when a real deal demands it.
• Skipping the audit trail. Adding it later means reconstructing history you no longer have.

Takeaway

A B2B quoting tool succeeds or fails on one thing: the number is right, every time, and you can prove why. Get the pricing engine, the snapshots, and the approval trail solid, keep the catalog and feature set small to start, and you replace a fragile spreadsheet with something your whole sales team can trust.

This is squarely the kind of thing we build, pricing logic, approvals, and all. If you are sketching one out, talk to us and we will help you scope it honestly.