Challenge
The company's wholesale customers sent orders through different routes: via the website and via messengers. Each order then went through a long chain: checking, picking, reconciliation, documents and payment control.
The hardest part of this process is weight. Products sold by weight are picked at their actual weight, which differs from the ordered amount, so the invoice total changes after the order has been assembled. This has to be reflected in the documents and in settlements with the customer.
Customer structure was a separate challenge. One wholesale buyer can have several delivery points, several logins for their staff and several legal entities that receive invoices. The usual "one customer, one account" model does not work here.
Customers also needed their own portal: browse the catalogue, place an order, see the invoice, finances and current balance without calling a manager. Since the portal handles financial data, the requirements for login security and data storage were high.
What we did
We built the system on top of the marketplace CRM we had previously developed for the same company. The same stack (Next.js 16, React 19, Tailwind CSS v4, Supabase, Vercel), ready-made notifications, roles and stage logic meant we did not have to start from scratch. That is why we assembled the first working version with all modules, a mobile version and the customer portal in a single overnight session of about 3 hours.
CRM for the team (19 screens)
- orders with invoices and processing stages;
- customers with delivery points, multiple logins and multiple legal entities;
- products, prices and promotions;
- analytics, integrations, users;
- administrator, manager and operator roles.
Wholesale customer portal (9 screens)
Catalogue, cart, orders, invoice, finances and balance, profile. The portal has no database of its own and works only through the CRM API, so the data is always the same in both places.
Security
- the login token is tied to the password version: after a password reset, all sessions end immediately;
- rate limits on password guessing by login and by IP address;
- data lives in a private schema that is not exposed through the public API, with access only via server-side functions;
- daily backup at 01:30, with the last 30 snapshots retained.
Results
In October 2026 the company received two connected systems: a 19-screen CRM for the team and a 9-screen portal for wholesale customers. Orders from the website no longer get lost between messengers, and the invoice, actual weight, documents and balance are visible on one card.
What this gives the business:
- customers see their own orders, invoices and outstanding balance;
- managers work with the customer's full structure: delivery points, logins, legal entities;
- prices and promotions are configured in one place;
- data is protected at the architecture level, not just by a password.
The next stage we are planning is synchronisation with 1C (BAF), so that documents and settlements are not duplicated in the accounting system.
What makes the project different
The key feature is speed without loss of quality. The first version appeared in about 3 hours not because we simplified the task, but because we reused proven parts of the previous CRM: roles, notifications, stages. For the business this means that every new product built on the shared foundation comes faster.
The second feature is a customer portal without its own database. All data passes through the CRM API, so there is no risk of the portal and the manager seeing different numbers. A private data schema and sessions tied to the password version close the typical weak spots of customer portals.
Published: · Updated: