Cheap Allegro to Subiekt integration: count three prices

A cheap Allegro to Subiekt integration is not the one with the lowest subscription, but the one with the lowest bill after three years. That bill has three line items: the entry price, the monthly price and the exit price, and most offers show you only one of them. Below I break three roads down into those three prices: a subscription integrator, an implementation built by us, and custom code at a software house. I also show where the Sfera licence lands in the budget, and give you the threshold: under my assumptions the subscription stops being the cheapest at around 650 orders a month.

Every amount in this post is an assumption to swap for your own. I am not quoting anybody's price list, ours included, because the price of an implementation depends on the number of accounts and document types, which is why we only state it after the audit. The model is simple enough to redo on your own numbers in fifteen minutes, and the comparison tool in the middle of the post does it instantly. If you have not yet worked out what re-typing orders by hand costs you, start with the post on the cost of handling Allegro manually: that number is the reference point for all three roads.

What a cheap Allegro integration means: three prices, not one

When somebody asks us about a cheap integration, they almost always mean the monthly price. That is the least dangerous of the three, because it is visible on an invoice. The other two show up later.

• The entry price. Configuration, a document map agreed with accounting, product mapping, tests on a copy of the database. On a subscription this is usually a one-off setup fee or your IT person's time. With custom code it is the main line item of the whole project.
• The monthly price. A subscription that grows with the number of orders, the size of the catalogue and the number of Allegro accounts, or technical support that grows with nothing. On top of that, in both cases, the cost of handling exceptions by hand: the orders that did not go through on their own.
• The exit price. What stays in the company once you stop paying. With a subscription the configuration and the mapping history stay in the vendor's panel, and the integration stops working overnight. With your own code the code and the database remain, so the next contractor has something to start from.

The cheap road is the one with the lowest sum of those three items over the horizon you actually work with. Nobody replaces their order integration every six months, so counting the first month alone makes no sense. I count over three years, and that is the default horizon in the comparison tool.

The three numbers this calculation comes down to, under my assumptions:

orders/mo: break-even point

650

subscription/yr, 500 orders/mo

PLN 5,290

our build, 1,500 orders, 2 accounts

PLN 7,700

Three options and what each costs per year

Let me start with what each option contains and which amounts I am plugging in. These are assumptions, not a price list: yours will be different, but the structure of the calculation stays the same.

A subscription integrator. An off-the-shelf tool that pulls orders from Allegro and creates documents in Subiekt following the vendor's schema. I assume PLN 299 a month up to 500 orders and 2,000 items in the catalogue, plus PLN 99 for every further 250 orders started, plus PLN 100 for every further 2,000 SKUs, plus PLN 150 for each extra Allegro account. PLN 1,500 of setup at the start. That shape of pricing, growing with volume and catalogue, is what we see most often with subscription tools; check your own price list, because the tiers differ between vendors.

An implementation built by us. An integration through Sfera written for your process and paid for once: for this calculation I take PLN 12,000 one-off for orders and invoices on a single account, and PLN 1,200 for each further account with its own document series and warehouse. Technical support at PLN 200 a month is an option, not a condition of it working. I take that PLN 12,000 deliberately from the top of the range, above the typical quote in the post on the cost of automation, so that the result does not land on our side simply because I plugged in a convenient number. Our actual figure comes after the audit and is fixed, because it depends on the number of accounts, the document types and the exceptions in your process.

Custom code at a software house. The same scope, only with a management layer on top. I take PLN 20,000 one-off and PLN 4,000 per extra account, plus maintenance at 10 percent of the implementation price a year. The PLN 20,000 order of magnitude comes from the quotes clients show us during consultations; I wrote them up in the post on how much process automation costs.

Every road carries one more item that appears in no offer: handling by hand the orders that did not go through on their own. I assume this affects 4 percent of orders on a subscription and 1 percent with an integration written for the process, and that one such order eats 6 minutes at a fully loaded cost of PLN 50 an hour. That difference in percentages is the heart of the matter: an off-the-shelf schema does not know your exceptions, while code written for your process can be taught them.

In the first row the subscription wins and there is nothing to discuss: at 150 orders a month custom code is money that will not come back. In the second the gap is already small, and the decision is made by what the table does not show: how many exceptions you have and whether you want the code on your side. In the third the subscription costs twice what the implementation does, because you pay there for volume, catalogue and a second account, while the price of code does not grow just because you sell more.

The horizon changes the result more than anything else. Over one year the threshold moves to around 1,800 orders a month, because the entire entry price falls on twelve months. Over five years it drops to around 550 orders. That is not an accounting trick, it is the reason it pays to know how many years you are planning for: order integration is infrastructure, not a campaign.

The Sfera licence and Subiekt updates in the budget

There is one item in this calculation that you usually learn about after signing, and it appears in none of the three columns. Subiekt nexo has no public web API: the way in is Sfera, InsERT's set of libraries available in the nexo PRO edition. If you run nexo without PRO, the licence has to be upgraded before any integration at all. I am not quoting a price, because it is not ours and it changes with the vendor's price list: check it with InsERT or with the partner handling your licence.

The second item from the same family is the seat. The integration logs into Subiekt like a user, so it occupies a session. If nobody counts that before the implementation, on Monday morning someone in the office cannot log in. The third is updates: Sfera changes along with Subiekt, so after every major update somebody has to check compatibility and fix the code if needed. On a subscription the vendor does that within the fee; with your own code you plan it with the contractor. None of these three items depends on which road you pick, and that is exactly why they drop out of the comparison so easily.

Where a subscription breaks: exceptions, custom fields, limits

A subscription is cheap as long as your process fits inside the configurator. It breaks not at the moment it stops working, but at the moment somebody in the office starts working by hand alongside it. The places where we see this most often:

• Unusual documents. An invoice issued against a receipt, an order merged from two transactions, a prepayment from another channel, a company with no tax number. Each such case normally ends in a manual fix after the fact.
• Custom fields and series. The Allegro order number in the notes field, a separate series for the marketplace, a warehouse that depends on the account. An off-the-shelf tool either lets you set that up or it does not, and that answer is not negotiable.
• Cross-border sales. Once you pass the EU threshold you settle VAT at the buyer's country rate. If the tool does not handle that, somebody corrects rates by hand, and a mistake surfaces at the VAT return, which is too late.
• Request limits and sync windows. Your plan decides how often the tool asks Allegro and how many items it processes at once. During a sale that is the difference between stock from five minutes ago and stock from an hour ago.

This table has no winning column. It is here to show that you are not comparing three prices for the same thing, but three different bundles. With one account, receipts and standard numbering, the first column is simply the better business decision, and we say so plainly during consultations.

Our workwear store implementation

The closest example from our own work is a store selling workwear and safety equipment on Allegro. The same model in many sizes and colours, so one item in the warehouse is a whole family of listings. Listings went into the panel one at a time, and profitability was calculated in a spreadsheet after the sale. We built an application that publishes listings directly through the Allegro REST API, with no middleman, and calculates margin after commission and shipping before publication. A listing in the red does not go out.

The first version went into production after 3 weeks and has been growing in iterations since. The code and the data sit with the client, deployment runs through GitLab CI, and multi-account support configured from the browser is in code review and has not reached production yet. We did not measure the hours saved, so I am not quoting any; the change the client feels most is a different one: they know what a listing earns before they publish it. The full write-up is in the workwear store case study.

What is missing from that example: an off-the-shelf subscription tool would have coped with publishing listings, but not with custom profitability logic and a variant catalogue mirroring the warehouse. That is exactly the moment when cheap stops being cheap, only seen from the listings side rather than the orders side. The other side of the same process, marketplace orders entering Subiekt nexo PRO as invoices through Sfera, is what we built for a seller on five Amazon EU marketplaces: automatic VAT invoices.

How to find your own threshold and what to ask before signing

The calculation you do at home takes fifteen minutes. You need five numbers: orders a month over the last three months, items in the catalogue, Allegro accounts, the share of orders somebody corrects by hand today, and the fully loaded hourly cost of that person. Put them into the comparison tool above, then verify the result with six questions to the vendor.

1. 01How does the fee grow if I double the number of orders, add 2,000 items to the catalogue and a second Allegro account? Ask for concrete amounts for those three scenarios, not for a price list.
2. 02Does your tool enter nexo through Sfera, and is my current licence enough, or do I need to upgrade to PRO and add a seat?
3. 03Which of my exceptions will the configuration handle, and which stay on my desk? Write them down before the call, from your inbox rather than from memory.
4. 04What stays with me when I stop paying: the configuration, the mappings, the document history, the code? In what format and within what timeframe will I get it?
5. 05Who checks compatibility after a Subiekt update, within what deadline and for how much, when something goes wrong mid-season?
6. 06Can I start with the cheapest option and move to my own code later without rewriting everything from scratch? The answer to this one usually tells you most about who you are talking to.

If the calculation says a subscription is cheaper for you, stay on it: an implementation that does not pay for itself is bad for both of us. If it says otherwise, the next step is an audit for PLN 699 net. That is a few days of work and an implementation document: the document map, the scope, the risks, a fixed price and a deadline, and we credit the whole audit fee toward the implementation price. A typical implementation is 2-3 weeks from kick-off to production; a larger scope is split into stages of 2-3 weeks, each with a working piece at the end.