semplohome.com: rescuing a failing ERP-to-store integration

Semplo Concept Ltd., the Sofia home-furnishings retailer behind semplohome.com, runs its catalogue of more than 11,000 products in the Bizzio ERP and sells them through WooCommerce. The connection between the two had been failing for months: products went missing, photos never arrived, and the ERP vendor itself complained about the load.

We took over the integration, diagnosed every failure down to its cause and rebuilt the sync as a monitored nightly process. Today one request to the ERP per night brings every changed article across, each run is checked for completeness, and the shop runs without manual re-imports.

Today the whole process is automated. The sync starts on its own every night while the team sleeps, records every product it touches, and emails a report in the morning. The hours the team used to spend checking the shop against the ERP now go into growing the business.

We also fixed our own mistakes along the way. This case study lists them next to the ones we inherited.

In January 2026 the ERP vendor wrote to the client that the site's integration was misbehaving, and the client forwarded the message to us the next morning. The vendor's own logs showed three problems:

• The site called the ERP every 3–4 seconds, around the clock, each time asking for every article changed in the last few hours, with images. The vendor's guidance was once a minute at most.
• The sync stopped for almost 20 hours and then again the same evening.
• Each request asked for changes in a fixed window behind the current time, so anything changed during a longer outage was silently lost.

The integration then in place was a single-file plugin with one "Sync" button: no history, no error reporting, no way to see what had arrived. Staff had learned to send products in hand-picked batches of up to 200 and check the next day what had made it across. Photos uploaded in the ERP never appeared in the shop.

The real cost was the team's time. Nobody could see when an import started or finished, or which products had made it. To find out, staff spent hours comparing products in the ERP with products on the website by hand — every time.

Reviewing that code later, we also found the ERP password written in plain text in the plugin's code, and a site endpoint that let any visitor trigger a request to the ERP without logging in.

We traced 14 defects to their cause: 5 inherited, 8 in our own earlier versions and 1 in the server setup. Each was reproduced in a test before it was fixed.

The duplicates show how the old design failed: both copies of each pair were created in the same minute, during the weeks the vendor logged requests every 3–4 seconds. That fits two overlapping requests creating the same product; the old code has no lock against it. We removed all 111 duplicates free of charge, as part of looking after a valued long-term client.

The sync now runs once a night on the server's own schedule, asks the ERP a single question and checks its own work before calling the run complete. Nothing in the shop depends on someone visiting the site or pressing a button.

Full size↗

Nobody has to start, watch or check the sync any more. Every step the team used to do by hand now happens on its own.

Full size↗

The time saved goes back into the business — selling, not checking.

Since September 2026 every fix has been shown failing on the old code before it was written, and the full test suite (318 checks across 22 scripts) passes before any release leaves the laptop.

• Tests against reality. The test server answers like the real ERP, checked against the vendor's documentation and an anonymised real response.
• Repeatable releases. Each release is built twice from the same source and must produce an identical file, checked again before upload.
• Safe deploys. A full backup before every change, deploys only in daytime with hours left for a rollback, and a written rollback that takes one upload.
• A daily check. Each morning: the shop answers for an anonymous visitor, the night's run covered every article exactly once, the server log is clean.
• A clean week. Seven clean nights in a row before we call it done. Any unexplained error restarts the count. On the last night the host's scheduler skipped a slot; the sync started 15 minutes later on its own and still covered every change.

The daily check earned its place on its first morning under v1.2.2: it caught a made-to-order product that had never updated, an old defect of ours that no test had covered. It was fixed and released the same day, and the next night's run updated that product without error.

The ERP now gets one request a night instead of one every few seconds, and every run proves it covered each changed article exactly once.

The next release adds a one-time full refresh the client asked for, so every product can be brought level with the ERP in a single daytime run. It will also replace the fixed 48-hour window with "changes since the last successful run", the approach the ERP vendor recommended in January.

If your shop and your ERP disagree about what you sell, we can find out why.