Articles
Shopify alternatives for an Algerian shop: what to weigh instead
Four shapes can replace a hosted store, not one product. Where the order record lives and who reconciles the cash decide between them.
- ecommerce
- platforms
- algeria
The alternative to a hosted store is rarely another product on the same shelf. It is one of four shapes: a hosted platform you rent, a self-hosted store stack you run, a store built onto a system you already operate, or selling through messaging with an order record behind it. Which one fits is decided by where the order record lives and who reconciles the cash at the end of the day, not by the checkout page — all four can take an order, and fewer can tell you what it cost.
What are the four shapes?
- A hosted platform. The store, hosting, checkout and support are rented from one vendor. You configure it and add apps; you do not run a server.
- A self-hosted store stack. A store application installed on hosting you rent. You choose the theme and the add-ons, and you carry the updates.
- A store on a system you already run. Your invoicing or stock system gains a public catalogue and an order intake, so the shop and the back office read the same records.
- Messaging plus an order record. Customers order in the messaging app they already use, and one place records the order, the amount to collect and the delivery status.
None is a downgrade of the others; they answer one question differently: who owns the machinery.
When is a hosted platform the right shape?
When the shop must exist quickly, nobody wants to administer software, and the catalogue is ordinary: products, variants, a cart, a delivery fee. The vendor carries upgrades, security and checkout; your work is merchandising.
Two things decide whether it holds. First, whether the vendor's app catalogue covers what you need — a courier interface, a local payment method, a second language — because the wall is where that catalogue ends. Second, how the subscription is paid from Algeria: a recurring charge in foreign currency is an operational task, and a shop whose card expires goes dark on a Friday.
When is a self-hosted stack the right shape?
When the shop must feed systems you already run, or hold data you will not place in someone else's account: customer records, purchase history, stock that also exists in a back office. The store becomes a component rather than a destination.
The cost is that everything is yours to keep alive — the application, its add-ons, the server, the certificate, the backup, and the person who knows all of it. Hire that duty or accept that it is your evenings.
When is a store on your existing system the right shape?
When the catalogue already exists as records: a stock file, an invoicing system, a counter application that knows every product and price. Publishing from those records removes the double entry that appears within a month — one list in the shop, another in the back office, a third in the courier's notebook.
The risk is exposure. A system built for internal use was not designed to be public: it may leak supplier prices, internal codes or customer lists. This shape needs a public layer in front, not a port opened to the internet.
When is messaging plus a record the right shape?
When orders already arrive that way and the volume lets a person answer each one. It asks nothing of a catalogue, and it matches how a customer here actually buys — a photograph, a question about size, an address in a voice note.
What it does not have is a record. Without one place holding the order, the amount to collect, the courier and the return, the shop is a chat history and a notebook, and the first busy week exposes it. Choose the record with the shape, even a plain one.
What are the four criteria?
| Criterion | Why it decides | How to test it |
|---|---|---|
| Where the order record lives | One order, one place; everything else is reconciliation by hand | Place a test order and follow it to the stock and the invoice |
| Who reconciles cash on delivery | The money arrives days later, through a courier, minus a fee | Ask for the settlement file and match it to orders |
| The delivery rule | Wilaya, weight, return and exchange decide the margin | Configure one real order end to end |
| Who carries maintenance | A shop that stops taking orders costs more than one that never opened | Name the person, and the hours, before launch |
| What to verify on the vendor's page | It changes faster than any article | Availability of the local payment and courier you actually use |
In what order should you decide?
- Count where the orders come from today: messaging, phone, a physical shop, a marketplace.
- Write the record you must keep: order, amount to collect, courier, status, reason for return.
- Take the shape that already produces that record, before considering the one with the better theme.
- Test one real order end to end: catalogue, address with wilaya and commune, delivery fee, confirmation, collection.
- Ask who applies updates and restores a backup, and write the name down.
- Read the exit terms: what you take with you, in what format, and how long it takes.
Where this goes wrong
- The platform is chosen for its design, then the delivery rule it cannot express is handled in a spreadsheet beside it.
- The shop is built on an internal system with no public layer. Supplier prices, internal codes or an admin path end up reachable from a search engine.
- Messaging is chosen without a record. It works until two people answer the same customer, or a parcel is lost and no one can prove what was in it.
- Cash on delivery is treated as a setting. Nothing separates shipped from delivered and paid, so the month cannot be closed.
- Hosting is the cheapest line in the budget, and the shop's uptime becomes the host's least urgent problem.
When neither fits
When the shop's advantage is a rule no store product expresses — a price that depends on the wilaya and the weight together, a subscription of weekly baskets, a wholesale tier behind a login — the answer is a custom storefront with a written interface to the system that holds stock and cash. That is more than configuring a platform and less than replacing the back office, and it is worth doing only when the rule is what customers pay for.
What this does not cover
No prices appear here, deliberately: subscription, hosting and courier costs change faster than an article can be corrected, and a figure would be wrong by the time it ranked. For the same reason no alternative product is named — availability, local support and payment integration differ by market, and a recommendation wrong about availability is worse than none. Nor does this judge courier contracts or the quality of local gateways; each deserves its own decision.
We build and integrate sites and systems for shops: the public layer over a stock system, the order record cash on delivery needs, the interface to the courier that has none. We resell none of these platforms and take no commission from any of them.
Services in this article
Articles
Related articles.
Shopify or WooCommerce for an Algerian shop: the delivery-and-payment question
Cash on delivery, courier integration, a bilingual storefront and who holds the data decide this — not the theme gallery.
- ecommerce
- platforms
- comparison
Cash on delivery is an operations problem, not a payment option
Cash on delivery is a cash-handling operation with a delivery step attached. What to record, how to reconcile, and where the money quietly goes missing.
- ecommerce
- delivery
- logistics
Work out delivery cost before you set a price
Delivery is priced per parcel you hand over, but it is paid per order that arrives. How to build a cost per delivered order before you set a price.
- delivery
- pricing
- ecommerce
Start a project
Have something to build?
One short brief is enough. You get a written scope and a fixed quote before anything starts.
