FaultFound

Home Results

We have no customer case studies yet. Here is what one will look like.

FaultFound is new. Rather than dress up examples as client work, this page shows the exact structure a real case study will use — worked through on scenarios that are clearly labelled as examples.

Nothing on this page describes a real business. Every domain, company name and figure below is invented for illustration. When we have completed repairs for customers who are happy to be named, their stories will replace these — with their permission, and with the evidence to back them.

Worked examples

Problem, evidence, impact, repair, verification, outcome.

Six stages, every time. This is the template a genuine case study will follow, so you can judge in advance how much substance one will contain.

Checkout fails at the delivery step

Example scenario — not a customer

Problem

An online retailer's basket and first checkout screen work normally. Selecting a delivery option returns a server error, so no order can be completed.

Evidence

HTTP 500 on three separate visits over two days, confirmed independently in a real browser.

/checkout?step=delivery

Customer impact

Every customer reaching payment is blocked. The homepage and product pages stay healthy, so nothing alerts.

Repair

Diagnosis points at the delivery-rate calculation path. The pack ranks likely causes, names the component to inspect and gives the log locations to check.

Verification

The same route is walked again after deployment: basket, checkout, delivery selection, all the way to the payment screen.

Outcome

Written confirmation that the route now completes, with the new response codes and timestamps recorded alongside the originals.

The booking button points at a retired provider

Example scenario — not a customer

Problem

A restaurant changed booking systems. The navigation was updated but the main homepage call to action still points at the old provider.

Evidence

The primary booking button resolves to a 404. Reproduced on desktop and mobile viewports.

/book-a-table

Customer impact

The most prominent booking route on the site fails. Customers who use the navigation instead are unaffected — which is why nobody noticed.

Repair

Identify every reference to the retired provider across templates, update them to the current system, and add a redirect for the old path.

Verification

Re-crawl the public pages for any remaining links to the old provider, and confirm the redirect resolves.

Outcome

Confirmation that the homepage booking route reaches the live system, with no remaining public references to the old one.

One product page down, the rest of the shop healthy

Example scenario — not a customer

Problem

A single high-value product page returns a persistent server error while several hundred other product pages respond normally.

Evidence

HTTP 500 on three checks across two days. Neighbouring products in the same category return 200.

/products/workbench-1800

Customer impact

One product cannot be viewed or bought. Because it is a single page, no site-wide monitoring registers anything wrong.

Repair

Isolate what differs about this record — a missing variant, a broken media reference or a corrupted field — and correct it.

Verification

Load the product page, add it to a basket, and confirm the same fault does not exist on sibling products.

Outcome

The product page returns 200 and behaves like the rest of the catalogue, confirmed in writing with before-and-after responses.

Contact page loads, enquiry route silently fails

Example scenario — not a customer

Problem

A trade business's contact page renders perfectly. The endpoint the form posts to returns an error, so enquiries never arrive.

Evidence

The page returns 200 while its submission endpoint returns 500. Observed without ever sending an enquiry.

/contact/enquiry

Customer impact

Prospective customers believe they have made contact. The business assumes a quiet month.

Repair

Restore the mail handler or form integration, add error handling so a failure is visible, and confirm delivery to the real inbox.

Verification

The business sends a test enquiry themselves. We re-check that the endpoint now returns a success response.

Outcome

Enquiries arrive again, and a visible error state exists so the same silent failure cannot recur unnoticed.

When real results appear

The rules this page will keep following.

A published case study will always

  • Be published only with the customer's written permission
  • Describe a fault we genuinely found and documented
  • Show the evidence, including the response codes we recorded
  • Describe the repair that was actually carried out
  • Say who implemented it, if it was not us
  • State plainly what we do and do not know about the impact

It will never

  • Invent a revenue figure we cannot evidence
  • Claim a percentage uplift we did not measure
  • Use a customer's name or logo without permission
  • Describe a competitor's work as our own
  • Present an example scenario as a real customer
  • Quote a review score we cannot link to its source
On "revenue recovered" claims: we can prove a route was broken and that it now works. We cannot know how many people hit it while it was broken, or how many of them would have bought. Any figure claiming otherwise is guesswork dressed as data, and you will not see one from us.

Judge us on the report, not the marketing.

The sample report is the honest version of a case study: real structure, demonstration data, nothing claimed that isn't shown.

Open the sample report About FaultFound