A checkoutwith a humanin it.

LooksLab takes payment off the site. Rather than treat that as a gap to paper over, the platform was built around it — a staff member verifies the money, and everything of value in the system waits for them to do it.

lookslab.shop
The LooksLab storefront: a dark home page with the catalog and the compliance notice across the top
Client
LooksLab
Scope
Storefront, accounts, staff console
Built
June – August 2026
Status
Live in production
22
Console tabs
30
Database tables
13
API modules
22
Build days

01

The spine

Eight steps, and nothing in the codebase is allowed to break them. Every feature added afterwards had to respect the order rather than route around it.

  1. 01

    Customer orders; an invoice is generated and emailed

  2. 02

    They pay externally, by whichever method the store has enabled

  3. 03

    A staff member verifies the payment — the human gate

  4. 04

    Status moves, and the customer is emailed at each move

  5. 05

    Shipments are created and tracking is emailed per parcel

  6. 06

    A carrier API confirms delivery, or a person does

  7. 07

    The order completes itself, and the whole thing is audit-logged

02 · Why the gate is the product

Because a person has already looked at the money, payment verification doubles as the fraud gate. Reward points, referral credit and store credit are all earned at that moment and not one step earlier — so reaching checkout, which anybody can do, is worth nothing. It is the cheapest anti-abuse control in the system and it came free with the workflow.

03

What got built

A storefront the staff can rewrite without a deploy, an identity system of its own, and a console with enough in it to run the company from a phone.

  • Two catalog lines with per-variant pricing, bulk discount thresholds and stock-aware variant chips
  • Pre-orders that ship together or separately, with a configurable split fee
  • Accounts with magic-link sign-in, saved addresses, and a wishlist that emails on restock and price drops
  • A points programme and a referral scheme, both with admin-set rules and a review queue
  • A 22-tab staff console across orders, inventory, growth, content and settings
  • Carrier tracking polled every thirty minutes, with orders closing themselves once every parcel lands
  • Every customer-facing word — copy, banners, FAQ, email templates, SEO — edited from the admin, not the repo

04

The unglamorous half

Four things were quietly broken in production before I found them, and none of them had raised a complaint. This is the part of shipping that never makes a highlight reel.

  1. 01Bot protection was inert — the site key had never been set, so checkout had been open the whole time
  2. 02Customer login never stored its session, so signing in appeared to work and then did not
  3. 03A first-time save in the admin could overwrite live site copy with the panel’s own defaults
  4. 04A cart race could write an empty cart to storage over a full one

05

Security, on the record

An audit early in the build found a hidden route that minted owner accounts and kept them out of the accounts list. It was deleted, along with every mechanism that had concealed it.

  • Order pricing moved server-side, so totals cannot be edited from a browser
  • Database backups taken out of version control — they can hold customer data
  • Permissions enforced in the Worker, never by hiding a button
  • Every admin change logged with who did it, when, and what changed

Behind the counter

The deskit runs on.

The orders tab of the LooksLab console, listing invoices by payment and fulfilment state
The order desk. Every row waits on a person confirming the money arrived — “pending”, “deposited”, “awaiting deposit” are states a human moves, not a webhook.
The LooksLab dashboard: revenue over thirty days, active orders, and stock alerts
The dashboard the staff open first: revenue over thirty days, what is unpaid, what is unshipped, and what is running out of stock.

Under the hood

What it ismade of.

Frontend
React 19 · Vite 6 · React Router 7
API
Cloudflare Workers
Database
Cloudflare D1 — 30 tables
Email
Resend — transactional, campaigns, inbound
Bot protection
Cloudflare Turnstile
Scheduled work
Worker cron — carriers, rewards, wishlists

Next step

Yours to run.Not to rent.

This one was built around how the business already took money, rather than around what a platform would allow. If yours has a step like that, it is a reason to build rather than a problem to work around. Thirty minutes and we will tell you which you need.

Fig. 01The gate is a personMoney moves when someone confirms it did. Everything else in the system waits for that.

We do the marketing. You stay lazy.