What an Online Store Costs, and What Raises the Price

€4,500 is a real figure, but it is not the only one. What raises the price from Basic to Pro, what does not, and when rental is a starting figure, not a promise.

A client opens a quote, sees €4,500 and asks the question almost everyone asks: what an online store costs. The answer they expect is one number, but the number they then live with is another — the one that remains when a warehouse, a second language or an accounting invoice is added to what the Basic version deliberately leaves out. This article is about what creates that gap, and about when the gap is not worth buying, because the cheaper line that does not match the process becomes, after launch, the most expensive mistake you can make on the project.

Three prices already written down, and what they are not

Our e-commerce development page carries three lines, and they are not hidden behind “by agreement”: the Basic version costs €4,500 as a one-time payment, the Pro version costs €9,500 as a one-time payment, and rental starts from €130 a month plus €600 for setup and is available only on Laravel together with our hosting. The service card above them says “from €4,500”, because that is the cheapest published start, not because Basic itself is a starting figure, and treating that figure as one means turning a price list into a promise we have not made. Basic is €4,500; “starts from” belongs on the rental line.

All three lines are indicative and exclude VAT, and we prepare a precise quote after discussing scope, within five to ten working days — this sentence is written under the price list not as a courtesy, but as the boundary between a published guide and a contract. The Pro version has one more line that is often skipped: it can be paid in instalments over up to twelve months, with a fifteen per cent instalment handling fee on the contract value and with a personal guarantee, and if the contract were exactly €9,500 the fee would turn it into €10,925. That is an example with this sum, not a new price-list line, and without the guarantee there is no splitting at all.

These three prices belong to the store product, not to everything we sell, and mixing products here is the same as comparing a store cart with a system that has no cart at all. A fixed-scope Laravel system starts from €8,000, and it is a different product: a system in which the process is built from a blank page, not a store with a catalogue, a cart and checkout. The hourly rate of €50 belongs to that other product, to work on time and materials, not to a top-up with which Basic could be “patched” until it becomes a system. Infrastructure rental starts from €45 a month and is a separate page, not a third column of the store package, while WordPress website development starts from €2,500 and is a different object that does not belong to this question.

A person who reads these lines as a menu usually picks the cheapest and then wonders why the quote is different, because they have chosen a number, not a process. A person who reads them as a map first asks which of the five lines missing from Basic they actually need, and only then looks at the number. The second reading is the one this article is written for, because the first reading has already been done on the service page and does not need three thousand words to repeat what already stands there.

What raises the price inside Basic: five lines, not catalogue size

Basic is not separated from Pro by the platform or by the number of products, because both versions are available on WooCommerce and on Laravel, and both include unlimited SKUs, payment integration with Makecommerce or Stripe, search-engine optimisation and an admin panel. The difference is five lines that stand as missing on the Basic list: a warehouse module, multi-language support, B2B pricing tiers and integrations, a discount system and content migration. Pro includes all of them, and the rental’s contents in the price list are the same as Pro’s, only with hosting, updates and maintenance on top, so a person who rents in order to “avoid Pro” is still buying the Pro contents, only on a different rhythm.

These five lines are what raise the price inside the store product, because each of them is work that somebody has to write and test, not a markup for more modern technology. A warehouse module means the stock figure is no longer one number next to the product, but a truth that lives somewhere else and that the store has to reflect in the second the buyer presses the button, otherwise two buyers can purchase the last unit at the same time. Multi-language operation means not only a translation, but a catalogue in which one product exists in several languages without breaking the addresses by which Google already finds it. B2B prices mean that two signed-in people see two different prices for the same line, and a discount system means those prices still change by quantity, period or cart contents, therefore by rules the store has to execute itself, not rules the buyer has to guess.

Migration is the fifth line and the one people most often imagine as copying files, although products, categories, customers and order history have to be moved so that the addresses stay the same, because otherwise the search rankings the store has already paid for with time disappear. In the Pro version and in the rental this work is included; in the Basic version it is not, and we quote it separately by the volume of data and the number of fields, because a hundred products with one image is not the same work as seven hundred products with variations, customer groups and five years of order history. The person who will “move it themselves” usually values their time as free, until they have spent a week lining up fields that carry the same name in both systems and mean something different in each.

We ourselves usually recommend starting with a basic catalogue, payments and delivery, going live, and adding B2B prices, discount logic or a warehouse once the first real orders are visible, and that is not an exercise in modesty, but a way of not paying for Pro for a process the store is not even doing after three months. If a second language or a second price table is needed on day one, then Pro is not “a more expensive Basic” but the right line, and hiding it behind Basic so the quote looks better means one argument after launch in which both sides will be technically right and both will remain dissatisfied. Honesty here is cheaper than a discount you later have to take back.

What does not raise the package price

Catalogue size does not raise the package price, because unlimited SKUs are already inside the Basic version, and a store with forty products and a store with four thousand cost the same on this line. What starts to cost money at four thousand is not the number of rows, but whether those rows also live in a warehouse, in a second language or in a second price table. A person who hears “large catalogue” and immediately hears “Pro” is mixing volume with process, and that mix-up is expensive precisely because it looks reasonable and is easy to sell, including to yourself.

The platform does not raise the package price either, and WooCommerce or Laravel — which to choose, and when — is a question we have answered in a separate article, and this article’s job is not to rewrite it, because that article already says what this one must not repeat. In the price list Basic is €4,500 and Pro is €9,500 on both platforms, because what costs money is the work, not what sits underneath. What the platform does decide are other things: the rental line is Laravel only, automatic core patches sit on the WooCommerce side, and who is allowed to make your next change is a question about the code, not about this article’s figures.

A courier connection is not a warehouse module, although the two lines often melt into one in conversation, because both touch “goods leaving the house”. An Omniva, DPD, Latvijas Pasts or Venipak interface means a shipment can be created, tracked and handed to a parcel locker; a warehouse module means the stock figure is true at the moment a shipment is allowed to be created at all. In the Riga Lashes store, which we maintain on Laravel, these are two different things in one sentence: product inventory and integrations with courier services, plus payments and a process automated as far as packing. Mixing them means either overpaying for Pro when only a shipment interface is needed, or staying on Basic with a courier and wondering why the stock in the store does not match what is on the shelf.

Horizon, Jumis or another accounting system is not inside Basic either, although we work with them regularly and that remains true even when those lines are not in the particular contract. In the price list Basic includes custom integrations on request, and that means a quote, not a gift, because a published interface is not yet an integration: somebody has to line up what the store calls a product with what accounting calls a stock item. If accounting is the place where the truth about stock lives, then this line has to be named and priced separately, not imagined as part of the €4,500, because otherwise the quote and the hope already differ before the first sprint.

Build versus rental: starting figures only

Rental looks cheaper until you add it up over years, and more expensive the moment somebody forgets the words “from”. €130 a month over five years is €7,800, plus €600 for setup, so from €8,400, and that is a starting figure, not a total, because rental starts from €130, it does not stop there. 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 starting figures, and they are comparable only because the price list gives both the same set of features, not because either of them is an invoice you can sign without a discovery.

Rental is available only on Laravel and only together with our hosting, and this boundary is not a matter of taste: on the rental line we are responsible for the environment, updates and maintenance, and we take that responsibility only where the code and the server are in our hands at the same time. You cannot rent a WooCommerce store from us, and if you need to stay on WooCommerce or keep the server yourself, the rental line does not fit you no matter how attractive the monthly figure looks, because the monthly figure here also buys the environment, not only the software.

Comparing starting figures is honest; turning them into a promise that over five years rental will cost €8,400 is not, because scale lifts rental just as it lifts a build, only in a different place — more integrations, more languages, more custom logic. In the rental you pay for use together with hosting; in a build you pay for the system at once and then separately for it to stay alive. Where each of them ends is decided by scope, which is why we quote both for the project rather than reading them off the price list as a final invoice, and the person who asks for “an exact five-year total right now” is asking for what the price list deliberately does not give.

Rental is right when you want the Pro contents without a one-time €9,500 and you are prepared to stay in our environment, and it is not right when the aim is to come in cheaper than Basic, because the rental’s contents are not Basic’s contents. The person who rents in order to avoid Pro is usually avoiding the wrong number: they are still paying for the warehouse, multi-language operation and migration, only by the month, and after a year they discover they have bought the same Pro, only on a different rhythm. If the rhythm suits you, rental is a good instrument; if the rhythm is only a way of not seeing Pro, the instrument is working against you.

When a store is no longer a store

There is a moment when the conversation about Basic and Pro becomes pointless, because what has to be built is no longer a catalogue with a cart. On the LIDO food-ordering platform the price is not decided by the product but by the address: geolocation determines the delivery zone and the fee, each restaurant has its own range, and alongside the orders runs a separate process automation with integrations into more than ten systems, including Wolt, QWQER and RKeeper. That is not a Pro store with a few extras, but a process for which the store metaphor has become too narrow, and in such cases the price list has a different line; hiding it behind the name of a store means selling the wrong product with the right smile.

A fixed-scope Laravel system starts from €8,000, and this “from” is real: scope, timeline and price are fixed before the work, but the starting figure itself is not the store’s Basic and is not the store’s Pro either. The hourly rate of €50 belongs to the same layer, to time-and-materials work with a report every month and with no long-term commitment, not to a store package. Mixing this rate with a store package means imagining that €4,500 is ninety hours that can be added until a system appears, although what appears is only an unclear contract in which both sides count differently what has already been paid.

The boundary can be spotted from the question, not from turnover, and that matters, because turnover does not lie here, but it does not decide anything either. If you need a catalogue from which the buyer themselves chooses, pays and receives a shipment, you are still in the store product, even if the catalogue is large. If an order becomes an order only after a zone, after a chef, after another system’s confirmation or after a logic for which a ready-made store has no word, you have crossed the boundary. We do not hide this boundary in order to sell the more expensive line; we name it so that we do not sell a store where a store will not survive the first real week.

This is also the place where honesty and persuasion pull in opposite directions, because the store page looks more saleable than the system page, and it is more pleasant for a person to hear that this is Pro with a few integrations than to hear that it is no longer a store. We say the second sentence anyway, because the first sentence becomes a reproach after launch, and a reproach about the wrong product is more expensive than a lost quote. If this distinction strikes you as too sharp, that is a sign the boundary is already close, not that we have invented it in order to complicate a simple project.

Eight to thirty-two weeks is not the sum of four phases

The timeline we publish is eight to thirty-two weeks from discovery to launch, depending on scope, and the process is discovery one to two weeks, design two to three, development four to ten, then launch in a planned window and the first thirty days on heightened standby. If you add those phases together you get seven to fifteen weeks plus a launch for which no week-count is written, and that is not the same figure as 8–32. Adding them up in order to explain the published range means inventing arithmetic the price list does not contain, and then wondering why the project did not fit the promise, although the promise was not a sum.

Week eight is possible when the scope is Basic, the content is ready and the integrations are the ones already included; week thirty-two appears when the migration is large, there are several languages, accounting has to be lined up with the store, or the process changes along the way. Time raises the price not because a week is itself a line on the price list, but because a longer road almost always means more decisions that nobody had named in discovery. That is precisely why the end of discovery is, for us, a clear scope and price, not a rough guess: until that has happened, any timeline is a wish, and we do not sell a wish as a schedule.

Waiting for content is the place where the schedule slips most often, and it slips before the code, not in the middle of it, because until there are texts, images and product data the design stands still, and while the design stands still development does not start. A short timeline is not earned at this point by faster work; it is bought by skipping a check or launching a store in which half the catalogue is still placeholders. We do not do that, even if the quote therefore looks slower than a promise a competitor has written without a content list, because a store that opens empty is not fast — it is unfinished, and a buyer notices an unfinished store faster than a schedule.

Starting smaller is also a timeline instrument, not only a price one, because a store that launches with a catalogue, payments and delivery fits the shorter end, and the Pro lines can come when they are no longer a hypothesis. A store that wants all five Pro lines plus accounting on day one stands at the longer end, and that length is honest. Hiding it so the quote looks faster means moving the delay into the week in which you have already promised advertising, and then the delay is no longer a question of our schedule, but a question of your campaign.

What an online store costs after it is already open

There are costs that do not raise the package and that still have to be paid even if you stay on Basic, and they are not a fifth version, but duties without which a store may look finished and may not be opened to consumers. The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 require that, before a distance contract is made, the buyer can clearly see the trader’s identity, the final price including taxes, the delivery costs, the right of withdrawal with the model cancellation form, and how the order will be fulfilled. That information forms part of the contract, and proving that it was given is the trader’s work, not the buyer’s.

On a website this becomes work on particular screens: immediately before the order the price and delivery must be visible, the button must say that the order creates an obligation to pay, otherwise the order does not bind the buyer, and delivery restrictions and means of payment must be stated no later than the start of placing the order. This is not a question of plugins and is not an argument for moving to Pro, but text, the wording of a button and the order in which the price appears, and this work already belongs in the first launch, because otherwise the store is opened in breach of rules that Trading Standards enforce.

The consumer’s right of withdrawal is fourteen days, not fourteen working days, and for goods the period is counted from the day the goods come into their possession; if the information about the right to cancel is not given, the consumer may cancel at any time in the following twelve months, and if you tell them during those twelve months they have fourteen days from when you told them. Exceptions exist — goods made to the consumer’s specifications, clearly personalised goods, a sealed hygiene pack once opened — and they must not be invented wider than the regulations allow, however convenient it would be to announce that “this store does not accept returns”. Confirmation of the contract must be given on a durable medium, no later than delivery, and all of this is Basic-store work exactly as it is Pro work, because the law does not touch the name of the package.

Two VAT conversations must not melt into one here, because they belong to two different contracts. Our price list is exclusive of VAT, and the invoice to you will come with the tax separately; that is our contract with you. For the store’s buyer the final price must already include taxes, and the standard rate on the supply of goods and services in the United Kingdom is 20 per cent, as GOV.UK publishes it, although reduced rates exist for particular goods and to say that everything is 20 per cent would be a false shortening, so the price the consumer sees and the price you see on our quote remain two different columns.

The structured electronic invoice is the third line that older press articles still date wrongly, although the United Kingdom has no B2G mandate equivalent to a 2025 duty to issue invoices in the EN 16931 format. GOV.UK has announced that VAT invoices will have to be issued as e-invoices from 2029, which is not a duty for every store to produce e-invoices for consumers from tomorrow, and EN 16931 remains the European format if you sell into the EU. It is a reason to keep the accounting question open if you sell to government now, to companies soon, or to buyers in a member state that already requires the file, and it is not a reason to start with Pro if the buyers are people who need a fourteen-day right of withdrawal, not an EN 16931 file.

Cookie consent is another line this article does not rewrite: if the site measures visitors or shows third-party tools, the banner is not decoration, and what has to be in it we have written separately. This work does not belong to the Pro version either, because it belongs to any site whose cookies are not limited to the strictly necessary ones, and a quote that forgets it is not cheaper, but incomplete.

When Basic is enough, and when we do not say so

Basic is enough when the process fits inside a catalogue with one price, one language, payment and delivery, and when the stock figure can live in the store itself while orders are still few. For a very small store with standard processes we say so, and we say so even when a Pro quote would look more impressive, because selling Pro for a process that is not there means one client who after launch asks what they paid the extra five thousand for. That question is deserved, and we would rather not hear it, even if it means a smaller line on this quote.

Pro is worth it when one of the five lines is needed on day one, not when we grow, because a second language, a second price table, a migration from a live store or a warehouse without which you may not sell are not future features. They are first-day features, and hiding them inside Basic so the figure stays €4,500 means moving the argument into the week in which the store already has to open. Rental is worth it when the Pro contents are needed but a one-time €9,500 is not, and when Laravel plus our hosting suits you; it is not worth it as a substitute for Basic, because it does not buy cheaper contents, but a different payment rhythm for the same contents.

The system line is worth it when the word “store” no longer names the process: as long as we can show a cart and checkout, we stay in the store product, but when the order is a route through restaurants, zones and foreign systems, we call it by its right name, even if that means a larger starting figure and a longer conversation. Honesty here is not a marketing style, but a way for the quote after launch still to be the same quote you signed, and that is the only way this article is allowed to end: not with a summary, but with a choice you can make before somebody has sold you the wrong line.

If you want us to read your process and say which of these lines is yours, write to us. Sometimes the more honest answer is that Basic is enough and that the money is worth saving for the second year, not the first screen; sometimes the answer is Pro; sometimes the answer is that a store is not the product. All three are valid, and only one of them is right in each case, and we would rather lose a quote in which we have named the wrong line than win a project in which that line becomes a reproach after launch.