How we test a system before it goes live

What we test with

We test with the real thing your system will handle: the emails it will send, with your wording and your photos, and the forms your customers will fill in. When a system uses AI to read enquiries or documents, we run it over real examples from your business and look for the ways it gets them wrong before you do. Health records carry one more rule: identifiable patient details never go to an overseas AI model, in a test or in use.

Nobody real is on the receiving end of a test. The customer in a test email is made up. To test every route a system sends email by, we point each one at a made-up address and swap the email and payment services for stand-ins, so a test can’t reach a real customer or charge a card.

Screens

Take a laptop with a 1366 × 768 screen. Once the browser has drawn its tabs and toolbar, and Windows its taskbar, about 650 pixels of height are left for the page. A heading and button that fit on a MacBook can fall below that line.

We learned that in September, when a side panel we’d measured at 1366 × 768 and passed turned out to be 43 pixels too tall for the page on a real laptop that size. Since then, 1366 × 650 has been one of the sizes every page of a website we build has to pass, and each page’s phone version is designed alongside the laptop one. At the other end, a page built only for laptops can leave its words in a narrow strip down the left of a 2560-pixel monitor, so we check that too.

Inboxes

When an email service says “delivered”, it means the other side’s mail server accepted the email. It doesn’t say whether it reached the inbox or the junk folder. So we send the real email from your real sending address, about a made-up customer, to a spam tester. It checks the email the way receiving mail servers do and scores it out of 10.

Some companies pass their mail through a security filter before Outlook opens it, and some of those filters strip the hidden instructions an email carries for Outlook. Without them, a photo meant only for phones can show twice and buttons can shrink to thin strips. Gmail and phones show the same email fine, so testing only in Gmail never catches it. Since October 2026, our check strips each email the way those filters do and rebuilds what Outlook would show, beside Gmail and phone widths. Each email is built to hold up in all of them.

Trying to break it

Since October 2026, when Ostley OS holds health or legal records, we try to break it before we hand it over. For each step, we ask who else could reach it and with what, then walk through it the way an intruder would, for example as someone who has got into your email.

“Nobody outside can read this” gets proved. Without signing in, we try to read every table and function in the database and check each one refuses. We check that nobody can make themselves an account, and that a password without its authenticator code opens nothing. Anything that isn’t covered yet gets written down.

The fresh AI auditor

We build with AI, and we check with it too. Whoever built something checks for what they expect to find, and that’s as true of an AI as of a person. So since 9 October 2026, before a build reaches you, a separate AI agent, started fresh, audits it. It gets the work and the bar it has to clear, and none of the builder’s reasoning. It picks the claims the work rests on and opens their sources instead of trusting ours, and it renders pages at laptop and phone sizes. Every problem it reports comes with its evidence. We fix what it finds and run it again until nothing blocking is left.

On 9 October, a fresh AI auditor caught a miscount in the draft of our first security audit, and we fixed it the same day.

For the part of a page people see first, the auditor also scores the work out of 10, and under 8 the builder goes again. An 8 doesn’t overrule you. If it still looks wrong to you, it goes back.

When something needs fixing

When you report a problem, “fixed” is a claim we have to earn before we send it. We wrote this down in September, after a fix came back looking almost the same as the problem it was meant to solve. A fix nobody checked turns your time into the testing.

1. View it at the same screen size and zoom you used.
2. Measure what you raised, such as a gap in pixels or how well text stands out from its background.
3. Put the after beside the before. If the two look nearly the same, it isn’t done.
4. Re-read your message word for word against the result.
5. Check the rest of the page for the same problem, and fix those too.

Our reply opens with a close-up of the after, so you can see it without going to check.

Launch day and after

At launch, one real test runs through the live system from start to finish. We check nothing leaked into your other systems, then delete what the test created.

After launch, a rule we set in October: you should never be the one who finds a broken button. Systems talk to other services with keys, and some keys expire. When a system depends on one of those, we set it to last a year and put its renewal date on our to-do list. The system also checks the key and emails us if it’s ever refused.

Questions to ask whoever builds yours

• Which screen sizes did you check, and was one a laptop with the browser’s bars showing?
• How does the email look in Outlook at a company that filters its mail?
• Who checked the work, other than the person who built it?
• What happens when a key the system depends on expires?

Ask us all four on the discovery call.