Workwear store.

Situation

A jacket or a pair of trousers comes in many sizes and colors, and Allegro wants a full set of data for every variant. Managing listings ate the time that should have gone into purchasing and buyers.

Let's be straight: an off-the-shelf subscription tool is often enough, and when it is, that is what we recommend. Here it was not, because the client wanted their own profitability logic and a variant catalog mirroring their warehouse.

What was not working

A few inconveniences added up to a daily loss of time and money.

• Listings were created by hand in the Allegro panel, every size from scratch.
• Margin calculated in a spreadsheet after the fact: that a listing breaks even after commission and shipping was known only after the sale.
• A second Allegro account meant a second set of listings, with no shared catalog.
• A rejected listing got lost in the panel; there was no certainty which variants were live.

What we built

A dedicated application: React frontend, Symfony backend, PostgreSQL database. It talks to Allegro directly through the REST API, with no middleman and no subscription for someone else's platform. The code and the data belong to the client.

The heart of the application is the variant catalog: model, size, color, purchase price, stock. Listings are assembled from the catalog in a custom workflow, and the profitability module calculates the margin after Allegro commission and shipping cost before publishing. A listing in the red does not go any further.

Production runs on the client's server in Docker. Deployment is handled by GitLab CI: image build, database migrations, restart. Application errors go to monitoring, so we see them before the client does.

How it works day to day

An employee picks a group of variants in the catalog, checks the pricing and clicks “publish”. Publishing goes to a queue and is executed by a background process, so the interface does not wait for Allegro. Each variant remembers its listing status, listing ID and last error, so re-running does not create duplicates, it only completes what is missing.

When Allegro rejects a listing, the reason is shown next to the variant, right where it gets fixed.

Results

Listings are no longer created by hand, and profitability is known before publishing, not after. The first version went to production after 3 weeks and has been growing in iterations since, driven by how the client's team uses it.

We did not measure the hours saved, so we do not quote them. The change the client feels most: they know how much they make on a listing before they publish it.

What we learned

Database migrations at the client run automatically on deploy, with no rollback, so we tested the current series of changes on a production-shaped copy, including reverting them. A migration that could wipe listing statuses has a safety catch: instead of deleting data, it stops the deploy and says why.

Listing on Allegro by hand, or paying a middleman you do not need? A free consultation takes 30 minutes. When the topic is bigger, an audit for PLN 699 net is a few days of work and an implementation document: architecture, scope, risks, a fixed price and a deadline; we deduct the full amount from the implementation price.