Data exposure
What a stranger can pull out of the database with nothing but a browser and a little curiosity.
Case study
Wildlife Lookout went live — without a launch-day surprise
- Live · wildlifelookout.org
- Consulting + safe launch
A treehouse adventure that teaches children about wildlife and ecosystems. The product was theirs. Getting it safe, stable and ready for real visitors was ours.
Live
In front of real visitors
Public at wildlifelookout.org — not a staging link.
6
Failure areas read
Data, secrets, auth, drift, load, untested paths — each by a human.
1
Go / no-go call
Findings first, fix plan second, launch decision last.
Fixed
Scope and price
Priced per verified change, approved before any of it started.
The brief
An app that was nearly ready — and about to meet children
Wildlife Lookout teaches kids about wildlife and ecosystems through a treehouse adventure. By the time we were called in, the product existed and worked. What nobody could say with confidence was whether it would hold up once strangers arrived.
That is the gap a safe launch closes. Not another feature, not a redesign — an honest read of everything that could go wrong in public, a plan to close it, and a launch call made on evidence instead of nerve.
- Security read
- Stability
- Go-live readiness
- Fix plan, in order
- Verified changes
How we framed it
It works isn't the same as it's safe. Launch day is where the difference stops being theoretical.
What was actually at risk
Launches rarely fail on features
They fail on the things nobody looked at: an open database, a key that shipped to the browser, a route that forgot to ask who you are. Here's what we changed about how this launch was approached.
The usual launch
How this one ran
Ship it and see. Problems get found by users.
Read the whole app first, then decide whether it's ready.
A security scan output nobody can act on.
Findings in plain language, ranked, each with the fix named.
Open-ended hardening work, billed as it goes.
A counted list of changes, priced and approved before we touched anything.
Fixes marked done because the code changed.
Each change verified against the finding it was meant to close.
Launch day is a hope, and the team crosses its fingers.
Launch day is a decision, made together, on what we found.
What we read
Six places an app comes apart in public
The same six every time — not because it's a checklist we run and forget, but because this is where products break when real people arrive. Each one read by someone who has seen it go wrong before.
Keys & secrets
What got shipped to the browser, what's sitting in the repo, and what should have stayed on the server.
Auth & access
Who can sign in, who can act as somebody else, and which routes forgot to ask for permission at all.
Drift from intent
Where the build quietly diverged from what was asked for — the rule that got dropped somewhere along the way.
Under real load
The queries, limits and background jobs that hold fine for one visitor and buckle at a thousand.
Untested paths
Sign-ups, uploads, edge cases — the flows nobody has run twice, where silence looks like success.
How it ran
Read it, price it, fix it, then launch it
Four steps, in that order, with an approval between each one. Nothing after the audit started without the client seeing what it would contain and what it would cost.
-
The read
Before anything is touched- Full security read — row-level security, exposed keys, auth and access gaps
- Structural health of the code, and where it drifted from the intent
- What's untested, and what that puts at risk on day one
- Behaviour under load, not just under a demo
-
The plan, in plain language
Approved before we start- Findings ranked by what actually matters, not by tool severity
- Each finding paired with the change that closes it
- A counted list of changes and an exact price for them
- The client decides what's in and what waits
-
The fixes
Verified, not just shipped- Every approved change made against a named finding
- Each one verified to close what it was meant to close
- Nothing added quietly — scope stays where it was agreed
- A verification summary they can hand to anyone who asks
-
Go live
A decision, together- Readiness reviewed against the findings, one by one
- Anything still open named out loud, not buried
- Launch called on evidence — go or no-go
- Live at wildlifelookout.org, in front of real visitors
The result
The launch stopped being a hope and became a decision.
What they got
A public launch they could stand behind, and a written record of what was checked and what was fixed to get there.
What changed
Security, stability and readiness moved from assumptions to things somebody had actually looked at and closed.
What stayed theirs
The product, the idea and the credit. We didn't build Wildlife Lookout — we made it safe to open the doors.
Wildlife Lookout is their product and the credit for it is theirs. Our part was the launch: reading the app for the ways it could hurt them in public, fixing what mattered, and making the go / no-go call with them.
Questions
What a safe launch actually is
You didn't build Wildlife Lookout — so what did you do?
We hardened it for go-live. The app already existed and worked; what it hadn't had was an honest read of how it would behave with strangers in it. We did that read, produced a ranked fix plan, made the approved changes, verified each one, and called launch readiness together. Greenfield builds are a different engagement — that's DevStudio.
Why does a working app need this at all?
Because it works and it's safe are different claims. An app can do everything in the demo and still leave its database readable, its keys in the browser bundle, or a route that never asks who you are. Those don't show up in a walkthrough. They show up the first week you're public.
What exactly gets looked at?
Six areas, every time: data exposure, keys and secrets, auth and access, drift from what you meant, behaviour under real load, and untested paths. Each is read by a human, not just scanned. The full method is on the Coherence & Security page.
How is it priced?
The audit is a fixed one-time price. The fixes are priced per verified change, and the audit sets the count — so you see the number and approve it before any work starts. No open-ended hardening budget.
What happens after launch?
A fixed app should stay a fixed app. The Safe-Change Layer reviews every significant change before it becomes a problem — so new work doesn't quietly reopen what was just closed. It's optional, and it's added after the fixes, not sold with them.
Before you launch
Find out what's in there before your users do
If you're weeks from going live and nobody has read the app for the ways it could hurt you, that's the call to make. You'll get findings you can act on and a price for closing them.
01
A short call
You tell us what you've built, how it was built, and when you intend to be live.
02
The read
A few business days later you have findings in plain language, ranked, each with its fix named.
03
Your decision
You approve the changes worth making — or you take the report and do it yourself. Both are fine.