An online store costs more than a brochure website because it has to do more: take money, track stock, and move orders out the door. The good news is that you can start lean here and grow. This is what an e-commerce build really costs in 2026, where a hosted platform beats a custom one, and the running costs that decide whether the store is profitable.
The realistic ranges
| What you get | Build cost (KES) | Typical timeline |
|---|---|---|
| Starter: focused catalogue, M-Pesa checkout, simple order management | 80,000 to 150,000 | 4 to 6 weeks |
| Growth: larger catalogue, delivery tracking, accounts, analytics | 150,000 to 350,000 | 6 to 10 weeks |
| Custom or multi-vendor platform: bespoke features, integrations, scale | 350,000+ | 8 to 12 weeks and up |
Use these for a first budget and confirm current pricing with any provider. On top of the build there are payment fees per transaction, hosting, and, on a hosted platform, a monthly subscription. Those three decide the running cost, and they are what the build price alone does not tell you.
Custom build, Shopify, or WooCommerce
This is the decision that matters most, and it is not really about features. It is about where you want your costs to sit: monthly and predictable, or upfront and owned.
| Hosted (Shopify) | WooCommerce | Custom build | |
|---|---|---|---|
| Upfront cost | Low | Low to medium | High |
| Monthly cost | Subscription, per plan | Hosting plus plugins | Hosting only |
| M-Pesa | Usually a paid app or workaround | Plugin, quality varies | Native, via Daraja |
| Who maintains it | The platform | You | Us, or you |
| Fits an unusual workflow | Poorly | With effort | Exactly |
| Best when | You are testing whether you can sell at all | You already run WordPress | Selling online is the business |
As a general starting point: where you are testing whether you can sell online at all, a hosted platform keeps the upfront cost low and puts the saved money into stock and photography. Where selling online is core to the business, and platform fees or platform limits are already constraining it, a custom build removes the per-plan subscription. Where the crossover falls depends on your subscription rate, your order volume, and how long you expect to run the store, so it is worth working out with your own numbers rather than a rule.
The M-Pesa question
For many consumer-facing businesses in Kenya, M-Pesa is a major checkout requirement. The appropriate payment mix depends on the target customer and the business model. Where M-Pesa is required, STK push through the Daraja API gives the shortest path: the customer approves a prompt on their phone and the order confirms against the payment, without a till number being copied by hand.
The part that separates a store that works from one that leaks money is the callback. A payment can succeed on Safaricom's side while the customer's phone dies, the browser closes, or the network drops before the confirmation gets back to the store. A store that only listens to the browser will record that order as unpaid, and the customer finds out before you do. Ask how a payment that lands after the checkout page has closed is reconciled. The answer should describe a server-side callback and a defined timeout path for pending orders.
A worked budget
An illustrative example, not a quotation. Suppose you sell homeware: forty orders a month, average basket KES 2,500, so revenue is KES 100,000 a month. Now the costs, hosted against custom:
| Line item | Hosted | Custom |
|---|---|---|
| Build, one-off | 35,000 (setup and theme work) | 120,000 |
| Platform subscription, monthly | 5,000 to 9,000 | 0 |
| M-Pesa app or plugin, monthly | 0 to 3,000 | 0 |
| Hosting, monthly | included | 1,000 |
| Monthly running cost | 5,000 to 12,000 | 1,000 |
| Total, first 12 months | 95,000 to 179,000 | 132,000 |
| Total, first 24 months | 155,000 to 323,000 | 144,000 |
Read the last two rows rather than the first. Hosted is cheaper to start and can be more expensive by the second year, and the gap widens the longer you trade. That is the real trade, and it is a cash-flow decision as much as a technical one. If the upfront number is what stands between you and trading at all, start hosted and move later. Moving is work, but it is work you can pay for out of revenue rather than savings.
What you keep from each order
Revenue is the number people quote and margin is the number that decides whether the store survives. Payment providers take a cut of every transaction, and the percentage looks small until you set it against your own margin rather than against the sale price. Work it per order:
| Low-margin (electronics) | High-margin (handmade) | |
|---|---|---|
| Selling price | 8,000 | 2,500 |
| Cost of goods | 6,800 | 700 |
| Payment fees | roughly 1 to 2% | roughly 1 to 2% |
| Delivery, if you absorb it | 350 | 350 |
| Roughly what you keep | about 730 | about 1,410 |
| Orders needed to cover 8,000 monthly running costs | about 11 | about 6 |
Fees move with your provider and your volume, so check yours rather than trusting the rough figures above. The lesson holds either way: the electronics seller needs nearly twice the order volume to cover the same monthly cost, so a subscription that looks affordable against revenue can be expensive against margin. If you sell few, high-value items, per-transaction fees barely register and the subscription is your real cost. If you sell many small items, the opposite is true.
Catalogue size
There is a strong pull toward launching with everything you stock. The practical constraint is that every product needs a photograph, a description, a price, and stock tracking, and each of those is work that has to be maintained. A smaller, well-structured catalogue can be easier to navigate and cheaper to keep current; the right structure depends on the product range and on how customers buy. Catalogue size is also one of the few variables that reliably moves an e-commerce quote, so launching with a focused range lowers the build cost as well as the workload.
Delivery
Delivery design affects checkout conversion, operating cost, fulfilment, and customer experience, so decide early how orders reach customers, whether through your own riders or a partner. Order tracking that the customer can see for themselves reduces the volume of enquiries asking where a parcel is, and each of those enquiries carries a staff cost.
- Set delivery expectations on the product page, not at checkout.
- Give every order a status the customer can see without contacting you.
- Decide who pays for a failed delivery before it happens, and write it down.
- Track your return rate from the first month. It affects margin directly and it is difficult to reconstruct later.
Before you commit
Work out your contribution per order: selling price, minus cost of goods, minus payment fees, minus delivery. Multiply by the orders you realistically expect in a month. If that number does not comfortably clear your monthly running costs, the platform choice is not your problem and a better store will not fix it. Fix the margin first, then build.
Planning a similar project?
We can help define the requirements, implementation options, and an appropriate project scope. There is more detail on e-commerce solutions if that is the closest fit.
Start a project