On a consumer site, price is the easiest part of the problem. One product, one price, the same for everyone who opens the page — a stranger in another country sees the same number you do. A developer new to B2B work tends to carry that assumption straight into their first wholesale project, and it breaks almost immediately.
I watched this happen with someone early in their career who was handed the job of building "the customer portal" for a wholesale operation. He built a clean product catalog, a cart, a checkout — a normal store, basically, done well. Then he showed it to the client, who looked at it for about thirty seconds and asked: "where does it show that this customer gets 12 percent off, and this other one gets a different rate because of last year's volume?" There was no clean answer, because the entire structure assumed one price existed per item. In a real B2B operation, that assumption is simply false.
One item, several true prices
In wholesale, the same part number can have a different price for every customer, and all of those prices are correct at the same time. One customer negotiated a flat discount years ago that's still honored. Another gets a lower rate once they cross a volume threshold each quarter. A third is mid-negotiation on a new rate that takes effect next month but not yet. None of this is an edge case to handle later — it's the normal shape of B2B pricing, and a portal that doesn't account for it from the start isn't a smaller version of the real thing. It's the wrong thing.
This is also why "just build a webstore" undersells what a portal actually requires. A webstore assumes a catalog and a cart are most of the work. In B2B, the catalog and the cart are almost the easy part. The pricing logic underneath them — who sees what price, how it changes over time, and how to honor a rate someone agreed to six months ago even after the general price list has moved — is where the real engineering is.
The quieter complexities arrive bundled with the pricing problem
Once pricing is handled properly, three more things show up right behind it, and all three are easy to underestimate from the outside.
The first is staying in sync. A portal showing stock and prices is only useful if those numbers match what's actually true in the systems that already run the business — inventory, billing, whatever your team already relies on. A portal that drifts out of sync with reality is worse than no portal, because it actively misleads customers instead of just failing to help them.
The second is permissions inside a single customer. A business customer usually isn't one person — it's a company with several employees who need different levels of access. The person placing routine orders shouldn't necessarily see the company's full payment history. The finance contact who needs invoices might not be the person who should be able to change shipping addresses. Role-based access inside each customer account is not a nice-to-have add-on; it's part of what "a company, not a person, is using this" actually means in practice.
The third is volume that grows. A portal built to comfortably handle today's traffic and today's catalog size will start to strain the moment either one grows past what it was built for — and for a business doing its job well, both will grow. Building for today's numbers only is a bet that the business won't succeed, which is a strange bet for anyone to make on purpose.
Design for it, don't patch it in later
None of this needs to be solved all at once, and none of it needs to be perfect on day one. What it does need is to be designed for from the start — the data model that assumes per-customer pricing from the first line of code, not retrofitted after the fact; the permission structure that assumes a company with roles, not a single login. Patching these in after a portal is already live is far more expensive than building them in from the beginning, because by then real customer data and real workflows depend on the simpler assumption you're trying to undo.
This is exactly why I run a short, fixed-price discovery phase before committing to a full build — about a week, with a clear scope, a working prototype, and a real estimate at the end of it. It's enough time to map out exactly how a client's pricing actually works, what systems the portal needs to stay in sync with, and who needs to see what inside each customer account, before any of those assumptions get baked into code that's expensive to unwind. I also build with AI-assisted development where it genuinely speeds things up, which shortens that timeline further, but every line still gets reviewed and tested the same way it always has.
It's not one price tag. It's a pricing system.
The gap between "a webstore" and "a B2B portal" isn't features — it's this one assumption, sitting underneath everything else. Once you accept that every customer might see a different number for the same item, and design around that from the start, the rest of the complexity — sync, permissions, scale — has somewhere sensible to live. Skip that step, and you end up rebuilding the foundation after customers are already relying on it.