# "Your product configurator should price server-side, not in JavaScript"

Open the devtools on a lot of product configurators, switch to the Network or Sources tab, and you can read the price list. Quantity tiers, wholesale discounts, margin logic, all of it, because the price is computed in the browser.

For a B2C product with one public price, that is fine. For B2B, it is the thing you least want to expose, shipped to every visitor. I build configurators, and server-side pricing is the one architectural decision I treat as non-negotiable for anything with real pricing rules. Here is why, and how to structure it.

## Two failures, not one

Client-side pricing fails in two separate ways.

**Information leak.** Your net prices, volume thresholds and margins are business secrets. If the browser needs them to compute a total, they are in the page, and a competitor or a customer can read them in seconds. No amount of minification fixes this. The data is there because the code needs it there.

**Integrity.** If the browser computes the price, the browser can be told to compute a different one. A user who edits the value before the order is submitted, or replays a crafted request, can send you an order at a price you never offered. If the server trusts the number it receives, you ship at that number.

Minifying the JavaScript hides neither problem. It is security by "probably nobody will look", and in B2B, somebody will.

## How it should work

The browser should send the **configuration**, not the price. The server owns the rules and returns the result.

```
// client: send what the user chose, not what it costs
POST /api/quote
{
  "product": "sliding-gate",
  "options": { "width_mm": 4200, "infill": "horizontal", "color": "RAL7016" },
  "quantity": 12
}

// server: compute from raw config + your rules, return the result
{
  "price": 4860.00,
  "currency": "EUR",
  "lead_time_days": 28,
  "quote_ref": "Q-2026-10-0473"
}
```

The browser receives a number and a reference, never the rule set. Three things follow from this:

1. **Your pricing logic never leaves the server.** Tiers, margins and dependencies stay private.
2. **The order is re-validated on submit.** When the customer confirms, the server recomputes the price from the stored configuration and the quote reference. The client cannot dictate the total.
3. **A price change is a data change, not a deploy.** You update the rules on the server. No frontend rebuild, no cache bust, no risk of a stale price list in someone's bundle.

That third point is the one people underrate. Pricing changes often. Coupling it to a frontend deploy is operational friction you do not need.

## This is also why off-the-shelf configurators struggle here

A lot of plugin and SaaS configurators price in the browser by design, because it is simpler to ship and avoids a backend. That is exactly why they are hard to trust with B2B pricing. When the comparison is "custom vs off-the-shelf", this is one of the quiet reasons custom wins for anything with real rules. I wrote the full build-vs-buy breakdown separately, but server-side pricing is the single clearest technical line between the two.

## When client-side is fine

To be fair to the browser: if the price is public, fixed and the same for everyone, computing it client-side is harmless and faster. A B2C configurator for a single consumer product with a published price does not need a round trip. The rule is simple. The moment the price is **not** the same for everyone, or the rules are **not** public, it belongs on the server.

## FAQ

**Is this not slower, with a round trip per change?**
A quote endpoint responds in tens of milliseconds and you can debounce rapid changes. The user does not notice, and you keep your rules private.

**Can I still show a live-updating price?**
Yes. The UI updates on every change by calling the quote endpoint. The number is live; the logic behind it is not in the page.

**What about the order total being tampered with?**
Re-validate server-side on submit. Recompute from the stored configuration and the quote reference, and reject anything that does not match. Never trust a total that came from the client.

**Does this need a heavy backend?**
No. A single stateless pricing endpoint is enough for most configurators. The rules live in data, not in a sprawling service.

## Build it right

If you sell B2B and your configurator prices in the browser, that is worth fixing. I build custom configurators with server-side pricing as the default. You can see ten of them, clickable with no sign-up, on the [custom 3D configurator page](https://grodev.pl/en/custom-3d-configurator). Tell me what you sell and I will send a fixed quote within 48h. Email: dominik.gronski@grodev.pl

Written by Dominik Groński GroDev, a solo full-stack developer building custom 3D configurators and Laravel back-ends for manufacturers across the EU, UK and US.