BaseLinker is often the first serious system that enters a growing store. And for a long time it does exactly what is expected of it. The problem shows up later, usually without warning: the company is still selling, but every change in the process requires another rule, another exception and another person who remembers why it was set up this way in the first place. In the projects we run from the vendor side, this moment has very specific technical symptoms. Better to recognize them early than in November.
Table of contents
What BaseLinker does well and where its role ends
As an operational layer the panel is genuinely good: it pulls orders from marketplaces, talks to couriers, issues invoices, keeps an eye on stock levels. For most stores that is enough for years and there is no reason to build anything custom.
The limit sits somewhere other than people usually assume. It is not about company size. It is about the moment when business logic stops being configuration and becomes code. A pricing rule that depends on a contractor’s margin, validation of a B2B order against a credit limit, assembling bundles from components: none of that can be sensibly described with actions in a panel.
That is also when the way you think about the tool changes. BaseLinker integration stops being the whole solution and becomes one element of the architecture. An important one, but not the one that makes the decisions. A standard WooCommerce integration with BaseLinker handles the flow of orders and stock levels, but it is not responsible for rules specific to your company.
Warning signs: when the panel stops keeping up with the company
The symptoms repeat themselves and are visible faster from the outside than from within. If you recognize more than two of them, it is usually not a matter of team discipline, but the ceiling of the tool:
- automated actions have grown into a state nobody can reproduce or explain to a new hire,
- after every sync somebody applies manual corrections so that the data adds up,
- the ERP and the panel show different stock levels, and the matter gets settled over the phone,
- a key part of the process lives in a spreadsheet next to the system, not in the system,
- during a complaint there is no way to establish who changed the order status and when,
- API limits block work at exactly the moment sales are at their highest.
There is one diagnostic question: does the problem disappear once you add another rule, or does it come back two weeks later somewhere else? The second case means you are patching a symptom. The cause sits in the architecture.
API limits and volume: the hard wall you only see at peak
Most integrations poll the API in a loop, because that is the fastest way to get them running. The cost of that approach grows linearly with the number of orders in the system, not with the number of actual changes. In a quiet month it looks perfectly innocent.
Seasonality is the most honest architecture test in this industry. A flow that flies along in March can grind to a halt in November, because the queue grows faster than the integration manages to process it. And that is when the absence of three things comes out: queuing, exponential backoff on errors and idempotency. Without them a repeated operation creates a second order or a second shipment, and the customer gets two parcels for one order. It shows up fastest where a store integration with Allegro is added and marketplace volume piles on top of your own traffic.
Reporting is a separate matter. An operational panel is not a data warehouse and does not keep history forever. Do you need year-over-year analysis? The data has to land somewhere else.
When you need your own middle layer
Middleware is the place that holds mappings, pricing rules, validations and everything else specific to one particular company. Code can be tested, versioned and rolled back. Unlike a set of actions clicked together in a panel by someone who no longer works here. This is where ordinary custom software development begins, with a repository, tests and a rollout process.
The architectural decision sounds different than many people expect: the integration layer does not replace BaseLinker, it only takes away its responsibility for logic. The panel still talks to marketplaces and couriers. But it no longer decides what counts as a valid order.
When sales run through several channels at once, you need your own source of truth for the catalog and stock levels. Plus logs and event tracking, so that a month later you can reconstruct exactly what happened to order number X. The same discipline is required by every API integration that has to be maintained for years afterwards.
Security, access and what companies remember too late
An API token circulating through emails and spreadsheets is a standard we see regularly. Usually one token, shared by all integrations, so it cannot be revoked without stopping half the company.
Separating permissions and rotating keys should be part of the project from the start, not a fix after an incident. A separate key per integration means that when a subcontractor leaves you cut off one access path, not all of them. It is also worth knowing where the personal data of customers flowing through the integrations actually lands and how long it stays there. Addresses and phone numbers can sit in logs far longer than anyone assumed.
A test environment tends to be treated as a luxury. Until an experiment on production ends with parcels sent to the wrong addresses. Cleaning up a situation like that always costs more than avoiding it.
Cost structure: what really drives the bill
The biggest budgeting mistake is counting the rollout instead of the maintenance. Marketplaces change their APIs, new invoice formats appear, more couriers show up with requirements of their own. And so it goes through the entire life cycle of the system.
The second cost is hidden on the operations side: the hours people spend manually patching what the system cannot handle. It does not show up on any invoice, but it grows along with volume.
Four things drive the bill: the number of sales channels, the number of exceptions in the process, order volume, and accounting requirements together with returns handling. The decision criterion is simple. As long as the exceptions can be described with rules, expanding the panel wins. Once they have to be described with conditions that depend on one another, your own layer comes out cheaper, because maintaining chaos costs more than putting it in order.
How to make the change without stopping sales
Migration goes in stages: first one channel or one process, then the rest. The “everything at once over the weekend” approach ends with nobody knowing on Monday whether the orders are off because of a mapping error or because of something else entirely.
The old and the new flow should run in parallel for a while, with the results compared, before anything gets switched off. Discrepancies then surface calmly, not in customer complaints. Before the start you have to write down status mappings, exceptions, pricing rules and the edge cases of complaint handling. This is the most commonly skipped stage, and it is exactly where the knowledge that exists in no documentation sits.
The typical mistake? Rewriting the existing mess one to one. Migration is the only moment when tidying up the process costs nothing extra, because you are touching every element anyway. The same principle applies to broader system modernization.
Summary
BaseLinker stops being enough not when the company grows, but when its processes no longer fit into the rules of the panel. That distinction matters, because the first case is solved by a higher plan and the second one is not.
A good decision rarely means replacing everything. Usually it is enough to add a layer that takes over the logic and leaves the panel what it is genuinely good at: the operational handling of orders, couriers and documents.
Do you see several of the symptoms described above in your own setup? We would be glad to look at it from the technical side. We run integration audits, design middle layers, automations and modernizations of sales systems, so write to us and we will start with a conversation about where exactly the process falls apart.
