Most "Shopware vs Shopify" posts compare dashboards, app stores, and pricing tables. None of that matters to you until the day a client asks for something the platform won't let you build. Then the comparison stops being a feature grid and becomes a question about ceilings: how high can I go before the platform says no, and what happens when I hit it?
That's the only axis I care about as a developer, so that's the one I'll argue on. Shopify is an outstanding product. It's also a closed SaaS that decides, on your behalf, where customization ends. Shopware is open source built on Symfony, which means the ceiling is "however far PHP and HTTP will take you." Below are the three places that difference actually bites, with code.
Angle 1: The checkout is the wall
This is the headline because it's where most agency developers first hit something they cannot do.
For years the Shopify answer to "customize the checkout" was checkout.liquid. That era is over. Shopify deprecated checkout.liquid in favour of Checkout Extensibility. Plus stores had to migrate their Thank-you and Order-status pages by August 28, 2025, and in January 2026 Shopify began auto-upgrading stores — wiping customizations built on additional scripts, script-tag apps, or checkout.liquid. Non-Plus stores have until August 26, 2026, and legacy Shopify Scripts keep working only until June 30, 2026. (Shopify migration timeline)
The replacement, Checkout Extensibility, is genuinely more upgrade-safe. It's also a smaller box. You get Checkout UI Extensions (declarative components that render in slots Shopify defines) and Shopify Functions for backend logic — and that's the surface. You don't own the checkout template; you decorate the pieces Shopify exposes. Worth noting: full visual checkout customization (branding API, custom fields beyond the defaults, full UI extension power) is gated to Shopify Plus anyway.
On Shopware, the checkout is a Twig template like every other page, and you override it the same way you override anything else — by extending a block:
{# MyPlugin/src/Resources/views/storefront/page/checkout/confirm/index.html.twig #}
{% sb_extends '@Storefront/storefront/page/checkout/confirm/index.html.twig' %}
{% block page_checkout_confirm_tos %}
{# Inject a B2B purchase-order field right above the terms checkbox #}
<div class="po-number-field">
<label for="poNumber">{{ "checkout.poNumberLabel"|trans }}</label>
<input type="text" id="poNumber" name="poNumber"
value="{{ page.extensions.poNumber ?? '' }}" />
</div>
{{ parent() }}
{% endblock %}
No slot has to exist for this. No feature has to be on a pricing tier. You're editing the checkout's actual markup, in the same templating language as the rest of the storefront, and your override survives core updates because it extends rather than replaces. The Shopify equivalent — arbitrary markup in the middle of the checkout flow — is simply not a thing you can do, on any plan.
Angle 2: Backend logic — a 5ms sandbox vs. the whole framework
Say the requirement is a non-trivial discount: "15% off, but only for B2B customers in a specific customer group, only on products from suppliers we flag as overstocked in an external ERP, and only Monday–Wednesday."
On Shopify this is a Shopify Function: Rust or JavaScript compiled to WebAssembly. It's clever engineering, but read the constraints before you design against it. A function's Wasm module must be ≤ 256 KB, may execute ≤ 11 million instructions, runs under a ~5 ms execution budget, is fully sandboxed (isolated memory, no network calls out to your ERP), and forbids nondeterminism — no clock, no random. Functions also can't be chained or made aware of each other. (Shopify Functions / WebAssembly docs)
Look at that list against the requirement. "Only on overstocked products from an external ERP" needs a network call — not allowed in the function. "Monday–Wednesday" needs the clock — not allowed. So the real-world implementation becomes: a separate hosted app syncs ERP + day-of-week state into metafields out-of-band, and the function reads those metafields. You can ship it, but the platform pushed a chunk of your domain logic out of the function and into infrastructure you now operate and keep in sync.
Here's the shape of what you're allowed to do inside the function — pure, deterministic, metafield-fed:
// Shopify Function (JS → Wasm). No network, no Date.now(), ≤5ms, ≤256KB.
export function run(input) {
const discounts = input.cart.lines
.filter((line) => line.merchandise.product?.isOverstocked?.value === "true")
.map((line) => ({
targets: [{ cartLine: { id: line.id } }],
value: { percentage: { value: "15.0" } },
}));
return { discounts, discountApplicationStrategy: "FIRST" };
}
On Shopware the same rule is an event subscriber in ordinary PHP, with the full container at your disposal — the database, HTTP clients, your ERP service, the clock, everything:
<?php
// MyPlugin/src/Subscriber/OverstockDiscountSubscriber.php
namespace MyPlugin\Subscriber;
use Shopware\Core\Checkout\Cart\Cart;
use Shopware\Core\Checkout\Cart\Event\CartChangedEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
class OverstockDiscountSubscriber implements EventSubscriberInterface
{
public function __construct(
private readonly ErpClient $erp, // your own HTTP service
private readonly DiscountFactory $factory // injected, like any Symfony service
) {}
public static function getSubscribedEvents(): array
{
return [CartChangedEvent::class => 'applyOverstockDiscount'];
}
public function applyOverstockDiscount(CartChangedEvent $event): void
{
$cart = $event->getCart();
$weekday = (int) (new \DateTimeImmutable())->format('N'); // 1..3 = Mon..Wed
if ($weekday > 3) {
return;
}
// A real network call to your ERP — impossible inside a Shopify Function
$overstockedSkus = $this->erp->fetchOverstockedSkus();
foreach ($cart->getLineItems() as $item) {
if (in_array($item->getReferencedId(), $overstockedSkus, true)) {
$this->factory->applyPercentage($cart, $item, 15.0);
}
}
}
}
The point isn't that PHP is nicer than Rust. It's that the entire business rule lives in one place, inside the request, with no sandbox to design around. Shopify's model is safer and more scalable by construction — that's a real trade-off, not a slur — but it's a model where the platform decides which parts of your logic are allowed to run where. Shopware doesn't make that decision for you.
Angle 3: Where your code lives
This one is structural and easy to underrate.
A Shopify app is an external application. It runs on infrastructure you host, talks to the store over OAuth and the Admin/Storefront APIs, and reacts via webhooks. Your code is never in the store; it's a satellite orbiting it through a rate-limited API. That's a clean boundary, and for many integrations it's the right one. But it means even small backend tweaks become a deployed, authenticated, separately-monitored service — and you're always one API version or rate-limit window away from the platform.
A Shopware plugin is a Symfony bundle that lives inside the application. The class hierarchy is literal: your plugin extends Plugin, which extends Bundle, which extends Symfony's Bundle. (Shopware: Plugins for Symfony Developers) So a plugin is just a Symfony bundle with conventions, and standard framework wiring applies:
MyPlugin/
├── composer.json
└── src/
├── MyPlugin.php # extends Shopware\Core\Framework\Plugin
├── Resources/
│ ├── config/
│ │ ├── services.xml # DI: register your subscribers/services
│ │ └── routes.xml
│ └── views/storefront/... # Twig overrides (see Angle 1)
├── Subscriber/
│ └── OverstockDiscountSubscriber.php # runs in-process (see Angle 2)
└── Migration/
└── Migration1700000000Example.php # owns its own schema changes
<?php
// MyPlugin/src/MyPlugin.php
namespace MyPlugin;
use Shopware\Core\Framework\Plugin;
class MyPlugin extends Plugin
{
// It's a Symfony bundle. Services in services.xml autoload,
// routes register, migrations run on install. No external host,
// no OAuth handshake, no API version to chase.
}
Your subscriber from Angle 2 and your Twig override from Angle 1 are the same deployable unit — one bundle, in the same process as the shop, sharing its container and database. There's no satellite to operate.
The honest trade-offs
I'd be doing the dishonest version of this post if I stopped there.
Shopify's closed model buys you things that are genuinely hard to replicate: you never patch a server, the checkout converts extremely well out of the box, PCI scope is mostly Shopify's problem, and the sandboxed Functions model means one tenant's bad discount logic can't take down the platform. For a merchant who wants to sell, not to operate software, that's often the correct choice — and as a developer you should say so.
There's also a cost angle that's easy to forget mid-architecture-debate: if you use any payment gateway other than Shopify Payments, Shopify adds a third-party transaction fee — 2% on Basic, scaling down to 1% (Grow), 0.6% (Advanced), and 0.2% (Plus). (Shopify third-party transaction fees) Self-hosted Shopware has no such cut — but you (or your host) now own uptime, security patching, and scaling, which is not free either. You're trading a platform fee for an operational burden. Which one is cheaper depends entirely on the project.
Shopware's openness is power and responsibility. The ceiling is high because there basically isn't one — and the flip side of "there's no sandbox to design around" is "there's no sandbox protecting you from yourself."
So when does the open platform win?
When the requirement is the thing the closed platform won't let you build. A checkout that needs custom markup, not a Shopify-defined slot. Business logic that has to call your ERP synchronously and consult the clock. A backend tweak that belongs in-process, not in a separately-hosted, OAuth'd, rate-limited satellite. The moment a project has two or three of those, the Shopify ceiling stops being theoretical and starts costing you weeks of working around it — and Shopware's "it's just Symfony" stops being a slogan and starts being the reason you ship on time.
Pick Shopify when you want the platform to make decisions for you. Pick Shopware when you need to make them yourself. As a developer, you already know which kind of project lands on your desk.
I'm CTO at nextlevels, a German digital agency and Shopware Silver Partner. We build Shopware shops, custom software, and AI workflows for B2B Mittelstand clients — so I've shipped enough of both platforms to have opinions. Happy to argue the trade-offs in the comments.
