On this page9 sections
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, 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 to 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 to 2018: WooThemes and Codeable
In April 2014 I joined WooThemes, the Cape Town company that built WooCommerce, as a Support Ninja, and supported more than 850 WooCommerce customers. From October 2014 to October 2015 I was an affiliated WooWorker, doing custom development of WooCommerce setups and plugins. That specialisation is still in my day-to-day work. When WooCommerce introduced an annual affiliation fee that made no sense to pass on to small clients, I left the programme.
Also in October 2014 I joined Codeable, and became a Codeable Certified Expert that November. Until June 2018 I delivered 170+ projects there, each with a public review from the client who paid for it.
2018 Onward: Custom E-Commerce, Without the Badge
The work since has been the same shape: custom WooCommerce plugins, WordPress and WooCommerce setups for businesses who have outgrown the off-the-shelf checkout, headless WordPress and 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 WordPress API integration 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, or 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 WordPress and WooCommerce. For broader custom e-commerce platforms, see 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. Tell me the problem and we will work out which version of the answer applies. For the broader software work see /about.
For your technical person
The retail and e-commerce years built the WooCommerce specialisation still central to this practice: custom plugin development, checkout and payment logic that goes beyond what themes and off-the-shelf plugins support, and stock or order integrations that have to reconcile against a physical till, not just a database. See when WooCommerce plugins are not enough for what that looks like in current work.
Questions owners ask
Why does retail experience matter for an e-commerce developer?
Most e-commerce work fails for operational reasons, not technical ones. Stock counts that drift. Supplier lead times that are not modelled. Returns that bypass the system. Marketing that does not match what is actually in stock. A developer who has only built e-commerce software thinks the problem is the cart and the gateway. A developer who has run a shop knows the cart is the easy part, the hard part is the back of the store, the till, the stock room, and the supplier relationships. I have done both sides.
What did you actually do at WooThemes?
I started in April 2014 as a Support Ninja for WooThemes, the Cape Town company that built WooCommerce, before it was acquired by Automattic. I moved into the Certified Affiliated WooWorker programme, specialising in custom development of WooCommerce setups and plugins, until October 2015. Also in October 2014 I joined Codeable and became a Certified Expert that November, delivering 170+ projects there by June 2018, each with a public review from the client who paid for it. That specialisation is still central to the work today.
Are Matrix Warehouse Computers and iThemba still running?
Both businesses were owner-operated by me through the e-commerce-and-retail period (2008 to 2013). They are not active stores under that ownership now, the experience and skill set carried over into the software work full-time from 2014 onward. The photos in this post are from when those stores were operating.