Application
Audit
I go through the app you're about to launch and tell you where it loses money, data or trust — ranked, with the fix for each, and a way to reproduce every one.
- Takes
- from 5 working days
- Costs
- from €3,300
- You get
- A written, ranked report and the fixes
Who this is for
- 01
You have an app that works in a demo — often built fast, or with AI tools — and a launch date close enough to be nervous about.
- 02
You take payments or hold other people's data, and nobody has checked the code that does it from the outside.
- 03
A customer, an investor or an auditor just asked “how do you know this is safe?”, and you want a straight answer.
Not for: a design review, a performance pass, or building the features themselves. I do those as separate work.
What would I find in your payments?
The fastest area to check yourself. Answer honestly; “not sure” is an answer. You get the list of what is probably wrong, in the order I would look, and a link you can send to your engineer.
- 01 · Duplicate charges
If a customer double-clicks Pay, or your app retries after a timeout, can the same charge be created twice?
- 02 · Balance races
Where is “does this customer have enough balance or credit?” decided: in your application code, or inside the database in the same statement that deducts it?
- 03 · Illegal state changes
Can the same order be refunded twice if two people click at the same moment?
- 04 · Illegal state changes
Is there a written list of order states and allowed transitions that the code cannot step outside of?
- 05 · Webhook replay and order
Do you verify the signature on every webhook from your payment provider before acting on it?
- 06 · Webhook replay and order
If the provider sends the same webhook twice (they do), does your system act on it once?
- 07 · Webhook replay and order
If “captured” arrives before “authorized”, does the order still end up in the right state?
- 08 · Ledger drift
Can you rebuild any customer's balance from a list of entries, or is the balance a single number that gets overwritten?
- 09 · Reconciliation
Do you compare your records against the provider's settlement report automatically, and do you know yesterday's difference?
- 10 · Ledger drift
Is money stored as whole minor units (cents) in integers, never as floating-point numbers?
0 / 10 answered
What I check
Five areas where an app that works in a demo quietly fails in production. Each one is reproduced live in the lab, against a real Postgres, so you can see the failure before you believe me.
- 01Part 4.1
Access & tenancy
One client opens another's data by changing a number in the address, or a full-rights key sits in the browser and ignores every rule.
I check: Whether every request proves the thing is yours — in the code and again in the database.
See it happen → - 02Part 2
Payments
A charge runs twice, a forged message marks an invoice paid, money is a decimal that drifts a cent at a time.
I check: Idempotency keys, webhook signatures, balances in whole cents. The 10-question self-check below is this area.
See it happen → - 03Part 4.2
The AI
The support bot reads every client's files to answer anyone, and personal data in a brief leaves for the model.
I check: Whether the AI only reads what the person asking may see, and what gets swapped out before anything is sent.
See it happen → - 04Part 4
The data
Deleted files still answer, share links never expire, and nobody can say who opened what.
I check: Real deletion, links that are signed and expire, and a log of who looked that can't be quietly edited.
See it happen → - 05Part 5
Backups, secrets, releases
Backups that were never restored, secrets printed to the logs, releases straight to production from a laptop.
I check: A restore that's actually been tested, secrets kept out of logs, a staging copy and a way to roll back.
See it happen →
How it works
Read access and one hour of your engineer's time. That is the whole ask.
- Day 1
Read access to the repo and an hour with whoever owns it. I run it myself and map how it fits together: how you log in, where the data lives, how money moves, what the AI reads.
- Days 2–4
I read the code and the database, trace real actions, and try to break it: who can see what, how a payment is taken, what leaves for the AI, and what the backups, secrets and deploys look like. Where I can, I reproduce the failure against a copy.
- Day 5
Written report and a one-hour call. Every finding has a severity, where it lives, how to reproduce it, and the fix.
You get
- Ranked findings: what hurts first.
- Reproduction steps for each, so your team can verify before and after.
- The fix, as a diff or as SQL, not as a paragraph.
- What to monitor so the same class of bug cannot return quietly.
From production, not from a book
The list above is not a framework. It is the bugs I have met in code I was paid to fix or build: a refund that could run twice, a client who could open another's data, balance checks that did not hold. The cases have what I can say under NDA.
Read a full report, start to finish →Find out before
your customers do.
Thirty minutes. You describe how your product works; I tell you what I would look at first and whether the audit is worth your money.