Algeria AgencyWeb & software
E-commerce: what you are shown is the shopfront, what you are buying is the back office
Every demonstration shows the shop. All the cost and all the risk sit behind it, in the part nobody draws.
When an online shop project is presented to you, you are shown pages: a home page, a product page, a basket. Those are the three easiest things to build and the least decisive parts of the project.
What you are actually buying is a commercial operating system. It keeps a catalogue current, it knows a stock level, it records orders through successive states, it takes money, it handles failures, and it lets somebody work inside it every day.
None of those six appears in a demonstration, and that is exactly where the cost, the risk and the difference between a shop that runs and a shop abandoned after six months all live.
So this article is about the back of the shop. It assumes the channel question is settled — another article in this series deals with what happens after the order — and it talks about what you should insist on before signing.
What you are shown is not what you will use
A shop demonstration lasts twenty minutes and shows a journey that works: a product chosen, a basket filled, an order placed. It is true, it looks good, and it says nothing about the project.
What you will use every day is not that journey. It is the screen where a product is added, the one where a price is corrected across forty references, the one where an order from three weeks ago is found, the one where something is cancelled and refunded.
Those screens exist in every tool and their quality varies enormously. They are also the ones no sales proposal shows, because they are ugly and because nobody asks for them.
So the question to ask in a demonstration is simple and it changes everything: show me how twenty products are added, how a price is changed across a whole category, and how an order is found from a phone number.
If each of those three takes more than a few minutes, you have just discovered your real cost: it will not be on the supplier’s invoice, it will be in the hours of the person doing that every week for three years.
The catalogue is the real work
The most underestimated line in a shop project is neither the development nor the design: it is entering and maintaining the catalogue.
Every reference needs a name, a description, a price, measurements or specifications, at least one usable photograph, a category, and a decision about variants. Multiply by the number of references and you get a figure nobody put in the quotation.
The variants question is the most expensive one when it is badly framed. One colour and three sizes are not four products but twelve combinations, each with its own stock, and that decision structures the whole rest of the system.
You also have to decide who enters it. A supplier billing for data entry will do it fast and badly, because they do not know your products; your team will do it well and slowly, because they have another job. Both answers are acceptable; having made no decision is not.
And plan for maintenance, which is permanent. A catalogue is a living thing: products arrive, prices change, references disappear. A shop whose catalogue is no longer kept does not degrade gently, it becomes wrong — and a wrong shop is worse than no shop.
Stock: one truth, and who holds it
The most structural question in the whole project fits in one sentence: where does the truth about remaining stock live, and who is allowed to change it.
If you also sell in a shop you already have two potential sources, and two sources without a rule produce sales of products that no longer exist. It is the most expensive failure in this trade because it surfaces at the customer.
Three answers are defensible. The website holds the truth and the shop refers to it; the shop holds it and the website receives a copy; or a quantity is reserved for online sale and isolated from the rest. Those are three different systems with three different costs.
The third is by far the simplest and it is nearly always right to start with. It removes synchronisation, which is the permanent failure point of the other two, at the price of a little tied-up stock.
What has to be refused is the absence of an answer. A shop delivered without that question settled will work perfectly for two months, then sell an item sold in store the day before, and you will discover the rule while repairing the damage.
The checkout is a state machine, not a page
An order is not an event, it is a sequence of states: created, paid or not, confirmed, prepared, shipped, delivered, cancelled, refunded. Every transition has to be defined, and every one can fail.
The failures are the real subject. The payment that does not complete but whose amount the bank has already held, the page closed between payment and return, the customer who presses twice, the connection dropping at confirmation.
Each of those produces either a phantom order, a double charge, or a paid order you cannot see. All three are serious customer incidents, and none appears in a demonstration because a demonstration goes well.
The rule that protects you is that an order must exist before the payment rather than after. Created first, paid second, and reconciled by a unique identifier — that is what lets you find the money when the journey was interrupted.
You also have to decide what happens to an order created and never paid: after how long it expires, whether the stock is released, and whether anybody calls back. Those three answers are worth more than half the features on the basket page.
What taking payment online adds in obligations
Accepting cards changes the nature of the project. You are no longer publishing pages, you are operating a financial service, with the responsibilities that go with it.
The direction of the market is clear and dated: over one year the number of online merchants grew 26%, card transactions on the internet 38%, and the amount paid online 179%, while the card base grew only 9%.
The useful reading is the gap between 38% more transactions and 179% more value: it is not only payments multiplying, it is baskets growing. What that changes for your project is the standard of reliability required, because an incident now involves larger sums.
The concrete obligations come down to three things: a unique identifier per transaction, a daily reconciliation between what you have collected and what the platform says it processed, and a written refund procedure.
And a testing requirement we repeat throughout this series: the checkout has to be verified with both of the market’s cards before opening. Authentication journeys and error messages differ, and verifying with only one leaves half the cases never run.
GIE Monétique, 2025 annual balance sheet
Which screen your shop is actually operated from
The obvious half of this question is the customer, and it is well understood. The forgotten half is you.
The internet market observatory published by ARPCE counts, for the second quarter of 2025, some 59.10 million internet subscriptions in Algeria, of which 88.71% are mobile and 11.29% fixed.
On the customer side the consequence is known: the checkout is measured in fields, photographs are judged in a square inch, and the total has to be visible before commitment rather than after a scroll.
On the operating side the consequence is ignored by nearly every project. The person confirming orders often does it from a phone, away from the office, on a Sunday evening. A back office designed for a wide screen is unusable for them at the moment they need it most.
The three operations that have to work on a phone are always the same: seeing new orders, changing the state of one, and finding a customer by their number. Everything else can wait for a computer.
- Mobile subscriptions88.71%
- Fixed subscriptions11.29%
ARPCE, internet market observatory, second quarter of 2025
The back office: the part nobody draws
Over three years, the time spent administering a shop far exceeds the time spent building it. It is nevertheless the only part of the project no proposal details.
Four screens decide that time. The order list, with a filter by state and a search that accepts a phone number. The product page in edit mode, with bulk changes. The stock screen. And the export, which has to exist.
Search by phone number deserves to be required by name, because it is almost never native and it is what you will use most. A customer who calls gives their number, not an order number.
Bulk editing is the second point: changing a price, an availability or a category across thirty references in one operation rather than thirty. That is the difference between an hour and a morning, every week.
And the export has to be requested and tested before signing. A system you cannot get your products, customers and orders out of in a readable file is a system you will never be able to leave, whatever the contract says.
Delivery charges are a rule, not a field
Many projects treat delivery charges as a value to be typed in. It is a calculation rule with several inputs, and writing it badly produces either silent losses or abandoned baskets.
The inputs are always the same: the destination, the weight or volume, the basket value if you waive carriage above a threshold, and the method chosen — home delivery or pickup point.
Destination is the one that takes the most work and returns the most, because the country is not a single market. A grid by zone takes longer to enter and it is the only one that stops you financing distant deliveries out of the margin on nearby ones.
The free-delivery threshold deserves a calculated decision rather than a round number. It has to be above your average basket, otherwise you are waiving carriage on orders you would have collected in full.
And the rule that matters most to the customer is visibility: the total including charges has to be known before commitment. It is the same sentence as in the article written for merchants, and it decides the same thing — a refusal at the door or an abandoned basket, depending which side you look from.
Existing platform or custom build
The question comes up early and it is settled on one criterion: how unusual your selling rules are.
If you sell products with ordinary variants, one price per item and delivery by zone, an existing platform does all of that better than we could write it, for far less, and with security updates you will not have to fund.
A custom build is justified when a rule of your business does not fit: pricing by the metre or by cut weight, a discount per customer, stock shared with a depot, a compatibility constraint between items, an approval step before dispatch.
The trap is choosing custom for a reason of appearance. Every platform can be styled, and paying for a full build to obtain a particular layout is the least profitable spend in this trade.
The mirror trap exists: forcing a real business rule into a tool that does not anticipate it, at the price of accumulated extensions. Three extensions working around one constraint cost more, in maintenance and in breakage, than the build they were avoiding.
What can be measured on a shop
Four figures are enough, and the most important is not revenue.
The first is checkout abandonment, measured step by step. It does not say why people leave, but it says where — and the step that loses most is nearly always the one asking for something before the total has been shown.
The second is the share of orders created and never paid, if you accept cards. It measures the reliability of your checkout rather than your customers’ intent, and it is nearly always higher than the supplier said.
The third is your own processing time: between an order being recorded and moving to prepared. That measures your back office, and it is the figure that degrades as volume rises.
The fourth is the number of manual corrections per week: wrong prices, stock adjusted by hand, orders edited. It is a thermometer for the catalogue, and it rises before anything else becomes visible.
What to check before signing
The first request is not a question, it is an inverted demonstration: have them show you adding twenty products, a bulk price change, and finding an order by phone number. Twenty minutes worth all the rest of the evaluation.
The second is about stock: what is the source of truth, who can change it, and what happens if two people sell the last item at the same time? A supplier with no precise answer has not operated a shop.
The third is about payment failures: what becomes of a paid order whose customer closed the page before returning? The answer has to contain a unique identifier and a reconciliation, not an intention to check.
The fourth is about export: ask to see a file of products, customers and orders exported from an existing project. A demonstration, not a clause.
The fifth is about what is not included: catalogue entry, photography, the zone-based charges grid, annual maintenance. Those are the four lines that turn up after signature in most of the projects we take over.
What we do, and what we will refuse to do
What we will refuse: delivering a shop without the stock question settled in writing. It will work for two months, then sell something that no longer exists, and the customer who finds out will not know it was a decision nobody took.
We will also refuse to build custom for a reason of appearance. If your selling rules fit an existing platform, we will say so even when that reduces the invoice — visual styling does not justify a build.
And we will refuse to price a project without catalogue entry, or by mentioning it without having counted your references and your variants. It is the line that derails budgets and it is nearly always missing from the quotations we see.
What we do: the stock question settled before the first line, an order created before payment and reconciled by identifier, a back office whose search accepts a phone number and whose edits happen in bulk, a zone-based charges grid, and an export tested in front of you.
And what you should do without us this week: count your references, multiply by your real variants, and allow five minutes to enter each. That number of hours is the true first figure of your project, and it appears on none of the quotations you will receive.
Frequently asked questions
What should we ask for in a demonstration?
Three operations nobody shows: adding twenty products, changing a price across a whole category, and finding an order from a phone number. If each takes more than a few minutes, you have just seen your real cost.
How should stock be handled between shop and website?
Settle it before building. The simplest, and often the right start, is reserving a quantity for online sale and isolating it: that removes synchronisation, which is the permanent failure point of the alternatives.
Existing platform or custom build?
Decide on how unusual your selling rules are, never on appearance. If your variants, prices and deliveries are ordinary, a platform will do better for less. Custom is justified when a business rule does not fit.
What happens if a customer pays and the page closes?
That case has to be handled before opening. The order must exist before the payment, carry a unique identifier, and be reconciled daily against what the platform says it processed. Without that you will have money with no order.
What does the catalogue really cost?
Count your references, multiply by your real variants, and allow five minutes of entry per combination. That number of hours is the project’s true first figure and it appears on almost no quotation.
How should delivery charges be calculated?
As a rule, not a field: destination by zone, weight or volume, basket value if you waive carriage above a threshold, and the method chosen. And the total including charges has to be visible before commitment.
Where we come in
Your references multiplied by their variants, converted into minutes of data entry, give you the line nobody puts on a quote. It often exceeds the development.
- We settle in writing where stock comes from before a line of code is written.
- We create an order end to end before the shop opens to anybody.
- We price the data entry separately, with who will do it and over how many weeks.
A standard shop that accommodates your terms is enough, and we will build nothing more: the difference would show on the invoice and not on the screen.
Read next
Running an online shop: the day, the parcel, the return
A shop is chosen once and run every day. The second job is the one that decides whether the first was worth doing.When it works: what breaks next, and in what order
Growth breaks a business before it breaks a campaign. The constraint does not disappear, it moves — and never to where you are watching.The month renting gets more expensive than building
Past a certain volume, buying attention every month costs more than making the thing that receives it. How to spot that moment, and what breaks if you build too early.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.