Auditing an app built with AI: what the founder needed to hear

How it started: the founder wanted to know whether his AI-built product would hold up · Duration: July to October 2026

Overview

The founder is not a professional developer. He built the product himself, with AI. The product worked, and customers paid for it.

He wanted to know three things. Will it hold up? Can he let a second developer into the code? And could one bug sink him?

The moment: the first sentence of the verdict

The full audit was long and correct. Nobody would read all of it. So the first sentence of the verdict said: "None of this is Armageddon."

Most of the important fixes were a few hours each. The founder needed to know where to start, not to hear that everything was wrong.

What we found

The code was not bad. It was inconsistent. That is typical for AI-written code.

AI does a security check well in one place and skips it in the next. Settings that should be mandatory stay optional. Operations often depend on one person. AI will write the code for you. It will not tell you what you forgot to set up.

How we verified it

A security test must not cause the incident it is looking for. So we proved the holes without downloading a single file. Often the difference in the server's response between a protected and an unprotected place is enough.

No real data, no password guessing, no writes. The report ends with a list of what we did not do.

What the founder got

We split the audit into three parts:

• a short verdict of a few pages with things for one evening,
• findings with exact places in the code,
• standards he can come back to as development continues.

We did not write the recommendations as "this is hurting you". We wrote what a fix unlocks for him: a second developer, the first security questionnaire from a customer, a calm weekend.

What we advised against

The audit offered an easy sale: a big rewrite and a new architecture. We wrote the opposite. The current code structure is enough. Stricter rules in the code come step by step, starting with login and permissions. No big rewrite all at once.

The most expensive advice is technically correct and comes too early.

What went wrong

We sent the first findings as a list right after the first call. A list alone was not enough. Things customers see come first. Things nobody sees until they break can wait. That is why the verdict has an order of steps, not just a list.

What changed

The founder knows what is under the surface of his product. He has an order of steps he can handle on his own. The code and everything we wrote down belong to him.

What we delivered