Wholesale and distribution
Wholesale & Distribution Software Design
Ordering platforms and buyer portals for distributors, where the competition is a chat thread at nine at night.
The problem
What this software has to survive
Distribution is not complicated because the software is bad. It is complicated because the trade is, and the design has to hold all of it.
Layered pricing
List price, customer tier, promotional price, and the one account with an arrangement that predates the software.
Orders from everywhere
Chat threads, phone calls, a field agent’s notebook, a buyer’s handwritten list.
Stock that is never simple
Consignment, reservations, partial availability, two warehouses on one order.
Payment reality
Cash on delivery, terms, part payments, post-dated cheques, collection day.
Geographic fulfilment
Routes, delivery windows, restricted hours, provincial runs that take days.
Users who are fast
Someone entering two hundred orders a day has a keyboard path. A prettier screen that is slower is a downgrade.
Where the work is
Four screens decide adoption.
The rest is detail.
Get order entry wrong and nothing
downstream rescues the project.
Four screens / one workflow at a time
Screen / 01
Order entry. The screen that decides everything. Repeat orders, product lookup by whatever the buyer calls it, quantities in the units they actually use, and a running total they trust.
Screen / 02
The buyer portal. Used by a store owner on a phone, at night, on a poor connection, without training. Design for that, not for a desk.
Screen / 03
The back office. Order management, exceptions, credit and returns, where the operations team lives all day.
Screen / 04
The exceptions. Short deliveries, price disputes, returns. These decide whether staff trust the system enough to stop keeping a parallel spreadsheet.
The one screen that matters
Order entry decides adoption
Everything else in a distribution platform can be adequate. If order entry is slower than sending a message, buyers keep sending messages and the software becomes a place where someone retypes them.
So it gets designed first and measured hardest:
- Repeat the last order in one action, because most orders are near-repeats
- Product lookup by whatever the buyer calls it, not the catalogue name
- Quantities in the units they actually order in: cases, sacks, dozens
- A running total they trust before they commit
What it costs
Ranges
One workflow: ordering, fulfilment or returns$3,000 to $8,000
Buyer portal and back office$10,000 to $30,000
Design plus front-end buildAdd 40 to 60%
Typical timeline, one workflow3 to 5 weeks
Discovery starts with watching how orders arrive today, whatever the channel. Those workarounds are the requirements.
Common questions
Before you get in touch
What is a B2B ordering portal?
The screen a buyer uses to place a repeat order without phoning anyone: product lookup by whatever they call the item, quantities in the units they actually use, their own pricing, and a running total they trust. Everything else in a distribution platform exists to serve that screen.
How much does distribution software design cost?
One workflow, whether ordering, fulfilment or returns, is $3,000 to $8,000. A buyer portal plus the back office behind it is $10,000 to $30,000. Design with the front-end build adds roughly 40 to 60 percent. Rate detail is in what a UI/UX designer costs.
How long does a buyer portal take to design?
Three to five weeks for the ordering workflow itself, longer once the back office and the exceptions are in scope. Sequencing matters more than speed here: shipping order entry first and running it beside the existing channel beats launching everything at once.
Our buyers order by chat. Will they use a portal?
Only if it is faster for them than the chat, which is a design problem rather than a training problem. Repeat ordering, memory of the last order, and no login friction are what move it. Expect to run both channels for a while and measure the split.
Should buyers get a mobile app or a mobile web portal?
Web first, almost always. A store owner ordering at nine at night will not install an app for one supplier, and an app puts a release cycle in front of every fix. Build the mobile web experience properly, then revisit the app once you know the portal is used daily.
Do you work with our ERP or inventory system?
Yes, and it means an early conversation about what your data can and cannot express. Designing a screen the back end cannot serve is the most common waste in this category.
Do you know Philippine distribution specifically?
Yes, it is the market I work in day to day: sari-sari stores and mini marts as buyers, cash on delivery and terms, provincial routes. The same patterns hold across Southeast Asia.
Can you help before we have built anything?
That is the best time. Designing the ordering flow before it is built is far cheaper than discovering in month six that the pricing model cannot express what sales promised.
The thinking behind it
Judgement, in writing
Tell me how orders reach you today, and where they go wrong.
That conversation usually locates the problem faster than a feature list does.