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 one bill shows the same amount everywhere.
• Credit bookCredit balances and repayments are checked against the bills behind them, including rounding and a payment sent twice.
• Bookings & tablesTests cover booking dates, table bills, discounts and settlement so the records stay linked to the right booking or bill.
• Staff & TeamTests check what each staff member may see, what happens when their access cannot be loaded, and switching between accounts. Staff can reach Team and private notes while customer inboxes stay protected.
• Sign-in & linked accountsTests cover signing in with Google, Apple or email, linking each to the right account, clashes between accounts, and never letting you remove your last way to sign in.
• 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.
• Plans & pricesThe Free, Plus and Pro comparison is checked against what each plan actually opens in a shop, and the “What Retriever replaces” figures are checked so each has one source and each plan’s total adds up.
• ZunoTests check that Zuno works only after you agree to OpenAI handling your questions, that taking the agreement back works, and that an answer never reaches the wrong account. Zuno's figures must come from records you may see. When Zuno reads a product photo, you still set the price and stock.
• Orders on a bad connectionIf the connection drops while an order is sent, tests check that trying again finishes the same order, for the same account, and never makes a second one.

Every update is tested first

Every update to the website must pass more than 3,500 automated tests, in more than 260 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.

The iPhone and Android apps, in the App Store and Google Play, show the same dashboard as the website.

Changes to the database and the server are released separately, each with the founder's go-ahead.

Tested on a real database

82 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.

Our tests show how Retriever behaves in the cases we try. Signing in with Google or Apple, Zuno's answers from OpenAI and payments also need checking on the live site, because a test on our own computer cannot prove them. We record those checks separately, and anything not yet checked stays marked as not checked.

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 the website’s test and check code from dated source snapshots.

By 9 November 2026 there were about 100,000 lines of test code, in more than 320 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.