Challenge
The producer's wholesale customers sent orders through different channels: the website and messaging apps. Each order then went through a long chain: review, picking, reconciliation, documents and payment tracking.
The hardest part of this process is weight. Meat products are picked with an actual weight that differs from the ordered weight, so the invoice amount changes after the order has been picked. This has to be reflected in the documents and in the account balance with the customer.
Customer structure was a separate challenge. A single wholesale buyer can have several delivery locations, several logins for its staff and several legal entities that invoices are issued to. The usual "one customer, one account" model does not work here.
Customers also needed their own portal to browse the catalog, place orders, and see their invoice, finances and current balance due 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 Hurtom on top of the marketplace CRM we had previously developed for the same producer. 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 work session, in about 3 hours.
CRM for the team (19 screens)
- orders with invoices and processing stages;
- customers with delivery locations, multiple logins and multiple legal entities;
- products, prices and promotions;
- analytics, integrations, users;
- admin, manager and operator roles.
Wholesale customer portal (9 screens)
Catalog, cart, orders, invoice, finances and balance due, profile. The portal has no database of its own and works only through the CRM API, so the data is always the same everywhere.
Security
- the login token is tied to the password version: after a password reset, all sessions end immediately;
- password brute-force limits by login and by IP address;
- data is stored in a private schema that is not accessible through the public API, with access only through server-side functions;
- a daily backup at 1:30 AM, with the 30 most recent snapshots retained.
Results
In October 2026, the producer got 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 across messaging apps, and the invoice, actual weight, documents and balance due are visible on a single card.
What this means for the business:
- customers see their own orders, invoices and outstanding balance;
- managers work with the customer's entire structure: locations, 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 sync with 1C (BAF), so that documents and account balances are not duplicated in the accounting system.
What makes this project special
The key feature is speed without compromising quality. The first version was ready 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 every next product built on the shared foundation costs less time.
The second feature is a customer portal without its own database. All data goes through the CRM API, so there is no risk of the portal and the manager seeing different numbers. And the private data schema plus sessions tied to the password version close the typical weak spots of customer portals.
Published: · Updated: