Online shops and B2B portals, built to hold
Online shops and B2B portals with complex catalogues: prices by volume and date, accounting integration, server-side rendering. Case: 5000+ SKUs at Plantpol.
Case study: Plantpol
One of the largest agri-technology distributors in Ukraine. We built a B2B portal with 1C integration that automated work across 5000+ SKUand cut the manager headcount by75%(from 20 people down to 5).
A complex catalogue is not just “more products”
A shop with a thousand items and a B2B portal with five thousand are different problems, and they break in different places. In B2B a price is rarely a single number: it depends on volume, on delivery date, on the specific customer and their contract. A catalogue built as “product — price” simply does not hold up.
At Plantpol the price is calculated per pallet and per shipping date — a plant collected in March does not cost the same as the identical plant in May. That is not a quirk: it follows the growing cycle. The catalogue had to show a manager and a customer different numbers for the same product without lying to either.
The second half of the same problem is accounting. While the catalogue and the books live apart, somebody moves stock levels by hand every day — and that is exactly where selling things you do not have comes from. Integration with the accounting system is not an optional extra; it is the condition that makes the rest meaningful.
What we actually build
A catalogue that survives complex rules
Prices by volume, date, customer and contract. Filters that stay fast across five thousand items. Search that understands what people actually call a product, not only how it is written on the card.
Two-way link with your accounting
Stock, prices, orders and statuses move between the shop and the accounting system on their own. Nobody retypes figures, so there is nowhere to get them wrong.
Pages search engines can actually see
Server-side rendering so a crawler sees the product without running JavaScript. Schema.org markup for products and categories. Speed treated as part of the build, not as a separate service “later”.
Payments and documents
Payment gateways, invoices, delivery notes, fiscal receipts. The same standard as in the self-service terminals: the money has to add up to the last coin, or nothing else matters.
The stack, and why this one
The storefront runs on Angular or React with server-side rendering. The reason is plain: without it a crawler sees an empty page, and half the search engines — plus every AI bot — do not execute JavaScript. For a shop that means the products do not exist for them.
The backend is Laravel or Node.js, depending on what the client already runs. We do not rewrite a working system for the sake of a tidier stack: connecting to it is cheaper and safer than replacing something that earns money today.
PostgreSQL or MySQL underneath. Queues for everything that must not block the buyer: emails, exports, accounting sync. Monitoring from day one, because a shop that went down overnight and told nobody costs more than any monitoring ever will.
Answers on this topic
Plain explanations without marketing — useful even if you never hire us.
Replacing 1C: what to migrate first
The order of migration away from 1C: where to start, what can stay for years, how to avoid stopping the business mid-transition, and where data goes missing.
Automating invoices, contracts and delivery notes
Why salespeople lose hours to paperwork and what to automate first. A worked example: 196 documents generated by the system with no manual typing.
Custom system or an off-the-shelf box: an honest comparison
When a boxed product wins, when custom wins, and the third option: a working system adapted to your process. Lock-in, code ownership, support, migration risk.