Most people think e-commerce means a storefront, a cart, and a checkout button. That’s the tip of the iceberg. The actual system is much larger, and it fails in much more interesting ways.

This is what it took to build PrimeShieldHub and BuildMart — not as a case study, but as a set of hard-earned observations.

The Business Model Comes First

Before writing a line of code, the business model has to be clear:

  • What are we selling? Premium gadgets — but which categories, at what margins?
  • Who are the customers? Individuals? Businesses? Resellers? Each needs different flows.
  • How do we source? Direct? Distributors? Both?
  • How do we price? Fixed? Tiered? Negotiated?
  • How do we deliver? In-house? Third-party? Pickup?

Every one of these decisions constrains the software. A business that sells to individuals has a completely different architecture from one that sells to enterprises.

The Technology Layers Nobody Talks About

Beneath the storefront, there are eight layers. Every one of them has failure modes.

1. Product Catalogue

Not “a list of products.” A system with:

  • Categories, tags, attributes
  • Inventory state (in stock, out of stock, backorder, discontinued)
  • Pricing (base, wholesale, reseller, promotional)
  • Media (images, videos, documents)
  • SEO metadata
  • Version history

2. Cart & Checkout

Not “add to cart, click pay.” A flow with:

  • Guest vs authenticated checkout
  • Shipping calculation
  • Tax handling
  • Discount codes
  • Currency handling
  • Abandoned cart recovery
  • Idempotent order creation (so a network blip doesn’t double-charge)

3. Payment Processing

Paystack handles the mechanics, but the platform handles:

  • Webhook verification
  • Idempotent webhook handling (the same webhook can arrive multiple times)
  • Reconciliation (matching payments to orders)
  • Refunds (full, partial, disputed)
  • Failed payment recovery
  • Multi-currency

4. Order Management

An order isn’t a row in a table. It’s a state machine:

  • Created → Confirmed → Processing → Shipped → Delivered → Completed
  • Or: Cancelled, Refunded, Disputed, Returned
  • Every transition has an actor, a timestamp, and often a notification

5. Fulfilment

Physical goods mean:

  • Warehouse location tracking
  • Pick, pack, ship workflow
  • Courier integration
  • Delivery confirmation
  • Return processing
  • Inventory re-sync

6. Customer Communication

Every order event triggers communication:

  • Order confirmation (email + optionally SMS)
  • Shipping notification with tracking
  • Delivery confirmation
  • Follow-up for review or reorder

All of this has to be idempotent — never send the same notification twice.

7. Business Operations

Behind the storefront:

  • Staff accounts with roles and permissions
  • Sales reports
  • Customer records (with privacy considerations)
  • Product performance analytics
  • Inventory forecasting

8. Trust & Security

The most underrated layer:

  • HTTPS everywhere
  • PCI compliance (or delegating to a processor)
  • Session security
  • Rate limiting on critical endpoints
  • Fraud detection (unusual orders, suspicious patterns)
  • Audit logs for every sensitive action

The Infrastructure Decisions That Compound

Every infrastructure choice compounds. Get them right early, and everything downstream is easier.

Cloudflare Workers over VPS. Zero cold-start, global distribution, predictable pricing. No servers to patch.

D1 over external Postgres. Edge-native, same billing model, no network latency between compute and data.

R2 over S3. Zero egress fees. For a business serving images and documents, this is enormous.

KV for caching. Where D1 would be overkill, KV is instant.

Cloudflare WAF + rate limiting. Security at the edge, before requests hit your code.

What Nobody Warns You About

1. Idempotency is not optional. Every system that touches money or sends notifications needs to handle duplicate events gracefully. A webhook that fires twice should produce one order, not two.

2. Eventual consistency is real. In distributed systems, “now” is not a single moment. Different services see different states for brief windows. Design for it.

3. Cost scales non-linearly. A system that costs $5/month at 100 users might cost $500/month at 100,000 users — or might cost $50. Depends entirely on the architecture. Design for the shape of the growth, not just the total.

4. Operations is the hard part. Anyone can build a storefront. The hard part is running it — handling returns, disputes, refunds, edge cases — at 2am on a Sunday, when the customer is upset and the system is behaving unexpectedly.

5. AI is a tool, not a strategy. Gemini helps with product descriptions and customer assistance. It’s not a moat. It’s not a category. It’s a tool. Use it where it removes friction. Don’t build a business around it.

The Real Lesson

Technology-driven commerce is not “a business with a website.”

It’s an operating system for a business — with every layer designed, integrated, and maintained.

The business is the system. The technology is how the system runs.

Once you see it that way, the scope becomes clear — and so does the value of getting the architecture right.