Most e-commerce developers have built carts and checkouts. Fewer have stood behind a till at 6pm on a Friday in a recession, watching a customer decide whether they can afford the part you ordered for them three days ago, and recalculating in their head whether you can pay the supplier on Monday.
That side of the work - the operating side - is where most e-commerce software actually lives or dies. This post is the short version of where I learned it.
2008: A Brick-and-Mortar IT Store, in a Recession
In the middle of the 2008 recession I was running an IT retail store. Not as a passive owner. As the person who set up the shop floor, built the display cabinets, installed the signage, ran the till system, kept the stock counts honest, and met the customers who walked in with a broken laptop or a question about a printer.
The recession was closing other stores in the same area. Mine turned a profit. Not because the macroeconomic environment was any kinder to me - it was not - but because I was hands-on across every part of the operation and could cut, adjust, and renegotiate fast.
What "managing all areas" actually meant
The list looks long because it was long:
- Setting up the shop - interior, fixtures, display cabinets, tables, signage, vehicle branding
- Setting up the technology - till systems, accounting server, phone PBX, file servers, CCTV
- Managing staff - scheduling, training, day-to-day
- Managing clients - relationships, requirements, expectations, problem resolution
- Managing 28 suppliers - terms, lead times, returns, reconciliations
- Managing orders, stock, logistics
- Managing the books - accounting, finances, reconciliations
- Designing marketing - teardrop flags, light boxes, vehicle signage, flyers, ads, the lot
- Designing and maintaining the business websites and the e-commerce system
Every one of those touches a piece of software a developer somewhere has to build. Doing them yourself for years changes how you build that software.
The shift to e-commerce: 2008 – 2013
Designing websites for clients started as a side activity while the retail store was running. The interest grew. The platform of choice in the early years was Prestashop. By around 2013 the work had shifted enough that I was running e-commerce projects as the main thing, with the retail experience as the operating context.
Two named businesses from that period: Matrix Warehouse Computers cc, and iThemba Computers cc. Photos from both are below.
2014 – 2020: The WooThemes years
In 2014 I joined WooThemes as a Support Ninja. WooThemes is the company that built WooCommerce, before it was acquired by Automattic (the WordPress.com parent). Cape Town-based.
I moved from Support Ninja into the Certified Affiliated WooWorker programme, specialising in custom development of WooCommerce setups and custom WooCommerce plugins. That specialisation is still in the day-to-day work today.
In 2015 WooCommerce introduced an annual affiliation fee - over $5,000 at the time, which made no commercial sense to pass on to small clients. I went solo. The certification was useful while it lasted; the underlying skill - building WooCommerce extensions and stores that survive contact with real operating reality - is what carried forward.
2020+: Custom e-commerce, without the badge
The work since has been the same shape: custom WooCommerce plugins, WordPress + WooCommerce setups for businesses who have outgrown the off-the-shelf checkout, headless WordPress + Next.js builds where performance and SEO matter, and the broader software work that lives next to e-commerce (booking systems, CRM integrations, custom Shopify apps, ERP sync - see the third-party API integrations post for the shape of that work).
A typical engagement now starts with a WooCommerce or Shopify store that is doing real revenue and is hitting a real ceiling - slow, brittle, broken integrations, plugin sprawl, payment-gateway issues. The conversation is operational before it is technical, which is why the retail-shop background matters more than the developer background half the time.
Why retail experience changes the build
Three concrete things a developer who has run retail does differently:
1. Stock counts that match physical reality. A developer who has not run a shop will trust the database. A developer who has knows that stock counts drift the moment three things happen at once: a return, a manual adjustment, and a delivery that arrives without paperwork. The build has to handle drift, not pretend it does not happen.
2. Supplier lead times that are modelled. "In stock" on the website does not mean "available to ship today" if the supplier ships from another country with a 14-day lead. A developer who has chased 28 suppliers for delivery slots writes the order pipeline differently from one who has not.
3. The till is the source of truth, not the website. When the till and the website disagree, the till is right - because that is what the customer paid for. The integration has to honour that direction, not the other way around. Most off-the-shelf integrations get this wrong.
What this means in practice
When I am scoping an e-commerce project - WooCommerce, Shopify, custom - the questions I ask first are operational, not technical. How many SKUs. How many suppliers. How returns are processed. Whether stock is held in one location or many. Whether the till and the website are reconciling. Whether anyone is currently doing manual data entry between systems.
The technical work follows from those answers. Not the other way around.
For the WooCommerce side specifically, see /services/wordpress-woocommerce. For broader custom e-commerce platforms, see /services/cloud-applications. For SA-specific payment gateway work (PayFast / Yoco / Peach), the comparison post is the starting point.
Photos from the brick-and-mortar period
Matrix Warehouse Computers cc
iThemba Computers cc
If you are setting up or rescuing an e-commerce store
I take e-commerce work where the operational side is the actual problem. If your store is technically running but losing money to bad integrations, drift, slow performance, or plugins that have stopped being maintained - that is the engagement shape. Past project work is on /projects. Get in touch and we will work out which version of the answer applies. For the broader software work see /about.