The pain and the solution
The pain
- Suppliers send product cards in Excel, and they are retyped onto the marketplace by hand.
- Where an item is right now is found out in Telegram chats: ordered, inspected, in the warehouse or on its way to a pick-up point.
- Buyers put orders together on their own with no suggestions, and procurement buys by gut feeling.
- Work happens in shared spreadsheets and chats, although the marketplace's data is sensitive.
How we solved it
- Supplier Excel files are parsed: product cards are created from the file and linked to the catalogue.
- Every item's route is visible to every role through QR scans, so nobody has to ask where the goods are.
- A recommendation module suggests a basket from similar buyers' orders and gives procurement a demand forecast.
- Role-based rights are designed before any business logic, sensitive fields are encrypted, and the server stands at the client's site.
Recognise your task? We will solve it for you too.
Discuss a similar projectWhat we did
Behind the storefront
The marketplace already has a storefront. We connect to it from the inside and run the catalogue, orders, warehouse, documents and team tasks.
Roles and rights
Director, logistics, storekeepers, procurement, sales, category managers, merchandisers and suppliers. Each sees only their own slice of data.
QR tracking
Every item gets a QR code. Order, incoming inspection, acceptance act, warehouse, pick-up point - each step is marked by a scan.
Recommendations and forecast
Based on orders of similar buyers the system suggests a basket and forecasts demand so procurement can buy ahead.
Documents and accounting
Agency contracts, agent reports three times a month, acts and offers from templates; electronic document exchange and 1C.
Data protection
Multi-factor login, encryption of sensitive fields, protection against bots and brute force, a dedicated server at the client's side.
The project in detail
This project is under NDA, so there is no company name and no industry. The marketplace sells to organisations that have a monthly budget and must report on their purchases. The storefront already works. We were asked to build what sits behind it: the system in which the team runs products, orders, the warehouse, documents and tasks.
Why it is harder than an online shop
At first sight it looks like a mid-sized marketplace. After studying the brief, the supplier guidelines and a long conversation with the owner, it turned out to be a different task: a multi-user system with a dozen roles, a warehouse, tracking of every single item, a recommendation module, document flow, integrations and serious protection. So we offered two honest options: a first working version within the budget and the full system, completed after launch.
Roles and rights from day one
The director sees everything. Logistics, storekeepers, project managers, procurement, sales, category managers and merchandisers each see their own part. Suppliers work in a separate portal. Rights are enforced in the database itself; the screen only shows what is allowed.
Rights are designed before the first line of business logic. Reworking them later is the most expensive change there is, and a new department should be added by configuration, without rebuilding the system.
Warehouse and item tracking
Every item has a QR code that holds only the article number; everything else is in the database. The route is a chain of states: ordered, at incoming inspection, acceptance act received, in the warehouse, on the way to a pick-up point, handed over. Each transition is marked by a scan, so logistics, sales and management see the same picture. The number of pick-up points is set to grow several times over, so this module is built to be split out when the load grows.
Basket recommendations and demand forecast
Buyers resemble each other and their orders repeat month after month. The recommendation module looks at what similar organisations bought and offers a ready basket within the budget. The buyer closes the purchase faster and is more likely to stay on the marketplace. Procurement uses the same data as a demand forecast and buys in advance. In the first version the module calculates and learns; automatic basket building comes in the next stage.
Documents and integrations
Agency contracts with suppliers, agent reports three times a month, acceptance acts and offers are generated from templates and sent through electronic document exchange. Accounting exchanges data with 1C. Product cards are created from suppliers’ Excel files. Legal reference databases are connected for checking contracts.
Telegram stays where people are used to it: a bot and a mini app send notifications and take simple actions, while data and processes live in the system. This moves work out of chats without breaking people’s habits.
A task planner of its own
A team of 20-50 people assigns tasks with deadlines, delegation and a Gantt chart. A ready-made cloud planner did not fit: everything has to run in a closed environment on the client’s server. So tasks are built into the system itself, borrowing the familiar patterns of large planners.
Protection
Login with a password, a second factor, a Telegram account and an allow-list of addresses. Sensitive fields are encrypted with separate keys, bots and brute force are blocked at the edge, and every action is logged. A separate layer of decoy data raises an alarm if someone reaches it. Data the marketplace does not need for its work is not stored at all, which beats any protection.
How we build it
It is a modular monolith: one system with clear module boundaries. At this scale separate microservices would add complexity and points of failure in a closed environment without any gain. The order of work was chosen by the client: catalogue, roles and the storefront link first, then item tracking and QR codes, then recommendations and the bot, and in the next stage documents, 1C and a mobile app.
Who else this fits
B2B marketplaces and distributors with a large catalogue, their own warehouse and a network of pick-up points; companies where several departments handle the same goods and each needs its own view; anyone running processes in Excel and Telegram who has hit the ceiling.
Discuss a similar project
Tell us about your task, and we will suggest how to build something like this for you.
- 01Analysis
We study processes, data and the points where value is lost, and fix the result we are working towards.
- 02Architecture and prototype
We design the system and build the first version on your real data. Stages and cost are agreed before work begins.
- 03Pilot
We launch in one area. Every stage is checked in a test version before it goes into operation.
- 04Scale and support
We connect the remaining areas, take responsibility for how the system runs and keep developing it.

