Skip to content
Case studies

What we found, what we changed, and what it measured after.

Five engagements written up in full: the failure modes we walked into, the work we did, and the numbers on both sides of it. No logos, no adjectives, no findings we did not actually file.Composite engagement. Details anonymised; figures are representative.

Book a Free CallSee what an audit covers

How to read these

Every study on this page is a composite. Each one is assembled from several engagements that shared the same failure pattern, with names, industries, and identifying details changed or removed. The figures are representative of what we measured - they are not attributed to any named client.

  • Each study merges several engagements that shared one failure pattern.
  • Roles are given without names; no client or company is identified.
  • Numbers are what we measured, rounded - never projections.
At a glance

The five studies, added up

Everything below is derived from the tables on the individual pages, so the totals and the details cannot drift apart.

  • 5composite studies

    One for each builder platform we see most often.

  • 21critical and high findings closed

    Out of 31 findings filed across the five.

  • 2–5 weeksfrom kickoff to handover

    The audit that precedes each one takes 3–5 business days.

  • $1,305 / monthnet infrastructure change

    4 of the 5 cost more to run after hardening. One migration paid for all of them.

Hardening usually costs a little more to run, not less. Staging environments, point-in-time recovery, log retention and always-on instances are all line items that a demo does not pay for. The one engagement that cut its bill did so by removing work the product never needed - not by removing safeguards.

The write-ups

Five apps that worked in a demo

Each one shipped, had real users, and was one request away from a problem its founder could not see.

Browse by platformLovableReplitBase44Claude CodeBubble
The common thread

What keeps turning up

These six findings account for most of the critical work in the studies above. They are what we look for first, in that order, on every audit.

  • Access rules that are on but mean nothing

    Row-level security enabled with a policy that matches every authenticated user is the single most common critical finding we file.

  • Privileged keys shipped to the browser

    Service-role keys, admin tokens, and third-party secrets inlined into client bundles, where reading them takes one keyboard shortcut and no expertise at all.

  • State on a disposable disk

    SQLite files and uploads written to a container filesystem that is replaced on every deploy.

  • Queries that were never going to scale

    Unbounded selects, missing indexes, and searches nested inside list views. Instant at demo volume and the first thing to fall over when real data arrives.

  • No route from a commit to production

    Manual deploys from one laptop, migrations pasted into a shell, and a rollback plan that nobody has ever performed.

  • No way to know something broke

    No error tracking, unstructured logs with no retention, and no alert that reaches a human being.

Every one of them started the same way

A free consultation and a scoped audit. What happens after that depends on what the audit finds.

Want your app written up like this?

Send us a repo link and a paragraph. The audit is free and the report is yours either way.

Book a Free Call