Apps and extensions: how the plugin bill becomes the architecture
Nobody plans to have twenty-three apps installed. It happens one reasonable decision at a time: a review widget, a shipping calculator, a popup, a loyalty programme, each solving a real problem on the day it was installed.
Two years later the storefront loads eleven third-party scripts, four apps do overlapping jobs, and the monthly bill quietly exceeds the hosting. That is an architecture, and it was never designed.
What an app really costs#
| Cost | How it shows up |
|---|---|
| Monthly fee | Predictable, and it compounds across a dozen apps |
| Page weight | Third-party scripts on every page, often blocking |
| Data | Your customer data now lives somewhere else too |
| Coupling | Uninstalling later leaves orphaned data and broken templates |
| Upgrade risk | The platform updates and the app has not been touched in a year |
Rules that keep the stack sane#
- One job, one app. If two apps overlap, remove one before adding a third.
- Nothing that writes to orders or prices without a review of what happens if it fails.
- Check what the app injects into the storefront before installing, not after a speed complaint.
- Anything unmaintained for a year is a liability, however well it works today.
- Review the whole list every quarter and remove what nobody can justify.
When to build instead of install#
Build when the job is central to how you sell — your bundling rules, your loyalty logic, your quoting. Install when the job is standardised and boring: address validation, accounting export, review collection. The mistake is inverting that.
An app that touches pricing or stock deserves the same scrutiny as a code change, because that is what it is.
The quarterly clean-up that pays for itself#
Sort the app list by monthly cost, then ask of each: what breaks if we remove it tomorrow? For most stores, two or three answers are none at all, and the saving pays for real engineering work.
Frequently asked questions
How many apps is too many?
When you cannot say what each one does and what breaks without it.
Do apps slow a store down?
Front-end apps usually do, because they add third-party scripts to every page. Back-office apps often do not.
Is it safer to build the same feature?
Safer to control, more expensive to maintain. Build what is central to how you sell; install what is standardised.
ecommerce appsstore pluginsextension bloatthird party scriptsstore performance
