Your store,
run by your rules
We set up the rules and flows that run your Shopware store, build the apps, plugins and integrations around it, and keep each one ready for the next major release, so each year’s update arrives with a plan.
Thanks, we’ll be in touch soon.
{{ heroStatus }}
You’re in good company
A few of the companies we’ve worked with.
When the code does what a rule could
Many Shopware stores carry custom plugins written to change prices, shipping, payment methods or what happens after an order. A plugin is code that runs inside the store itself, with full access to it.
Shopware’s Rule Builder and Flow Builder can now do much of that in the store’s settings: a rule decides which prices, shipping and payment methods a customer gets, and a flow decides what happens when an order is placed, paid or shipped. Not every case fits, but many do.
Major releases bring breaking changes, so plugins often need a new release for each one. Plugins also run only on self-hosted stores and Shopware PaaS, while apps, which work from outside the store, run on Shopware SaaS too. So each major release, and any move between hostings, starts with the plugin list.
What we build
The work on a Shopware store, kept where your team can see it: every extension, rule and integration with an owner on your side and ours, and every change tried on a staging copy, a copy of the store kept for testing, before customers see it.
Rules and flows
Rule Builder conditions for prices, shipping and payment methods, and Flow Builder for what happens after each order, set up and named so your team can read them. Code only where a rule can’t do the job, as the next section shows.
Apps and plugins
Each extension chosen by where your store runs and what it has to do: plugins run inside the store, on self-hosted stores and Shopware PaaS; apps work from outside it, through Shopware’s APIs, wherever it’s hosted. Kept in source control with tests, and given a release for each major version.
Themes and layouts
Storefront themes built on Shopware’s default theme, and Shopping Experiences layouts, made of sections and blocks, for the pages your team arranges itself. A headless storefront with Composable Frontends, Shopware’s own Vue.js and Nuxt toolkit, where it fits.
B2B buying
B2B Components on the plans that include them: company accounts with employees and their roles, order approvals, quotes, quick orders and order lists. Digital Sales Rooms, on the Beyond plan, where your sales team guides buyers through a live session.
Integrations
Your ERP, product data and warehouse systems connected through the Admin API, the Store API and webhooks, with large updates through the Sync API. Each integration gets its own credentials and a role with only the permissions it needs.
Major releases, planned
Every extension checked against the release candidate when it arrives, each update tried on a staging copy first, and Shopware’s security plugin where an update has to wait, as the section on releases sets out.
Where the store runs
Self-hosted, Shopware PaaS or Shopware SaaS, and moves between them, with what each allows and who updates it: Shopware updates SaaS stores itself, while on PaaS and your own servers your team does. For your own servers, the hosting is set up as our Cloud, DevOps & Security work does it.
Moves onto Shopware 6
From Shopware 5 with Shopware’s Migration Assistant, or from another platform: your products, customers and orders checked against the old store before launch, and every old address sent on to its new one with a redirect.
AI where it helps
Shopware’s MCP server, which Shopware marks experimental until Shopware 6.8, set up so AI assistants can work with your store: through the Admin API under an integration’s own role, or through the Store API within a shopper’s session, each with only what you allow.
- Connecting any of your systems:Systems & API Integration
- Automation across your tools:Workflow Automation
- Care once it’s live:Support & Maintenance
- Developers in your own team:Hire developers for Shopware stores
Written as rules, not code
Rule Builder defines a condition once, such as a customer group, what’s in the cart or the country an order ships to, and the same rule can then decide prices, shipping and payment methods, promotions and flows.
Flow Builder runs actions when something happens in the store, such as an order being placed, paid or shipped, with a rule deciding which orders each flow reaches: create the invoice and send it, tag the order, or email your team.
So much of what stores once wrote as plugins can be set up, read and changed in settings, and code stays for what a rule can’t express. Some flow actions come with the paid plans, as Shopware’s docs set out.
{{ flAns }}
A flow set up in settings is changed in settings, with nothing to release.
{{ flStatus }}
One major release a year
Shopware releases one major version a year, a minor version on the first Monday of every month, and patches when they’re needed. A release candidate arrives about two months before each major, and that phase can run longer.
Minor versions and patches install without changes to extensions. A major can need them: how much depends on how far the store is customized and how many extensions it runs.
Support moves with each major release, not on fixed dates. When a new major arrives, the last minor of the one before moves to Extended support, with selective bug fixes and security updates, and older versions get security fixes only, through Shopware’s security plugin, until they reach end of life. When Shopware 6.7 arrived, 6.6 moved to Extended support and 6.5 left it.
Shopware SaaS updates itself every week. On Shopware PaaS and your own servers, your team updates, and Shopware advises updating over relying on the security plugin. A store on an older version keeps running, and the move up is planned, not rushed.
So every extension is checked against each release candidate, each update is tried on a staging copy first, and the store moves up once a year, on a plan.
Start with the extension list
The review covers the version your store runs and where, self-hosted, Shopware PaaS or Shopware SaaS, and whether it’s on a paid plan or the Community Edition; every extension, from the Shopware Store or your own, plugin or app, what it changes, and whether it has a release for the next major; the rules and flows, and the plugins that could become one; themes, Shopping Experiences layouts and any headless storefront; each integration, with its credentials, its role, the APIs it calls and its webhooks; B2B Components, if they’re in use, and staff roles; and whether the security plugin is installed and current.
The first step is one plugin replaced by a rule or a flow, or one extension readied for the next major, tried on a staging copy first.
You get a written review and a proposal for the first step.
Questions worth asking
We’re still on Shopware 5. Where do we start?
With a list of what your store runs. Shopware 6 is a new system rather than an update: Shopware’s Migration Assistant brings products, customers, orders and more across, checking the data before it starts, while the theme and the plugins your store relies on are rebuilt or replaced for Shopware 6. Shopware’s own page gave the end of July 2024 as the last of its security fixes for Shopware 5. Your store keeps running meanwhile, and we plan the move, try it on a copy and redirect every old address.
Our Shopware 6 version is behind. How far is too far?
Shopware’s release calendar shows where each version stands. The newest minor version is the maintained one; when a new major arrives, the last minor of the one before gets Extended support, and older versions get security fixes only, through Shopware’s security plugin, until they reach end of life. A store on an older version keeps running, and the security plugin covers it while an update waits, though Shopware advises updating where you can. We check where your version stands and plan the move up.
Should we build plugins or apps?
It depends on where your store runs and what the extension has to do. Plugins run inside the store, with full access to it, on self-hosted stores and Shopware PaaS. Apps work from outside the store, through Shopware’s APIs and webhooks, on every kind of hosting, Shopware SaaS included. Some jobs need a plugin’s access and many don’t, so we choose with you, one extension at a time.
Self-hosted, PaaS or SaaS?
Each suits a different team. Shopware SaaS is hosted and updated by Shopware every week, and runs apps rather than plugins. Shopware PaaS is hosted by Shopware too, and your team installs the updates. Self-hosted runs on servers you choose, where your team does both. We look at your extensions and who will run the updates, then suggest where the store should run.
Can a rule or a flow replace one of our plugins?
Often, for logic about prices, shipping, payment methods or what happens after an order. Rule Builder can decide which customers get which prices, shipping and payment methods, and Flow Builder can act when an order is placed, paid or shipped. What a rule can’t express stays in code. We go through your plugins with you and move what fits, one at a time.
Do we need a paid Shopware plan?
Not to run the store: the Community Edition is free and open source, under the MIT license. Shopware’s terms let a Shopware Account be used with it only while the stores linked to that account stay at or below one million euros of GMV, the value of goods sold, over the preceding 365 days; above that, Shopware’s Fair Usage Policy asks for one of its paid plans, Rise, Evolve or Beyond, to keep the Shopware Account and the Shopware Store. Some features come only with a paid plan, such as B2B Components from Evolve. We set out what your store needs, plan by plan, as Shopware lists it.
Can you build B2B features like approvals and quotes?
Yes, with B2B Components, on the Evolve and Beyond plans: company accounts with employees and their roles, order approvals, quotes your team prepares from a buyer’s cart, quick orders and order lists. Where you need something more, we build it to sit beside them.
Can our team change pages without a developer?
Yes, with Shopping Experiences, Shopware’s own page layouts: your team arranges sections and blocks for landing pages, category pages and other shop pages, and we build any blocks of your own they need.
Can you build a headless storefront?
Yes, where it fits. Composable Frontends is Shopware’s own Vue.js and Nuxt toolkit for a storefront of your own, built on the Store API. A headless storefront gives your team a front end it controls fully, and also more to build and run, so we weigh it against Shopware’s own storefront first.
Can you connect our store to our ERP, product data or warehouse systems?
Yes. The Admin API and webhooks carry most connections, with the Sync API for large updates, and each integration signs in with its own credentials and a role with only the permissions it needs. Each connection is mapped field by field first, with one system named as the source for each record, and tried on a staging copy before it runs on the live store.
Can AI assistants work with our store?
Yes, through Shopware’s MCP server, which Shopware marks experimental until Shopware 6.8, so its tools may still change. Assistants for your team work through the Admin API under an integration’s own role, and assistants for shoppers through the Store API, within a sales channel, as a shopper would. We set up only the access each one needs, for the jobs you agree.
Can you move us onto Shopware from our current platform?
Yes. We bring your products, customers and order history in through Shopware’s import tools and APIs, check the records against the old store with your team before launch, and give every old address a redirect, so links and bookmarks still land.
Can you take over our existing store?
Yes. We start with the extension list and the review, so nothing runs on your store without an owner, then take on the work you choose first, alongside your team if you have one.
How do you keep our store secure?
Every integration gets its own credentials and a role with only the permissions it needs, and every member of your staff a role in the Administration that matches their work. Security updates go in as Shopware ships them, tried on a staging copy first, and the security plugin covers a version while its update waits.
What does it cost?
It depends on your store, its extensions and the first step you choose. Before any work starts, you get a written proposal with the scope, the price or rate, and how you pay.
Can we hire Shopware developers for our own team?
Yes. We introduce developers who know Shopware within 48 hours of your request, working in your time zone. You meet them first, and decide who joins.
Shopware is a trademark of shopware AG. Webair is independent of shopware AG, and isn’t sponsored by, endorsed by or affiliated with it.
Let’s build it better
Tell us which version your store runs and where it’s hosted. We’ll agree on a first step in a short call.
Thanks, we’ll be in touch soon.
{{ ctaStatus }}