Photo: free stock photography (Unsplash licence) — see imprint
The 70% trap
Almost every store plugin covers the obvious 70% of a requirement beautifully. The remaining 30% — your pricing rule, your ERP field, your customer group logic — is exactly the part your business actually competes on. That last 30% is where projects quietly go over budget, because you end up paying a developer to bend a plugin that was never designed to bend.
A rule of thumb that holds up
Buy when the requirement is a commodity: cookie banners, invoice PDFs, payment providers, sitemaps. Build when the requirement encodes a business rule that is unique to you: scale pricing per customer, availability logic across warehouses, quote workflows. Commodity plugins get maintained by their vendor for years; your pricing logic never will be.
The hidden cost nobody quotes
A €300 plugin is rarely a €300 decision. Add the integration time, the template overrides it forces, the update it blocks next spring, and the second plugin you buy because the first one does not talk to it. We have seen three €300 plugins cost more over two years than one clean custom extension would have.
How to decide in one meeting
Write down the requirement as a sentence. If you can end that sentence without naming your company, buy it. If the sentence only makes sense with your customers, your ERP or your margin model in it, build it — and build it as a proper plugin, never as a core hack.
- Commodity → buy. Business rule → build.
- Count integration and update cost, not the licence price.
- Never solve the last 30% with a core hack.
Frequently asked questions
Write the requirement down as one sentence. If you can finish that sentence without naming your company, buy it — cookie banners, invoice PDFs, payment providers, sitemaps are commodities and someone else will maintain them for years. If the sentence only makes sense with your customers, your ERP or your margin model in it, build it. Nobody else will ever maintain your pricing logic.
Because it was built for the obvious part of the requirement, and it covers that part beautifully. The remainder — your pricing rule, your ERP field, your customer group logic — is precisely the part your business competes on, so no vendor could have anticipated it. That is where budgets quietly disappear: paying a developer to bend a plugin that was never designed to bend.
Rarely. Add the integration time, the template overrides it forces on you, the update it blocks next spring, and the second plugin you buy because the first one does not talk to it. Three cheap plugins can easily cost more over two years than one clean custom extension would have. Count the two-year total, not the licence line on the invoice.
You can, and you will pay for it at every update for as long as the shop exists. If the last stretch of a requirement does not fit, that is information: the plugin is the wrong tool, not an almost-right one. Build that piece properly as a plugin of your own. A core hack is not a shortcut, it is a debt with an automatic payment schedule.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer