WooCommerce vs Laravel: Which E-commerce Build, and When

The platform is not decided by a first-day feature list — warehouse, B2B prices and multi-language operation we build on both. What decides it is who decides your next change, and what that change costs.

A technology question whose answer is not a feature list

The conversation almost always starts the same way: the client has around seven hundred products, three price levels for resellers, each of whom sees only their own price when they sign in, and Visma Horizon accounting, where the stock figure is the truth and the store merely reflects it. The question they ask is this one: WooCommerce vs Laravel? The answer they expect is a two-column table with something in one column and a gap in the other — a table we do not have, and neither does anyone else who genuinely builds on both.

A warehouse module with real-time stock sync, B2B pricing tiers, a discount system, multi-language support and content migration we build on either platform, and the price in our price list does not depend on which one is underneath: the Basic version of an online store costs €4,500 and the Pro version €9,500 on WooCommerce exactly as on Laravel. Those five lines are what separates Basic from Pro, not what sits beneath them; the admin panel is named in the price list at the Basic level already, while multi-currency operation is in neither version and is agreed separately — again, on either platform.

One practical thing follows from that. A platform sold to you on the strength of a first-day feature list is being sold on something you can have either way, and a comparison that opens with that list is finished before it starts. The interesting question begins a step further on: who decides what your store will be able to do next year, and how long that decision waits in somebody else's queue.

In the first year both platforms do what you paid for, because in both cases somebody has just built it; in the second year the process changes — wholesale arrives, or a second warehouse, or an obligation to issue machine-readable invoices, or simply a different order of discounts — and from that point the two roads cost differently. On another vendor's extension every later change is like remodelling rented premises: the rules of your process live in somebody else's settings screen and move on somebody else's release schedule. On your own code the same thing is work with an hourly rate in the price list, and the only thing to agree is its priority against everything else on the list.

What WooCommerce does well

We put WooCommerce into client stores ourselves whenever the process fits, and it is the most widely used e-commerce system in W3Techs' surveys: on 6 August 2026 it was running on 8.2% of all websites and made up 48.5% of all e-commerce systems in those surveys. What matters more than the number itself is what it is a share of — of the systems surveyed, not of the world's stores and certainly not of e-commerce turnover — and behind it stands WordPress, on 41.2% of all websites.

The WordPress.org plugin directory showed WooCommerce 11.0.0 the same day, updated on 4 August, with the bucketed estimate "7+ million active installations", and it is the vendor itself that advises reading that cautiously: usage tracking is switched off by default in the core downloaded from WordPress.org, so nobody — Automattic included — knows how many of those stores actually trade, and the figure is an upper bound on installations rather than a count of merchants.

The vendor's own pricing page describes WooCommerce as free and open source, with no platform fee and a 0% revenue share: you do not pay for selling, and you do not pay for growing. The catalogue, the order list and the discount settings also look exactly like the rest of the WordPress admin, which your team most likely already knows how to use without training.

The strongest argument in WooCommerce's favour almost always drops out of competitor comparisons, and it is the automatic patch. On 2 March 2026 a Store API vulnerability was disclosed that affected versions 5.4 through 10.5.2 and allowed a forged request to create an administrator account; somebody else found the flaw, not the store owners; the fix was backported across 52 affected versions; and from 14:00 UTC the same day it began rolling out automatically to every store with automatic updates enabled, with no invoice attached. That setting is not self-evident, and configuring and watching it is precisely what a person does under a maintenance contract; how WordPress sites get broken into, and what to do when that has already happened, is set out in our article on a hacked WordPress site.

The recommendation has therefore not changed, and it is written on our service page as well: for a very small store with standard processes — WooCommerce. For a hundred products with one price, one warehouse and one payment method, a custom platform gives you nothing worth paying the difference for, and selling the more expensive option when the cheaper one does the same job means one more dissatisfied client and not a single referral.

Does WooCommerce handle Latvian payments and delivery?

It does. Delivery and payments in Latvia are not where an off-the-shelf store runs out of road, and warnings to the contrary are usually unfounded: Omniva publishes ready modules for six platforms — WooCommerce, Shopify, PrestaShop, OpenCart, Magento and Mozello — and next to them a documented OMX interface carrying shipment data, labels, tracking events and parcel-machine lists across all three Baltic states, the precondition for which is a company contract rather than a programmer. DPD Baltics maintains its own WooCommerce plugin in the WordPress.org directory — version 1.2.91, more than 2,000 active installations — covering parcel machines, courier collection, labels, manifests and cash on delivery; the same page also shows its public rating of 2.7 out of 5 and user reviews complaining of conflicts with other delivery plugins.

MakeCommerce, with Maksekeskus AS behind it, gives you bank links for Swedbank, SEB, Citadele and Luminor, cards, Apple Pay and Google Pay under a single contract, and Omniva, DPD, Venipak and Unisend delivery alongside them; its WooCommerce plugin has more than 3,000 active installations and was last updated in June 2026. Klix by Citadele, maintained by the bank itself, publishes official plugins for six platforms, WooCommerce from version 3.5 among them, so to claim that an off-the-shelf store cannot take money in Latvia would simply be untrue.

The other side of the same coin is that these providers are not the property of the plugins: MakeCommerce, Omniva and DPD publish interfaces, not only modules, and in our price list connecting payments — MakeCommerce and Stripe — is part of the Basic version at €4,500 already, whatever platform sits underneath. Integrations with Horizon, Jumis, Latvijas Pasts, Omniva and DPD are a line of the store service, not a surcharge for Laravel, and we work with the Omniva, Latvijas Pasts, DPD and Venipak delivery APIs regularly, which is why the Latvian delivery and payment layer is an argument neither for nor against any of the three routes.

Where the real work is in Latvia

What complicates the back office is that Visma Horizon, Jumis and Directo each publish a REST interface of their own; Directo's documentation describes authorisation with an X-Directo-Key header and access to items, orders, customers, invoices, stock and price formulas. A published interface is not yet an integration, though: somebody has to line up what the store calls a product with what the accounting system calls a stock item, and decide which of the two holds the truth about the stock figure in the second the buyer presses the button. Two places where the stock figure lives are like two clocks on a ship: until they are set against each other nobody knows the time, and this work is bespoke on any platform — with Horizon and Jumis we do it regularly.

Above it sits a dated legal fact with a trap inside it: a structured electronic invoice has been mandatory towards public bodies in Latvia since 1 January 2025, and it becomes mandatory in transactions between companies on 1 January 2028 — under the Accounting Law and in the LVS EN 16931-1:2017 format. The trap is the date: 2026 was the year originally planned, so press articles from 2024 still name the wrong deadline, and it needs checking against the Ministry of Finance's page about structured electronic invoicing rather than in the news, because a store that sells to businesses will need somebody to build a machine-readable invoice route on any platform, whichever year finally turns out to be the right one.

WooCommerce vs Laravel: which of the three routes is yours?

Comparisons that present this choice as two buttons leave out the route we sell most often, because there are in fact three of them; they differ in how much of your process lives in code you can change yourself, and choosing between them is choosing where your pricing and order rules will sit from now on — in a settings screen, in your own repository, or somewhere between the two.

The first route is an off-the-shelf tool with off-the-shelf extensions — WooCommerce or OpenCart, which we also offer to existing stores. WooCommerce core has two price fields, regular and sale, one stock figure per product or variation, and three payment methods, none of which takes money online, which is why a price for a particular customer group, quantity discounts, turning a quote into an order, VAT exemption and stock in several warehouses are each a separate purchase from a separate vendor with a separate annual subscription. This route is the fastest and very often the right one, and its price is not money but the fact that your process rules now live in another vendor's settings screen.

The second route barely appears in comparisons at all, although it is the one we sell most: an off-the-shelf tool with our own code on top. WooCommerce is open-source PHP, so a reseller price table, a credit check or a stock reservation can be written next to the core rather than bought as a plugin, and there is no licence for it — there are hours — at the price that this code stays tied to WooCommerce's update rhythm and to the way that platform stores orders. A considerable part of what our price list calls the Pro version at €9,500 is exactly this work, and this is where most of our own stores sit.

The third route is our own platform, in which the catalogue, the cart, the checkout and the pricing logic are written from a blank page around your process; it is the most expensive start and the only one with no other vendor's assumption inside it about what a product is and when an order becomes an order. Inside the third route there is a fork: Bagisto and Lunar are MIT-licensed Laravel commerce packages — 27,943 and 3,588 GitHub stars respectively on 6 August 2026 — that hand you a catalogue and a cart already written, in exchange for one more external dependency whose rhythm is not in your hands. We do not take it.

How much do WooCommerce plugin licences cost a year?

For a store with seven hundred products and three reseller tiers, the first route cost €270 a year on 6 August 2026 for two public prices plus an unknown third. Dynamic Pricing at €113 a year gives quantity and role-based discounts; B2B for WooCommerce, built by Addify, at €157 a year gives role-based prices, tiered prices, quote-to-order, VAT exemption and payment and delivery methods restricted by role; but for stock across several warehouses the core provides nothing at all, so a third paid plugin joins them, Addify Multi Inventory Management for instance, for which the vendor names no public annual price.

That €270 a year is a little more than five development hours, because a development hour in our price list costs €50, and for features that come with a vendor, documentation and updates, it is cheap. A price you cannot know before the conversation is nonetheless not a line in an estimate: the warehouse plugin lifts that figure, and by how much depends on the quote that will reach you once you have named your number of warehouses and your order volume.

For another store the lines are different: one selling subscriptions, bookings and membership tiers pays, at those same marketplace prices, €245 a year for WooCommerce Subscriptions, €218 for Bookings, €175 for Memberships, €140 for AutomateWoo and €70 for Product Add-Ons — €848 a year in total. Over five years, if the prices do not rise, that is €4,240: nearly the whole price of a Basic version store, which in our price list is €4,500, and nearly half of the Pro version at €9,500. This line does not amortise, because it is for one site, for one year, and it is paid afresh every year.

The same figure the other way round is nearly 85 development hours at €50, and those are hours that stay in your code and belong to you, rather than reappearing on next year's invoice. That particular €848 bill is moreover the bill of a subscriptions, bookings and memberships store, not a norm — there is no norm here, and every store has to add this line up out of its own process. The licence line also comes on top of the build rather than instead of it: in both cases somebody built the store first, and in only one of the two does an invoice for what was built arrive again next January.

What the invoice does when you stop paying it

If the subscription is not renewed, the WooCommerce.com documentation says so plainly: "the extension or theme remains installed on your site but will no longer receive updates" — the plugin stays installed, the store keeps trading, and the only thing that disappears is updates. The consequence of a lapsed licence is therefore not downtime you notice the same day, but an unpatched piece of code that is still processing payments; one subscription moreover covers one production site and one staging site, and subdomains count separately.

One line behaves differently, and behaves the same way on both sides: an accounting connector is usually not a licence but a subscription that climbs with the number of orders — MyWorks Xero Sync on the WooCommerce marketplace starts at a free tier and is priced by volume from there, so this line grows precisely when the store grows. A custom platform does not take it away; it changes who maintains the connector, and in our case that is hours. Nor should the lines be inflated: multi-language operation is not automatically €99 a year for WPML Multilingual CMS, because Polylang stands next to WPML — but the cheaper WPML licence, Multilingual Blog at €39, has no e-commerce support, so for a store the choice between €39 and €99 does not exist.

Why the difference shows up in the second year

That the price of change is a real rather than a theoretical expense is demonstrated by the platform itself: since 2023 WooCommerce has removed two load-bearing parts, withdrawn one beta feature and changed one default. The Legacy REST API left the core on 11 June 2024 with version 9.0, having been marked deprecated as far back as version 2.6 in 2016; the bundled PayPal Standard gateway was removed in version 8.9 in May 2024; the product editor beta was removed in version 11.0, which appeared in the directory on 4 August; while HPOS order storage became the default for new installations in version 8.2 in October 2023 and leaves existing stores alone until somebody migrates them.

Against that background, the Advisories section of the WooCommerce developer blog carries 37 posts in the twelve months to 5 August 2026 — roughly three a month — and each of them has to be checked against every extension installed in the store, which a store with four plugins absorbs without effort and a store with twenty does not. Nor does the pile accumulate in a single day: plugins arrive one at a time, each of them individually a perfectly sensible decision, and the multiplication of combinations to be checked happens quietly.

Ten plugins are not ten parts but ten contracts, each of which can end separately, and the owner changes even when there is nothing wrong with the code at all. On 31 October 2025 the review service Judge.me switched off its WooCommerce integration together with Square, Squarespace, BigCommerce, Duda and PrestaShop: the data was accessible until 19 November, after which access was removed irreversibly, and review videos were not included in the export, so a marketing asset built up over years was left partly on the other side of the door. The quieter cases make the point better: in 2019 Automattic bought Prospress, the author of WooCommerce Subscriptions and AutomateWoo, in 2020 GoDaddy bought SkyVerge, whose more than sixty plugins were used by more than 100,000 merchants, and both deals, as far as anyone can tell from what is publicly known, ended well for merchants. The question is not damage; it is that the owner of a component of your store can change without your participation.

How large that risk really is

Scale puts it in proportion, and the numbers here are our own: in a 6 August 2026 enumeration the WordPress.org plugin API returned 7,764 plugins tagged "woocommerce", of which 23.1% had not been updated for two years or more, but in that same enumeration 10,809,800 active installations sit on plugins updated within the last six months and only 208,790 on plugins untouched for more than three years. Plugins with 10,000 installations or more that have gone two years without an update come, in that same enumeration, to exactly six.

The abandoned plugin is almost never the popular one everybody knows: the risk sits in that one narrow module your particular process demands — in B2B pricing tiers, in a warehouse connector, in one courier's label generator — and the further your process is from the average, the closer you are to the part of the directory where the last update is from the year before last. This line can be brought down without rebuilding anything: under a maintenance contract we do it — we reduce the number of plugins, configure updates and keep monitoring in place — and a rebuild is the answer only once the problem is no longer maintenance but the fact that the process is written down nowhere.

Where the shape of WooCommerce's data starts to press

The second place where the second year costs money is the shape of the data, and first the side on which this argument is no longer true: orders in new installations have lain in four tables of their own since version 8.2, and the company's own March 2023 benchmark shows the new storage speeding order operations up rather than slowing them down. What presses is the product side, and it was written up best by WooCommerce's own engineers, explaining the 3.6 performance improvements on 1 April 2019: products and variations go through the WordPress post system, in which post meta is extraordinarily flexible but "not that efficient when we need to sort or filter by many meta values at once". The answer in that same release was wc_product_meta_lookup, a denormalised helper table holding SKU, price and stock status next to post meta rather than instead of it, so the underlying shape stayed as it was.

The equivalent work on the product side, woocommerce-product-tables-feature-plugin, has lived on GitHub alone since 16 October 2017 and is not abandoned — the last changes are from 31 July 2026 — it is simply still not judged stable enough for the WordPress.org directory. Next to it stands wp_options, whose autoload column has no index by default, whose autoloaded data is read on every page load, which WooCommerce itself recommends keeping under roughly 500 rows, and whose growth is caused precisely by extensions, plugins and themes — the same pile discussed above, seen from the database side.

What Laravel gives a store that an off-the-shelf tool does not

Laravel is not a store and does not pretend to be one: it hands you named, documented, MIT-licensed parts out of which somebody assembles a store, so the question worth money here is not "is the framework any good" but "which parts of your process finally become your own tables and your own jobs". In a distributor's store the answer is usually four lines — the reseller price table, the credit limit, the stock reservation and the accounting sync — and in an off-the-shelf tool those are precisely what you buy from four different vendors and afterwards reconcile with one another.

Before that it is only fair to say what this route does not give, because Laravel gives none of those four either: the framework's official starter kits give you authentication and nothing more — no catalogue, no cart, no checkout step, no warehouse — and the one commerce package that comes with it is Cashier, which serves subscription billing on the Stripe or Paddle side and expects products with prices to be described in the payment provider's dashboard already. What Laravel does give is a shape in which those four lines are cheap to write and cheaper still to change later.

Queues, transactions and the shape of your own database

The first part is queues: one API over several engines — Redis, the database, Amazon SQS, Beanstalkd — that lets order processing, ERP sync and email leave the request, so that the buyer no longer waits while the accounting system answers. The documentation also names what decides a real implementation: job chains and batches, unique jobs a queue will not run twice, retries, and failed-job storage from which they can be released again. An order processed twice is an invoice somebody has to cancel afterwards, and a customer who notices it before you do.

Horizon shows queue throughput, run times and failures, lets the worker configuration be described in code and warns when a queue waits too long, but it requires Redis and does not work with Redis Cluster at present, which makes it a separate line on the hosting bill rather than a free extra. Transactions, in turn, are what the sentence "the order and the stock movement both happen or neither does" means in practice: DB::transaction rolls the changes back itself on error and lets them be retried if the database reaches deadlock.

Migrations are what the Laravel documentation calls version control for the database, and in practice that means you design tables, indexes and foreign keys around your own pricing and stock logic rather than around what somebody else once decided a product was. Search and subscription billing also stay a choice rather than a compulsory monthly line: Scout indexes in the database itself with MySQL or PostgreSQL full-text indexes and no external service, while Cashier serves the Stripe side if the store has subscriptions at all.

A price table, a credit limit and a reservation in code

What that looks like concretely is shown best by the first of the four lines. On your own code a reseller price table is one migration with four columns — customer group, product, quantity threshold and price — and a unique index across the first three, so the price for a particular buyer is found by one query with one join rather than by a search through meta values; a new price tier is a new row in a table rather than a new setting in another vendor's screen. When a fourth tier arrives a year later with a different rounding rule, one place and one test change, and both of them are in your repository.

The credit limit and the stock reservation are the same idea one step further on, because there too everything rests on one table and one transaction: the sum of unpaid invoices is a column on the customer, and the check happens inside the same transaction in which the order is created, so two orders submitted at the same moment cannot both slip under the limit, while a deadlock simply retries the transaction. A reservation, in turn, is a row with an expiry that comes into being with the order and disappears through a scheduled background job if the order goes unpaid, so the stock figure is no longer a number two buyers can empty at the same time.

The accounting sync is a queued job marked unique, so a retry never issues an invoice twice, and when Horizon shows you in the morning that the accounting end was down overnight, failed-job storage lets those jobs be released again in order instead of being retyped by hand. Each of these four lines is available in an off-the-shelf tool as well, only as a vendor's settings screen whose rules you cannot see, which has to be re-checked after every update, and which does not travel to another platform.

Two builds already running

What it looks like in a project rather than in documentation can be seen in our own Laravel work. On the LIDO food ordering platform the price is decided not by the product but by the address: geolocation determines the delivery zone, the distance and the fee, each of the thirteen restaurants has a menu of its own, and alongside the store runs a separate process automation system that receives every order and distributes it between restaurants and chefs — with integrations into more than ten other systems, Wolt, QWQER and RKeeper among them. The Riga Lashes store on Laravel has variant prices, customer accounts, a wishlist and the studio's service price list, and behind them warehouse stock, courier integrations and payments, with the process automated all the way to the packing stage. In both cases the decisive part would have had to be written on an off-the-shelf tool too, only inside another vendor's price and order shapes, and that is exactly the difference that stays: on your own code this work is one repository with no separate subscription for each capability, and it does not have to be re-checked after every platform update. We have been writing Laravel since 2013, and most of our custom systems, public-sector portals and B2B platforms run on it.

Where the money goes when it is not going on licences is a concrete question, and the answer is just as concrete: the nearly 85 hours that the €848 annual licence line costs over five years are, on your own code, precisely this price table, this credit limit, this reservation and this sync, written around your process. They stay in your repository even if we one day stop being your partner: in a commissioned build the code is yours from the first day, and that is written on our Laravel service page too.

Filament: the admin panel nobody writes from scratch

The admin-panel half of the objection that everything has to be written from scratch in a self-built system is taken away by Filament, an open-source interface framework for Laravel applications. Resources generate CRUD screens for Eloquent models, the table builder gives filtering, sorting and pagination, form components arrive with validation built in, while Filament reads access rights straight from Laravel's model policies, so role checks do not have to be written a second time. Relation managers, dashboard widgets and notifications are in the same box; so is multi-tenancy, though with Filament's own warning that it is a set of tools rather than a guarantee and that separating tenants' data is the implementer's responsibility; the whole layer is MIT licensed, as Laravel itself is, so there is not a single licence fee in it.

What matters most, though, is not what the framework draws but where the money it frees up goes: product editing screens, order tables, filters and permission checks are the part of development the buyer never sees and the client nonetheless pays the full rate for, and when a framework supplies them, the budget goes to the pricing, order and stock logic that custom development was chosen for in the first place. The example is where you are reading this: this site runs on Laravel 13 and Filament 5, and all editorial work in twelve languages happens in a panel we configured rather than wrote from scratch.

Where the framework ends and the store begins

Filament is not a store, and this boundary is worth drawing clearly: the framework gives you an admin panel — screens, tables, forms and permission checks — but knows nothing about what is in those tables or by what rules it got there. A product catalogue with variations and attributes, the cart, the checkout step, pricing rules with customer tiers and quantity discounts, the order lifecycle from creation to return, and stock reservation in the warehouse — none of that is in the Laravel and Filament box. Filament is like a fitted-out workshop with shelves, benches and good light; what to make in it does not come in the box.

How literally that is meant is shown by the documentation itself, in which Order and Payment models appear only as examples a developer writes themselves, because the framework simply has no such classes. That is not a shortcoming in the framework but a division of labour: Filament promises an administration interface and nothing else, exactly as Laravel promises a framework rather than a finished application. In practice it means that Filament shortens the administration work and shortens nothing at all in the part that custom development was chosen for.

That is why the Basic version of a store in our price list at €4,500 comes without the warehouse module, multi-language support, B2B pricing tiers, the discount system and content migration, while the Pro version at €9,500 comes with all of them. The difference is not a markup for more modern technology but the price of what somebody has to write, and that is exactly why it is the same on both platforms. A fixed-scope Laravel system from €8,000 is a different line and a different product in the price list: not a store but a system in which the whole process is built from a blank page.

What we do not promise: where building it yourself costs more

A self-built store is free of annual plugin licences, not of maintenance, and those are two entirely different things. Laravel gives each release 18 months of bug fixes and two years of security fixes, ships a new major version once a year, and has no long-term support tier, so the dates are specific: Laravel 13 came out on 17 March 2026 with security fixes until 17 March 2028, Laravel 11's security window closed on 12 March 2026, and Laravel 12's bug fixes end on 13 August 2026. Once every year or two the system therefore has to be moved to a new major version, and the Laravel documentation says they strive to make that possible in a day or less — an effort, not a promise about how long it will take on your system.

The PHP treadmill is moreover identical on both sides: each version gets two years of active support and two more of security fixes only, so a five-year window contains at least one and, depending on where in the cycle you start, up to two forced PHP migrations regardless of what sits underneath. Neither a WooCommerce nor a Laravel store escapes this line, and in both cases it is planned by the same person who plans the rest of the maintenance — the only difference is that on your own code the migration can be done when it suits you rather than when some extension stops supporting the old version.

Three lines where the off-the-shelf tool wins

More expensive than maintenance are three other lines, and the first of them is the ecosystem: here the off-the-shelf tool wins without discussion. One more marketing automation in a WooCommerce store is a marketplace entry — AutomateWoo, for instance, costs €140 a year — and, in our experience, a day's work, whereas in a self-built system it is a specification, hours and a test, and at €50 an hour it is the first feature about which you will ask whether it is really needed. A product field or a new filter in the admin is not on that list, because the framework supplies it. The absence of an ecosystem is not a one-off cost but a permanently higher threshold for everything you later want to try, and for a store that experiments a great deal it can outweigh the licence bill — which is precisely why we do not call the licence bill the main argument.

The second is dependence on one team, and what answers it is structure rather than assertion: in a commissioned build the code is yours from the first day, we write it in the standard Laravel structure with no exotica, the critical logic has tests, and a documented README and CI come with it so that somebody else can take the system over. Laravel developers are easy to find in Latvia, which is why our own answer to the question of why Laravel ends with the sentence that you are not left dependent on one team, ours included — and that does not remove the risk, but it makes it transferable.

The third is PCI DSS, and it is against us. For merchants whose payment page is delivered entirely and directly by a PCI DSS compliant service provider, and who have themselves confirmed that the site is not susceptible to script-based attacks, the SAQ A revision published in January 2025 and effective from 31 March 2025 removed requirements 6.4.3 and 11.6.1 — the script inventory, its justification and change monitoring — and requirement 12.3.1 on targeted risk analysis, while stating that it does not remove the PCI DSS requirements themselves. That relief describes a small WooCommerce store with a bank's payment page far more accurately than a checkout step we render in our own code, and next to it stands a second, equally uncomfortable fact: the March vulnerability was found and fixed by somebody else, whereas in a system we have written it is our team that does it, which makes maintenance there a contract line rather than an assumption.

Our own dependencies are not a different species

Filament is exactly the same third-party dependency as the plugins just discussed, and the difference between them is one of degree and position, not of principle. It is one MIT-licensed dependency in the development layer, its code sits in our repository and can be forked, and it does not stand in the buyer's checkout path, because it draws the admin panel rather than taking the payment.

If the project stopped tomorrow, the store would carry on taking orders, and what would age is the part your staff see, not the part that takes money from the buyer. Filament also publishes a version support table with specific dates: version three came out in August 2023 and receives security fixes until 1 January 2028, which is a longer window than Laravel gives its own releases.

Filament is nevertheless not a Laravel first-party package, because Laravel does not name it in its own package list, and behind the project stands not a company with a balance sheet but a team around one maintainer: some 17,000 contributions in the repository are in his name, against roughly 2,400 for the next contributor, and the funding comes from GitHub sponsors and paid consulting. The release rhythm is not gentle either: version four came out in August 2025, version five already in January 2026, two days after Livewire 4, which is one more third-party dependency underneath it. And the sentence "we will fork it if we have to" is cheap to write and expensive to carry out.

We do not offer a store with no third-party dependencies, because neither we nor anybody else has one; we offer a smaller number of them, a licence that lets the code be kept and maintained by us, and a clear line between what stops the cash flow when it fails and what ruins an employee's working day. If that difference does not strike you as large enough, it is an entirely reasonable objection — and then we build you the off-the-shelf tool, because it is the same Basic or Pro version at the same price. Neither of the two answers makes us the wrong partner.

How we make this choice in practice

What you buy along with a platform is the answer to one question — who is allowed to change your pricing and order rules, and on what schedule — and on your own code that answer is "you, next sprint", while on another vendor's extension it is "when the vendor puts it into a release, if they do". That is why in a discovery conversation we do not ask about turnover; we ask how many price tiers you actually have and whether one customer ever sees a different price from another — that is the boundary between the two price fields WooCommerce gives you itself and a price table somebody has to maintain.

Then we ask whether the stock figure lives in more than one place, because a warehouse plus a store shelf is two places already, and two places mean that somebody has to decide which of them counts as the truth. The next two questions usually decide everything: does an order become an order straight away, or does it first need an approval — from the client's purchasing department, from your sales manager or from a credit limit — and would the process still work if the catalogue doubled.

If the answer about approval is "yes", you are in the place where the off-the-shelf plugin market is at its weakest: credit-limit monitoring and blocking orders above the limit are in neither the core nor the mainstream B2B suites, and only a few specialist listings promise it, QuarkCode B2B Commerce Suite among them. How much of the process you are prepared to remake around the tool is the question that remains, and unclear requirements are the most expensive mistake in the whole commission, which we have written about separately.

If the answers fit inside the off-the-shelf tool, take the off-the-shelf tool, because it will be cheaper, and we will build it for you. If one or two of them do not fit, you are most likely on the middle route, and in the price list that is the same Pro version at €9,500 on WooCommerce — the same price as on Laravel, because what costs money is the work, not the platform. If three or more do not fit, and particularly if an approval step or a credit limit is among them, the conversation is no longer about a platform but about how much of the process lives in code we can change without agreeing it with another vendor.

Three starting points and what each of them costs

In practice we sell three starting points, and each of them has a price you can work out. The first is to start with the catalogue, payments and delivery, go live, and add B2B prices, discount logic and warehouse integrations once the first real orders are visible — in our own answers we call this the usually right choice. The second is to move an existing store, and that is a project rather than a switch: we keep the URL structure, but data models do not map one to one, and every plugin that stored fields of its own has to be assessed separately. Migration is included in the Pro version and in the rental; it is not in the Basic version, and we estimate it separately by volume, because the price is decided by the amount of data and the number of fields.

The third is rental: a Laravel store together with our hosting from €130 a month plus a €600 one-time setup fee, and in the price list its contents are the same as the Pro version's — warehouse module, multi-language support, B2B pricing tiers, discount system and content migration — only with hosting, updates and maintenance on top; it is available on Laravel alone, because a WooCommerce store cannot be rented from us. The choice of platform does by itself decide a few specific things that work does not level out: this rental line, the free automatic core patches, the ecosystem threshold, and who has to agree before your next change reaches production. Everything else is work.

Rental starts from €130 a month, which over five years is from €7,800, plus €600 for the setup — from €8,400 — and it includes hosting, updates and maintenance. The Pro version costs €9,500 once, and hosting comes separately with it: our infrastructure rental starts from €45 a month, so from €2,700 over five years, from €12,200 in total, and application updates are not inside that yet. Both figures are floors, not totals, and they are comparable because the price list gives both the same set of features. In the rental you pay for use together with hosting; in a build you pay for the system at once, and comparing the two floors, the rental starts lower over a five-year window. Where each of them ends is decided by scale, which is why we estimate both for the project rather than reading them off the price list.

After that the work runs in two-week sprints with a demo after each of them; payments, delivery services and accounting are connected and tested before launch; products, customers and order history are carried over with the URL structure preserved. For larger non-standard work we work time and materials with a weekly cap, because a fixed price there usually means either a markup for risk or an argument about scope, and the hourly rate in the price list is €50. The whole route takes 8–32 weeks. Get a project estimate and a technology recommendation — answer the same questions for us, and we will tell you which of the three routes costs less in your case.