E-commerce

03

An online store is a sales operation

The catalog matters, the photography matters and the copy matters — but a store is not finished when it looks good. It is finished when it can take an order, take money, and deliver the thing. Every piece below is what turns a website into a sales operation, and every one of them is engineered rather than assumed.

• Catalog, search and filtering that are genuinely fast — a catalog that takes three seconds to render on prepaid data is a catalog nobody finishes browsing; we build search and filters to be instant, not decorative.
• Checkout that accepts M-Pesa and cards cleanly — STK push to the phone, PayBill and Till flows, card entry — each wired with real callbacks, real verification and a clear state on screen.
• Trust elements that reduce cart abandonment — order statuses, tracking, receipts and clear delivery expectations tell the buyer the store is real and their money is safe.
• Inventory that matches reality — stock levels updated by real orders and restocks, so the store never sells what it does not have.
• Fulfilment that connects the order to the doorstep — the order state machine carries the parcel from paid to picked to dispatched to delivered, with a message at every step.
• Returns and refunds that follow policy, not mood — a return is an order state, a refund is a payment event, and both move through the same ledger as the sale.
• Analytics on what sells, at what margin, through which channel — every order ties to its acquisition source so marketing spend is measured, not hoped.

The web is full of counters where nothing is sold. We build stores where the numbers reconcile — orders, stock, money and parcels all agree, all the time.

04

From cold traffic to cart: the conversion journey

Most visitors to a store never reach the cart. The journey from an ad, a WhatsApp link or a Google result to a completed order is a series of decisions, each one a place to lose the customer. We engineer the journey the way we engineer the payment — deliberately, with the failure points identified in advance.

• First impression is measured in seconds — the store, the product page and the checkout must load and speak honestly fast, because a slow first screen is a silent bounce.
• Product pages built to answer the buying question — price, availability, delivery fee and delivery time visible before the customer asks, in shillings the customer recognises.
• Cart as a commitment, not a dead end — the cart is saved server-side, survives refresh and device change, and is reachable from a WhatsApp or SMS link.
• A one-click return path for the interrupted customer — the browse-then-return visitor is greeted with their last cart, not a blank homepage.
• Cold-call-to-cart hooks — vouchers, bundles and free-delivery thresholds exist to move numbers, and every one is measured for return, not installed as a habit.
• Checkout data captured once and remembered — names, phone, addresses and preferred pay method persist, so returning customers buy in two taps.
• The phone number is the identity — in a Kenyan store the M-Pesa number doubles as the account and the delivery contact; the whole journey is built around that single pivot.

Conversion is a series of small honest wins, not one big trick. We build each step to reduce friction — and we measure which friction actually mattered.

05

Checkout: M-Pesa on the front line

The checkout is where the store either becomes a business or stays a website. In Kenya the decisive rail is M-Pesa — the customer pays with a PIN from their own phone — and beside it sit cards, wallet gateways and bank transfers for the customer who lives on those. We run every payment surface, on every rail, through the same machine that handles money on our own platform:

• STK Push at checkout — the customer confirms with their own PIN; the charge request is fired, the push lands, the customer approves, and Safaricom captures the money.
• PayBill and Till as alternative rails — a customer who prefers to dial a PayBill or Lipa na M-Pesa Till can complete the order on their own terms.
• Cards for the customers who don't use M-Pesa — Visa and Mastercard wired into the same checkout so international and non-M-Pesa customers are not turned away.
• Payment happens before fulfilment, always — the order moves to picking only when the money is genuinely captured and verified, never on hope.
• The customer sees a state, not a mystery — initiating, push sent, awaiting confirmation, paid, failed — the screen tells the buyer exactly where the money is.
• Timeouts are handled with grace — someone who abandons the PIN pad gets a resume-in-one-tap path, not a dead order and a lost customer.
• Fees are shown before confirm — amount, delivery fee and any platform fee total exactly on the confirm screen, so the pin the customer enters matches the number they saw.

The checkout is the moment the website earns its keep. We make sure it accepts the money people actually pay with — M-Pesa, cards, wallet gateways, bank transfers — and that 'the money moved' is true on whichever rail before anyone touches a box.

06

One money machine, whatever rail the customer chooses

M-Pesa is the home rail for a Kenyan store and it will be the lived core of any build here — the STK pushes, the PayBill and till flows, the B2C refunds. But a store that grows, or that serves travellers, diaspora customers or business buyers, will meet PayPal, Stripe and PayStack, Visa and Mastercard, and direct bank transfers besides. The rule we hold is that every one of those rails is boarded through the same money machine — the same verification, the same idempotency, the same reconciliation — so none of them becomes an easier way to steal or a quieter way to lose money:

• The same states on every rail — initiated, pending, confirmed, failed and refunded mean the same thing whether the money arrived through Daraja, PayPal, Stripe, PayStack, a card processor or a bank transfer.
• Verification is per rail and non-negotiable — STK Query proves the M-Pesa push, signature and status checks prove the card and wallet gateways, and every webhook must be verified against its issuing rail before an order flips to confirmed.
• Idempotency keys travel with the order — a retried charge or a redelivered webhook on any rail returns the settled answer, so cross-rail replays and double-taps can never double-charge.
• Fees and totals are computed once — each rail's fee structure feeds one canonical calculator, so the amount the customer approves matches the amount that reconciles, whichever rail they chose.
• Refunds go home on the rail they arrived on — a PayPal payment refunds through PayPal, a card payment reverses with the card processor, and an M-Pesa payment returns via B2C, each matched to its original transaction.
• Reconciliation reads every rail's statement — daily totals match the Daraja, PayPal, Stripe, PayStack and bank lines line by line; a mismatch on any rail is an incident with a drill-down, never tidied away as a rounding.

A store that is honest on M-Pesa and sloppy on PayPal has simply chosen a cheaper way to leak. We build so the money machine is identical whichever door the customer uses — and the books stay right because the discipline does not change with the brand.

07

Payment states: from initiated to settled exactly once

An order is not 'paid' the instant a push lands. Real payment software has explicit states and explicit transitions, and the store's order state machine mirrors them. Nothing jumps states, nothing settles twice, and at any moment someone can ask 'what is this order?' and get one true answer:

• Initiated — the order is created with a unique reference before any money is touched; this reference is the identity of the intent, and every retry carries it.
• Pending — the gateway has been asked and the push is on the customer's phone; money has not moved yet, and the store holds the stock quietly.
• Confirmed — the gateway has genuinely verified success; the wallet capture, the order state change and every ledger row are written atomically as one fact.
• Failed / Reversed — a definitive failure or genuine reversal moves the order back to a payable state or issues the refund, both in full, with the customer told.
• Timed-out / Expired — a payment left mid-flight by a dropped network or an abandoned pin pad is expired by a scheduled job that releases any hold, so no order lingers in limbo.
• Refunded — the money comes back through the same rail it arrived on, matched to the original transaction, never guessed.
• Replay protection at every transition — a callback or retry arriving at any state is matched against the terminal state and answered with the settled truth, never re-executed.

The rule is simple to state and brutal to hold: credit exact money once, however many times the network, the gateway or the customer says 'again.' The lifecycle below is how 'exactly once' is built.

08

Callback discipline: the gateway's word is a claim, not a proof

When Safaricom says 'the customer paid', that message arrives over the ordinary, forgable, replayable internet. The single most dangerous assumption in commerce software is trusting it at face value — a store that credits an order on a fake callback ships goods it was never paid for. We treat every callback as a claim to verify:

• A callback is a claim, not a proof — before an order is marked paid, the backend queries the gateway's own status API (the STK Query / status endpoint) and only a genuinely verified ResultCode 0 confirms the sale.
• Verified paid → fulfil — the confirmation, the order state change and the ledger rows are written in one atomic step, so stock, money and status move together.
• Transport or query error → retry signal — the backend returns the response that asks the gateway to re-send; the order stays pending and nothing is half-confirmed.
• Definitive 'not paid' → acknowledge, never ship — the claim gets a courtesy acknowledgement, the order stays unpaid, and the mismatch is written to an audited gateway log.
• Idempotency keys absorb replays — a callback arriving twice, or a retry from a dead-letter queue, always returns the settled answer and never double-confirms.
• Every interaction is logged — raw callback and verification result land in a payment-gateway log that support can query, so 'did this order actually get paid?' has an answer in minutes.

On our own platform this exact loop is what separates the sandbox from production: the sandbox accepts the callback; production asks the gateway to prove it. Every store we build gets the proof requirement.

09

Inventory that matches reality

The nightmare of e-commerce is selling what you don't have — the customer pays, the staff discovers there is no stock, and the refund machinery has to run at the worst possible moment. Inventory is a concurrency problem as much as a logistics one, and we engineer it so overselling is structurally impossible:

• Stock updated by real orders, not hopeful spreadsheets — every confirmed order decrements stock in the same transaction that records the sale; the number is a consequence, not a belief.
• Reserved on checkout, released on abandonment — stock is held while payment is pending and quietly returned to the shelf when the payment fails or times out.
• Row-level locks on the SKU — two customers could not both buy the last unit of a garment; the stock row is locked `FOR UPDATE` around the check-and-decrement, so the double-sale is impossible by design.
• Low-stock alerts and reorder suggestions — thresholds push a restock signal before the item sells out, and reorder calculations consider committed-but-unpaid stock.
• Multi-channel sync — a store that also sells in-shop or on marketplaces keeps one honest stock figure across every channel, so the counter and the website cannot disagree
• Variant awareness — sizes, colours and bundles are stocked per variant, and a sold-out variant never blocks a product the buyer can still have.

We have watched real platforms learn the lesson that stock is money. We engineer it so the store never has to learn it the hard way.

10

Cart, checkout and the great abandon

The cart is where the purchase is decided and where most purchases are lost. Abandonment is not one problem — it is dozens of small rational refusals, each with a name: hidden delivery fee, no M-Pesa at checkout, a demand for details the customer does not want to type on prepaid data. We attack each one in the architecture:

• Every cost visible before the pin — delivery fee, pick-up option and any platform fee are shown before payment, so the customer never discovers a surprise charge after paying.
• M-Pesa first, forms second — the phone number is the primary identity; the customer pays with STK then completes delivery details, or completes them once and remembers them forever.
• Guest checkout without the guilt — a first-time buyer can pay and later link an account; forcing registration before payment is a known abandonment machine.
• Cart persistence server-side — the cart survives a refresh, a device switch, a network drop and a phone that dies at the PIN pad; the buyer returns to a live cart, not a dead end.
• Resume the abandoned push — a payment left pending can be resumed in one tap, keeping the customer inside the checkout instead of forcing a rebuild.
• Abandoned-cart recovery tied to real data — a scheduled recovery flow touches the customer through SMS or push with a link that returns them to the exact cart, measured for actual conversions.
• The 9-digit confirmation ritual — phone numbers are validated exactly as the mobile-money world expects, so payment and delivery contact cannot silently be wrong.

Every abandoned cart has a reason, and most reasons are ours to fix. We build the checkout so the customer only leaves when they genuinely changed their mind.

11

Fulfilment: the order becomes a parcel

An e-commerce site stops being a website the moment an order is confirmed — now there is a physical promise in the world. The order state machine carries the promise forward, so the buyer, the warehouse and the finance team all read the same truth:

• Paid → picked → packed → dispatched → delivering → delivered — explicit states with explicit transitions, so 'where is my order?' has one answer the whole company shares.
• Stock and fulfilment tickets born together — a confirmed order creates the picking instruction in the same transaction, so nothing is paid for and forgotten.
• Packing slips, labels and invoices generated from the order — documents are derived from the record, never re-typed by a tired human.
• Dispatch marks the handover — the moment the parcel leaves, delivery ownership moves to the courier or logistics partner, with the handoff recorded.
• Proof-of-delivery at the end — a delivered mark, a photo or a PIN collection closes the loop, and the order state becomes a searchable fact, not a rumour.
• Failure branches handled — a parcel returned, refused or lost moves through the appropriate repair path instead of silently disappearing from the timeline.

Fulfilment is where trust is either kept or spent. We build the state machine so the promise is observable at every step — for the customer and for you.

12

Delivery tracking that keeps buyers calm

In Kenya the customer usually knows delivery will take a day or two, and what they actually fear is silence. Tracking is not convenience; it is the mechanism that stops the 'where is my order?' flood to your support line. We treat it as an engineered channel:

• Status events on every transition — each state change pushes an SMS, push notification or in-app message, so the buyer hears from the system instead of chasing it.
• A tracking page that is honest — the customer opens a link and sees the same state the warehouse sees, with a realistic delivery window stated once.
• Courier integration where it pays — rider assignment, ETA and status can flow straight from the logistics partner into the same timeline.
• Estimated delivery that learns — windows are derived from real fulfilment data per area, not optimism, so the store stops promising what it cannot deliver.
• Delivered assurance — the delivery completion triggers the final message, the review request and the settlement of any pay-on-delivery fee, all from one event.
• Exceptions surfaced, not hidden — delay, redelivery and address problems become visible states the store can act on before the customer calls.

The calmer the buyer, the fewer the calls and the better the review. Delivery observability is a feature, and we build it as seriously as the checkout.

13

Returns, refunds and the quiet reverse

Returns are the part of e-commerce everyone hopes to skip and nobody can. A refund is not a favour — it is a payment event that must move back through the same rail it arrived on, matched to its original transaction, exactly once. We build the reverse flow with the same discipline as the forward one:

• A return request is an order state — the customer initiates, the store approves or declines against policy, and the reverse journey is tracked like any other order.
• Refund eligibility follows the policy, not the mood — return windows, condition rules and restocking conditions are configurable and enforced by the system, so staff never improvise.
• The refund matches the original transaction — it carries the source order and transaction reference, is applied once, and a retried refund request returns 'already refunded' with the original outcome.
• Money returns through the same rail — a B2C disbursement or revers-al moves the money back to the customer's M-Pesa, with the same idempotency as the original charge.
• Stock reconciles on acceptance — an approved return puts the item back on the shelf in the same transaction that logs the refund, so inventory and money move together.
• Disputes leave a record — every return, approval, decline and refund is on the audit trail, so 'what happened to this order?' reconstructs in minutes.
• Chargebacks and payment disputes handled explicitly — a card chargeback or a mobile-money dispute becomes a distinct state with evidence capture, so the store is not ambushed by its own ledger.

A good returns flow costs the store a little margin and buys it a loyal customer. We build the reverse journey so it never turns a sale into a burnt relationship — or a hole in the books.

14

The ledger behind every order

An e-commerce platform is a small holding company: customer payments in, delivery and cost of goods out, platform fees aside, refunds back. All of it must answer one question — does the money reconcile? — and the answer is not a spreadsheet ritual. It is a ledger with the same discipline our own wallets run on:

• Every order touches the ledger atomically — the sale, the fee, the stock movement and the money capture are one transaction, so none of them can drift from the others.
• Immutable and procedural — balances and journals change only through verified server procedures; a direct insert or update from outside is refused by the database itself.
• Revenue is separated from float — customer money and platform earnings live in distinct ledgers, so a refund or payout can never touch the wrong pot.
• Every movement carries a reference and an audit row — born in the same transaction as the money, so the trail can never be detached from the fact.
• Escrow semantics on settlements — money captured but not yet settled to the seller is held in an explicit state — held, released, reversed — never ambiguous.
• Three layers of protection on balances — a pre-flight check inside the row lock, an atomic decrement, and a database CHECK constraint that makes a negative balance a compile-time impossibility.
• Fees from a configurable table — delivery fees, service fees and commissions come from a maintained ranges table via one canonical function, so the app, the report and the receipt never disagree.

The storefront is what the customer sees; the ledger is what the business actually is. We build both, and we hold the ledger to the standard a regulator would recognise.

15

Reconciliation: the statement is the truth

However good your books are, the final truth on mobile money is the gateway's statement — Safaricom's record of what actually moved into your PayBill or Till. Reconciliation is the daily proof that the store's orders, the money captured, the refunds and the statement all agree, and it must be a system, not a month-end ritual:

• Match by gateway reference, line by line — every C2B confirmation and refund is matched to its gateway reference, never by amount-and-date guesswork.
• Total-your-side-versus-their-side — the store's day totals reconcile against the statement; a mismatch is an incident with an investigation, never a quiet rounding.
• Drill to the discrepancy — when totals disagree, the system isolates the exact lines, so 'which transaction is this?' has an answer before anyone starts guessing.
• Scheduled and unattended — a cron job runs the reconciliation, flags exceptions and pages the right person instead of waiting for a human to remember.
• Self-healing where legitimate — pending-at-cut and in-flight settlements are classified and parked, so only genuine anomalies reach a human.
• Survives up to millions of lines — batched matching and indexed references keep the daily reconcile fast as the store grows past 'end of day equals a shoebox'.

The first day your store's ledger matches the M-Pesa statement to the shilling is the day you know it is real. We build towards that day from the first sprint.

16

Fraud on the store: attacked structurally, not hoped away

Fraud is a feature of the environment on any commerce platform — fake callbacks, stolen M-Pesa numbers, co-ordinated voucher abuse, card-not-present attacks, delivery scams. None of it is stopped by a checkbox that hopes people behave. Every control below is structural:

• Rate limiting is a financial control — per-user, per-action windows (5-second budgets on money paths) at the gateway and inside logic, so an attacker cannot hammer the checkout API behind a CDN bypass.
• Callback verification by default — a fake 'paid' callback is structurally incapable of confirming an order, because only a verified gateway status settles a sale.
• Recipient and identity checks — delivery numbers and payout targets are validated and owned by the account, and self-dealing through store features is blocked before it arms.
• Voucher and abuse rules — discount codes carry per-user, per-order and total-budget limits, so promotion abuse is engineered out rather than detected later.
• Suspicious velocity flags — repeated attempts, same-number fraud patterns and abnormal order velocity push holds that require a human or an extra proof.
• Account freezes with a path back — suspected fraud freezes the account with a banner and an owner-informed recovery, so the legitimate customer is not left shouting into silence.
• An audit trail a regulator can read — every order, payment, refund and admin action carries actor, timestamp, reference and outcome.

The design goal is deliberately asymmetric: the legitimate customer completes a purchase in seconds with zero friction, while the fraudster meets a wall at every move. Structural rules, not hoping.

17

Concurrency: the sale both racers want

A flash sale begins, and a thousand customers hit the same five yellow-dress items at once. Two of them are on the same stock row, and the system must decide honestly. This is the same concurrency discipline that protects money on our own platform — applied to stock, wallets and order states:

• Row-level locks (FOR UPDATE) — the stock row and the wallet row are locked before the decision, so two payments physically cannot both decrement the last unit.
• Atomic check-and-write — the stock check, the lock and the decrement are one transaction; the system can never observe a state that was never true.
• Advisory locks plus SKIP LOCKED on sweeps — recovery jobs claim a lock and skip rows another run already holds, so overlapping runs cannot double-release, double-refund or double-notify.
• Terminal-state matching — an order already confirmed or refunded is matched and answered, never re-executed, no matter how many threads reach it.
• Dead-letter honesty — payment or fulfilment work that fails repeatedly sits visibly with its payload intact, so nothing is silently lost and nothing silently replayed.
• The same discipline on money — cart holds, deposit captures and refunds all move through locks, so 'the sale both racers wanted' has one winner and one clean loser with a full refund.

Concurrency bugs are the most expensive bugs in commerce because they only reproduce under load, at the exact moment everything is on fire. We engineer them out of the architecture — and prove it with tests that simulate the exact overlaps a flash sale produces.

18

Performance: fast in a real Kenyan network

Kenya's e-commerce traffic is overwhelmingly mobile, much of it on prepaid data and mid-range devices over a network that drops and flaps. A store tuned for a fibre office will feel broken on the phone in a matatu. Performance is not polish; it is conversion, and we treat it as an engineering requirement:

• Responsive-first, mobile-first — the store is designed and tested on the small screen first, because that is where the order actually happens.
• Images served compressed and sized — product photography is optimised on the way in and served at the right resolution, so megabytes do not stand between the customer and the product.
• Page weight as a budget — scripts, fonts and third-party trackers are counted and capped, because every kilobyte on prepaid data is the customer's money.
• Caching that does not lie — catalog pages and search caches aggressively, while stock and checkout always read the live truth so a steady page cannot sell stale stock.
• Offline resilience — a dropped network interrupts the journey without destroying it; the cart, the reference and the resume path survive the flap.
• Proven under the load you expect — we test the store at the traffic volume the business actually predicts, not the volume that fit on a slide.

A store that is slow on prepaid data taught its users to walk to the shop instead. We build stores that stay fast where the customer actually is.

19

Integrations that keep the store alive

An online store never operates alone. It sits between suppliers, couriers, payment gateways, SMS providers, analytics and frequently an accounting package. Every integration is a failure point and a data seam; we wire them so the store talks to its partners the way the store talks to its own ledger — exactly and observably:

• Payment gateways with verification loops — Daraja STK, C2B, B2B and B2C plus card processors wired with callbacks, idempotency and status confirmation, never fire-and-forget.
• Logistics and courier APIs — dispatch, tracking and delivery events flow into the order timeline through retried, queued integrations with explicit failure handling.
• SMS, WhatsApp and push providers — transactional messages carry delivery status, so 'did the customer get told?' is a query with an answer.
• Accounting handoff — daily sales, fees and settlements export cleanly into the client's books, matched by reference, so the store does not end up maintaining two disagreed ledgers.
• Marketplace and multi-channel sync — inventory and orders reconcile across channels through a single honest stock figure and a defined conflict policy.
• Webhooks with retries and dead letters — partner notifications are acknowledged, retried on failure and parked visibly when they keep failing.

An integration that fails silently is worse than no integration. We wire every seam with retries, verification and observable failure.

20

How we build and run stores

The process is the same whether we are building your store or extending the machinery that runs our own live platform. It is staged, honest and delivered in increments a business can absorb:

• 01 · The money audit — map every money movement in the current operation: what can double-charge, what cannot reconcile, what a fraudster would hit first.
• 02 · The catalog architecture — products, variants, pricing, images and search decided before the storefront, so the selling surface is grounded in real data.
• 03 · The order lifecycle — every order state and transition specified so 'exactly once' is a property of the schema, not an aspiration.
• 04 · The payment wiring — real sandbox keys, real callbacks, real verification loops against the gateway's status APIs, rehearsed under simulated failures.
• 05 · The ledger — accounts, entry types, references and the revenue/settlement split decided before screens; the books are the foundation.
• 06 · The fulfilment engine — picking, dispatch and tracking states connected to the order, your warehouse and your courier.
• 07 · The returns machinery — policy-driven eligibility, same-rail refunds and stock reconciliation built the same week as the sales flow.
• 08 · The conversion layer — carts, vouchers, recovery flows and analytics wired and measured from day one, not bolted on when traffic arrives.
• 09 · The tests — double-callback, race, flash-sale overload, network-drop, refund, reconciliation — the failure simulations are part of the build.
• 10 · The ops — monitoring on the money and order paths, the cron sweeps, the support logs and the 'where is my order' answer path.
• 11 · The growth — more channels, more volume, more markets — added to the same architecture, never as a bolt-on that breaks the books.

You own the storefront, the data, the ledger and the gateway keys. No hostageware — the commerce machinery is yours.

21

Honesty about e-commerce

Because the store spends real money, we are direct about the trade-offs — the ones a vendor who wants the logo would never mention:

• An online store does not fix a business that cannot fulfil — if picking, packing and delivery are broken, the beautiful website will surface the brokenness faster, not hide it.
• Delivery in Kenya is the hard reality — costs, wait times and rider availability are the things that most often disappoint customers; we design for the honest delivery picture, not the optimistic one.
• There is no such thing as fully automatic fraud-proofing — the controls are structural and powerful, but a determined adversary keeps testing; monitoring and response are part of the product.
• Marketing spend must be measured, not hoped — vouchers and campaigns that cannot prove a return are a habit, not an investment; we wire the measurement in before the spend begins.
• Sandbox is not production — a checkout that passed a sandbox test but skipped the verification loop is a paperweight; the truth is in the M-Pesa statement.
• The ledger reveals the truth — the day your first statement matches your books to the shilling is the day you know it is real; we build towards that day from the first sprint.
• You own it all — the code, the data, the keys and the books; nothing that sold should ever be hostage to a vendor relationship.

We will tell you honestly when your store does not need a full ledger-and-float build — and give you the smallest correct one. And when it does need the real thing, this is the real thing.

The toolchain

The e-commerce toolchain

This is the stack we use to build stores that close and reconcile — the same machinery that runs a live payments platform, applied to selling things. Every layer exists because a real order required it.

Lifecycle

The e-commerce lifecycle — from audit to scale

Building a store that sells, ships and reconciles is a standing discipline. This is the lifecycle every commerce build we deliver passes through — the same one our own platform runs on.

Closing

More than development

An online store is a sales operation with a checkout, a warehouse, a ledger and a promise. We build all four — and we build them to the standard a live payments platform demands. That includes:

E-commerce is web design plus a warehouse plus a bank — and the weakest of the three decides the experience. We build so none of the three can be the weak one.

We run one of these every day on money that is real. When you need a store, you get the machinery that survived being live — not the one that survived only a sandbox.