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.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer