How Retriever is designed and tested

Start with the shop’s everyday work

A feature starts with an action: adding a product, accepting an order, recording a payment or answering a customer. The design needs to make the next step clear and show what has changed.

We consider more than the successful path: an empty list, a missing detail, a failed request, a slow connection or someone without permission. The page should explain what happened and what the owner can do next.

What we check across Retriever

Different features need different checks. These are examples covered by the website’s tests, not a claim that every possible situation is covered.

• ProductsProduct details, sizes, units and photos are checked so the item a customer chooses matches the order you receive.
• CheckoutOrder totals, discounts and stock are checked together, including when two customers try to order at once.
• Stock & returnsTests check that a sale takes stock once and that returns put back the correct quantity.
• Bills & paymentsReceipt totals, tax calculations and payment records are checked so the same bill does not acquire different amounts.
• KhataCredit balances and repayments are checked against the underlying bills, including rounding and repeated requests.
• Bookings & tablesTests cover booking dates, table bills, discounts and settlement so the records stay linked to the right booking or bill.
• Staff & TeamTests check current shop permissions, failed membership reads and account switches. Staff can reach Team and private notes while customer inboxes stay protected.
• Sign-in & linked accountsTests cover Google, Apple and email routing, linking to the initiating account, account conflicts and refusing to unlink the last usable sign-in method.
• MessagesTests cover customer conversations, automatic-reply controls, message routing and the links shown in replies.
• ReportsSales, refunds, product rankings and date ranges are checked, including empty data that must not invent a result.
• Demo shopsA real database test checks that a demo shop refuses real orders and writes nothing, while real shops still take theirs.
• PricesThe plan prices and the “What Pro replaces” comparison are checked so each figure has one source and the total adds up.
• ZunoDatabase and client fixtures check explicit account-recorded OpenAI consent, revocation, account switches and late answers. Grounding checks keep figures tied to permitted shop records. Product-photo tests keep prices and stock under your control.
• Uncertain ordersTests replay the original order after a lost response, keep retries tied to the initiating account and prevent an uncertain result from becoming a second order.

Every update is tested first

Every update to the website must pass more than 3,300 automated tests, in more than 250 test files, before it goes live. It must also pass more than 50 check scripts, a check that the website's code fits together, and a full build. If even one fails, the update doesn't go out.

Database changes and server functions are deployed separately, with Retriever's founder authorizing the change.

Tested on a real database

73 test files start a real database inside the test and run Retriever's own database code in it, read straight from the files Retriever's database is built from. Some start from exact copies of the code Retriever's live database was running on 13 October 2026.

How we check each change

Each larger change goes through three separate automated reviews before it is accepted. Anything they stop, we fix before it goes any further.

Then we build the whole website again from exactly the files our web host receives, and every test runs again. We check phone layouts at iPhone size in WebKit, the engine Safari and Chrome use on iPhone.

When we try a change on the live site, we use our own demo shops, such as Banana Store, filled with made-up data. Not a customer's shop.

Every release needs the founder’s authorization and must pass the required checks.

Source checks and fixture tests show how the code behaves under the cases we exercise. Real Google, Apple, OpenAI and payment-provider flows need their own acceptance checks. A successful local build or screenshot does not prove that a production deployment or every external provider works. We record those results separately, and leave unverified flows marked as pending.

The tests keep growing

Tests are code too: small programs that run parts of Retriever and check the answers. These counts show how much test code is maintained; they do not measure coverage of every feature.

The chart counts website test and check code from dated source snapshots. It excludes the desktop app.

By 30 October 2026 there were about 90,000 lines of test code, in more than 260 test files and more than 50 check scripts for the website.

If something goes wrong

Your shop's data is copied every three hours, and every night with your photos too, to a separate company's storage. Each copy is locked so only Retriever's founder can open it, and kept for 35 days. On 12 October 2026 we brought a full copy back on a separate computer and checked that every file and every count matched.

Built with real shops

No software is perfect, and we won't pretend Retriever is. When a shop owner tells us something broke, we fix it, and we add a test where we can so the same bug doesn't come back.