A plant nursery came to me a few years ago with a Shopware 6.4 shop and a problem they couldn’t shake. They had already paid another developer several thousand euros. The store worked, mostly. Then a plugin would break the layout. A small design change would break the checkout. Every fix held for a few weeks, then something else gave way.
They weren’t shopping on price anymore. They’d tried that. Hiring a Shopware developer on the lowest quote had already cost them more than they ever planned to spend, and the bugs kept coming back.
Here’s what happened next, and what five years of working together taught me about what “cheap” actually costs.
The shop that was already broken
When I opened their theme, the problem wasn’t where you’d expect. The previous developer hadn’t touched Shopware’s core. The theme itself was the problem. It was built so tightly wound that nothing could be changed without something else breaking.
There was no room to customize. Move a block, restyle a section, add a feature, and something three steps away would break. Even understanding how the thing was wired together was a job on its own. For a new developer to read that code and predict what a single change would do was the first real challenge.
That works on the day you ship it. It stops working the moment anyone needs to change anything. And a live shop always needs to change.
So every plugin, every new requirement, every attempt to adjust the design risked taking part of the storefront down with it. The owner was paying for the same category of fix, over and over.
From the outside it looked like bad luck. It was structural. A shop built this tightly breaks on a schedule, and the schedule is “whenever you touch it.”
Why patching looked cheaper (and wasn’t)
Here’s the trap. Each individual fix was small. A few hundred euros, a day here and there. Saying yes to one more patch always felt cheaper than the alternative.
But the patches never added up to a stable shop. They added up to a more tangled one. Fixing the checkout reintroduced a layout bug. Fixing the layout broke a filter. It was patching a symptom on a foundation that was the real problem.
And the invoice was never the whole cost. Add the downtime when the shop went sideways during business hours. Add the orders that didn’t complete while the checkout was broken. Add the owner’s own hours spent emailing a developer who kept saying “we’ll look into it.”
Run that over two or three years and the “cheap” build becomes the single most expensive thing in the business. It just arrives in installments, so nobody adds it up.
The expensive truth I told them
I didn’t lead with that. At first I did what they expected. I patched the problem in front of me, then the next one, then the one after that. That’s the honest version. For a while I worked inside the theme the way it was.
It didn’t take long to hit the wall. Every fix held until the next change knocked something else loose. I was treating symptoms on a structure that was the actual problem. So I told them the thing they didn’t want to hear: this won’t hold for the long run. The theme had to be rebuilt properly, to Shopware standard, and the patching had to stop.
Shopware standard isn’t jargon. It means building the theme on the platform’s own inheritance and block system, so the design can change without the shop breaking. A theme built that way bends when you push it. Plugins sit alongside it instead of colliding with it. New requirements get added instead of feared.
That call cost them more up front than another round of patches, and I was honest about that. A proper rebuild is real work, and I didn’t pretend otherwise.
What they got back was a shop that stopped breaking, and one they could finally change without holding their breath. They trusted me to make that call, and we’ve worked together ever since.
That’s the part worth sitting with. The cheaper-looking option had already drained thousands. The honest option, the one with a bigger number on the first invoice, is the one that ended the bleeding.
Five years later, trust compounds
We’re in the fifth year now. The recent work tells you how far that trust has come.
I migrated their entire catalog, close to 10,000 products, onto a new PIM (the system that holds every product, price, and description the storefront pulls from). On a live store, get that wrong and customers watch the shelves break in real time. We did it on a quiet day, with a short planned maintenance window. Customers noticed nothing.
And the work isn’t standing still. We’re now taking the shop international, opening it beyond Germany instead of serving one market. That’s only on the table because the rebuild gave them a foundation that can grow. The old, tightly-wound theme that couldn’t survive a redesign would never have carried a second language and a new market.
It’s the kind of high-stakes work I’ve done on bigger jobs too, like a platform migration kept alive during the switch and cutting a 500,000-product import from 33 hours to under 3.
Nobody hands you their live catalog, or their expansion into new markets, on day one. That trust got built one honest call at a time, over years. Projects end. The relationship is what keeps paying off.
How to hire a Shopware developer who won’t cost you twice
If you’re hiring a Shopware developer right now, a few questions separate the ones who build to last from the ones who’ll have you back in six months.
- Will I be able to change the design later without breaking the shop? You want a theme built on Shopware’s inheritance and block system, not hardcoded together. A tightly-coupled theme is cheap to ship and expensive to live with.
- Will the theme survive a Shopware update and a new plugin? Ask directly. A developer who builds properly can explain why the answer is yes.
- What’s the plan when something breaks? You want a person who picks up, not a ticket queue and a “we’ll look into it.”
- How do you handle migrations on a live shop? A real answer involves a maintenance window and a rollback plan, not “it’ll be fine.”
The red flags are just as useful. The cheapest quote almost always means the fastest, least durable build. “We’ll just hardcode it into the theme” means you won’t be able to change it later without a fight. No migration plan usually means they haven’t done many.
What this leaves you with
The cheapest developer is rarely the cheapest outcome. You tend to pay the difference later, with interest, in downtime and rework.
For what it’s worth, I’m not the lowest quote you’ll get, and I’m not the highest. What you get is senior-level Shopware work at a fair rate, and a shop that stops showing up as a line item in next year’s repair budget.
If that’s the kind of work your store needs, get in touch or book a call. The case studies show what it looks like in practice.
Frequently asked questions
What does it cost to hire a Shopware developer? Rates vary widely, but the number that matters is the total cost over a few years, not the first invoice. A cheap build that breaks every time you change it usually costs more than a proper one that doesn’t. Ask what the work will cost to live with, not just to deliver.
Why does my Shopware theme break every time I change something? Usually because the theme is built too tightly, with the design hardcoded instead of using Shopware’s theme inheritance and block system. When everything is wired together, one change or one plugin knocks something else loose. A theme built on Shopware’s extension points bends instead of breaking.
Is a custom Shopware theme better than a bought one? It depends on how it’s built. A bought theme hacked into shape breaks just like a bad custom one. What protects you is that the theme is built on Shopware’s inheritance and block system, whatever its origin.
What is a Shopware-standard theme? One built on Shopware’s theme inheritance and Twig block system instead of hardcoding the design. It can be customized, survives plugins and updates, and can be upgraded without a full rebuild.
Can you migrate a live Shopware shop without taking it offline? You can migrate with minimal disruption. The honest version is a short, planned maintenance window on a low-traffic day, with a rollback plan ready. I migrated a 10,000-product catalog to a new PIM this way and customers noticed nothing.
