DE-RANGER Store

The business problem

Pay on delivery is the dominant model for this business, and it breaks the assumptions a normal storefront is built on. There is no payment to confirm, so an order is not revenue — it is an intention. Most orders need a phone call before dispatch, some are refused, some cannot be reached, and a submitted order that is never delivered must never be counted as a sale.

On the operations side, the owner is one person working largely from a phone, handling orders as they arrive. They need to know what needs a decision, what money is actually collected, and what is merely submitted — without a spreadsheet and without a desktop.

System objective

Build both sides of the operation from the same rules: make ordering genuinely simple for a customer who has no account and no card, and give the owner an honest operational view where confirmed money is never confused with pending money.

• Guest checkout — no account, no card details, no advance payment. An order is placed in one form.
• Customer self-service — the customer gets an order ID and can check status, and can request cancellation while the order is still open.
• Phone-first admin — the operational screens are designed for one-handed phone use, because that is how the work is actually done.
• Only delivered orders count as revenue — collected money is separated from submitted and potential value everywhere it is displayed.
• Content manageable without a developer — packages, prices, FAQs, reviews, images and site copy are all editable from the dashboard.

Who uses it

Two audiences with very different needs, served by the same deployment.

• Customers — browsing packages, placing an order with name, phone, state, city and address, receiving an order ID, checking status afterwards, requesting cancellation while the order is open, and reaching the business on WhatsApp or by phone.
• The owner — checking which orders need a decision first, working the order list, moving orders through the lifecycle from a phone, editing storefront content, and reviewing revenue that reflects collected money only.

How the system works

The store is a Next.js application with server-rendered pages, a small set of JSON endpoints for orders and tracking, and Supabase providing PostgreSQL with row-level security, authentication and file storage. Five SQL migrations build the schema, abuse controls and the admin metrics functions.

The customer side is deliberately thin: an offers section, an order form, a track-order page and informational pages, with WhatsApp and phone as the human confirmation channel. The admin side is a protected dashboard covering orders, content, FAQs, reviews, images and account settings.

• Order capture — a single validated endpoint is the only public write path on the site. It rejects oversized bodies before parsing, normalises Nigerian phone numbers, validates against a schema, and rate-limits by hashed IP.
• Money stored as integers — every amount is an integer count of kobo, never a float, which is why the dashboard has no rounding drift. Prices entered in naira are converted on the server; the browser's number is never trusted.
• Eleven-state order lifecycle — pending, confirmed, processing, dispatched, out for delivery, delivered, plus cancellation requested, cancelled, customer refused, unable to reach and delivery failed, each with a customer-facing label and hint.
• Enforced state machine — transitions are validated server-side before the write, so a crafted request cannot mark an order delivered from pending. Every transition appends to an order status history with actor and note.
• Tracking requires both ID and phone — order ID alone reveals nothing, and the response is identical for a wrong ID and a wrong phone, so the endpoint cannot be used to discover whether an order exists.
• Revenue discipline — only the delivered status is realised money. The dashboard separates delivered revenue, confirmed-but-uncollected, lost, outstanding, pending and stalled, and marks a customer view safe by excluding internal fields.
• Content management — the admin edits packages and prices, FAQs, testimonials, product images and grouped site settings (brand, contact, delivery, payment, availability); each write revalidates the public site.
• Admin authentication — Supabase Auth with email and password, a protected route group, and an authorisation check inside every server action rather than in the UI, because a form action is just an HTTP POST anyone can send.
• Attribution plumbing — orders persist UTM parameters, referrer and Meta click identifiers from a first-party cookie, so marketing performance can be traced to real orders rather than to clicks.
• Consent-aware analytics — page views and funnel events are recorded through a first-party endpoint; delivery fires the server-side purchase event so reported revenue reflects money actually collected.

Key features

• Guest checkout and order captureA single form takes name, phone, alternative phone, state, city and address with an optional note and terms acceptance. No account, no card, no advance payment — which is what a pay-on-delivery customer actually expects.
• Self-service order trackingThe customer checks status with their order ID and phone number and sees a progress timeline plus what happens next. Cancellation can be requested from the same page while the order is still open.
• Eleven-state order lifecycle with an enforced state machineHappy path, cancellation, refusal, unreachable and failed delivery are all distinct states with their own labels and customer-facing wording. Illegal transitions are refused server-side, and every change is appended to an audit history.
• Revenue reporting that respects pay on deliveryDelivered revenue is separated from confirmed, outstanding, pending and lost money, with stuck-order detection. Because amounts are stored as integer kobo, the figures reconcile exactly.
• Content management without a developerPackages and pricing, FAQs, customer reviews, product images and grouped site settings are all editable from the dashboard, and each save revalidates the public pages.
• Abuse control and privacy by constructionRate limiting on the public order and tracking endpoints, hashed IP and user-agent for abuse control rather than stored raw, internal notes and abuse columns excluded from application types, and no-store, noindex responses on order and tracking payloads.
• Phone-first operational interfaceThe order list renders as stacked cards on a phone and as a table on a wide screen, from separate markup rather than one squeezed DOM tree, with attention badges on the navigation.

Interface

www.deranger.name.ng

www.deranger.name.ng

How it was built

The build started from the awkward parts of the business model rather than from a template, because pay-on-delivery is where generic commerce patterns break.

• The state machine is the source of truth — the admin UI renders the transitions the server will accept, rather than offering buttons that can fail.
• Authorisation lives in the action, not the interface — every admin mutation re-checks the session first, because the service-role database client bypasses row-level security and nothing downstream would otherwise stop an unauthenticated write.
• Money is integer kobo end to end — naira is converted on the server and formatting happens only at the edge of display.
• Degrade instead of lying — when the metrics functions fail, the dashboard says the figures could not be loaded and points the owner at the order list, which still works, instead of showing zero.
• Responses leak nothing — order and tracking payloads are no-store and noindex, errors are generic, and authentication responses are identical for every outcome so they cannot be used to discover which accounts exist.
• Edge-cached landing page with owned content — the storefront reads only rarely-changing content and no cookies, so it is regenerated on an interval rather than paying a database round trip per visitor.

Notable decisions

The interesting constraints came from doing commerce correctly under conditions where the usual shortcuts are unsafe.

• A submitted order is never revenue — only delivery is. This is enforced in the status types, the metrics functions and the dashboard layout, so the two cannot be confused at a glance.
• Tracking needs two factors, not one — requiring the phone number alongside the order ID makes enumeration useless, and the failure response is deliberately indistinguishable between a wrong ID and a wrong phone.
• Cancellations and refusals are not sent to the ad platform — feeding a refusal signal back to an optimiser invites it to chase the same low-quality traffic that refused.
• Abuse columns are excluded from the application types — ip_hash, user_agent_hash and idempotency_key exist in the table, and leaving them off the type is the cheapest way to ensure no code reads them.
• Analytics never blocks the owner — the purchase and Meta events run through waitUntil so a slow third-party call cannot fail a status update the owner is trying to make.