Service · Audit and maintenance

Audit your AI-built app before real users find the problems.

I analyse the code, permissions, dependencies, performance and tests to tell you what is ready, what isn't and what should be fixed first.

I want my app reviewed See the process

Code review · Security · Tests
Prioritized findings
Optional maintenance

The risk

A feature that looks fine is not necessarily safe

Demos are tested on the happy path. Real users take every other path. These are the problems that often stay hidden in an AI-generated application.

Permissions checked only in the interface

The button disappears, but the API still accepts the operation. Anyone with the right request can reach other people's data.

Exposed secrets

Keys in the frontend, in the repository or in variables that should never be public.

Silent failures

Operations fail without warning: a payment isn't recorded, an email isn't sent or a record is saved halfway.

No tests on critical paths

Every change can break login, signup or payment without anyone noticing until it happens.

Dependencies and maintenance

Outdated packages, incompatible versions or code nobody will know how to update in six months.

Performance that was never measured

Repeated queries, missing indexes or unnecessary loading that shows up when real users arrive.

The approach

An honest review, with priorities and no alarmism

An audit is not a two-hundred-page document written to justify a rewrite. It is an assessment of what exists, with evidence and an order of work that makes sense for the business.

I review the code and how it runs: configuration, database, permissions, dependencies and critical flows. Then I separate what blocks launch from what can wait.

I can't certify that an application is invulnerable after a one-off review. I can tell you which risks I see, which are reasonable to accept and what I would do first.

The result depends on the access you have to the code and the agreed scope. Reviewing one part is not the same as auditing the whole system.

Review of architecture and code organisation.
Authentication, authorization and data permissions.
Secrets, dependencies and configuration.
Performance and queries on the main flows.
Tests on the paths that cannot fail.
A report with findings, severity and next step.

What's included

From a focused review to ongoing maintenance

You can book a closed review or turn it into a maintenance relationship. The decision depends on what it finds and what you want to do next.

Review of AI-generated code

The problem: The project grew through prompts and nobody has reviewed the full structure.
What I do: I analyse readability, duplication, error handling, layer boundaries and consistency with the stack.
What changes: You know which parts are maintainable and which should be rebuilt.

Authentication and permissions review

The problem: It isn't clear who can see or modify each piece of data.
What I do: I review login, sessions, roles, server-side checks and resource access.
What changes: Permissions stop depending on the interface hiding a button.

Dependencies, secrets and configuration

The problem: There are old packages, misplaced keys or different settings between environments.
What I do: I review versions, known vulnerabilities, variables and information exposure.
What changes: Less risk surface and an understandable configuration.

Performance and database

The problem: The app responds with little data, but you don't know how it behaves under volume.
What I do: I review queries, indexes, caching and the load of main routes.
What changes: Bottlenecks identified before users arrive.

Tests on critical paths

The problem: There is no safety net and every change feels risky.
What I do: I add tests to the flows that cannot break: access, signup, payment, primary data.
What changes: You can change with more confidence and catch regressions.

Maintenance and development

The problem: After the review, someone has to execute fixes and keep evolving the app.
What I do: I fix, update, build and maintain within an agreed scope and regular reviews.
What changes: The application doesn't end up without a technical owner again.

Who it's for

When reviewing before continuing makes sense

An audit isn't a mandatory step for everyone. It fits when users, money or sensitive data are involved, or when the team has lost confidence in the code.

Before a launch

You want to know what blocks production and what can be fixed afterwards.

With an app already live

There are recurring errors or incidents nobody can fully explain.

When inheriting an AI-built project

You received code that works, but you don't know whether it is safe or how to maintain it.

Before expanding the product

You need to understand technical debt before adding features or taking payments.

How it works

A review with clear scope and a plan you can execute

First we define what is and isn't reviewed. Then I deliver evidence-based findings in priority order; fixes are a separate step.

01
We define the scope
Which parts, which flows and what access I have to code and environment.
02
I review the system
Code, permissions, configuration, dependencies and critical routes.
03
I prioritize findings
I separate blockers from what can wait and explain the risk.
04
I deliver the report
Findings, evidence and recommended next step, without filler.
05
I fix or maintain
If you continue, I execute fixes and can stay on maintenance.

Frequently asked questions

What to know before an audit

What does an AI-generated code audit include?

It depends on the agreed scope, but it can cover architecture, readability, permissions, secrets, dependencies, performance, error handling and tests. The report separates risks and priorities.

Can you guarantee my application is secure?

No. A one-off review reduces known risks, but it doesn't certify a system as invulnerable. If you need certification or a formal pentest, I'll point you to the right kind of specialist.

How long does a review take?

It depends on size and scope. I don't give firm timelines without seeing the project; first I review what exists, then I propose a realistic scope.

Do I have to give you full repository access?

Usually yes to review the code, but it can be limited to a branch, an environment or a set of files. Access is agreed beforehand and revoked when the work ends.

Are you going to tell me to rewrite everything?

Not by default. A rewrite is an option when the cost of maintaining what exists is higher, not an automatic conclusion. If I recommend it, I explain why and what the alternatives are.

Can you fix the problems you find?

Yes, as separate work or within a maintenance plan. The audit is for deciding; it doesn't by itself include every fix.

Is it worth auditing an app with no users yet?

It can be worth it if you're going to invest in it, if it handles sensitive data or if you want to avoid carrying difficult decisions forward. For a purely exploratory prototype, a narrower review may be enough.

Do you offer maintenance after the review?

Yes. It can be occasional maintenance or an ongoing collaboration, with an agreed scope and cadence. I don't sell blocks of hours without first understanding what the application needs.

Contact

Tell me what you want reviewed and what depends on it

You don't need to know what's wrong. Tell me what worries you and which decision depends on the review.

What helps to include

What the application is and what state it's in.
Whether it already has users or hasn't launched.
What worries you: security, errors, performance or maintenance.
Which tool built it and which stack it uses, if you know.
Whether you can give access to the repository or a test environment.

Don't share credentials in the form. If the review goes ahead, we agree limited access and revoke it when the work ends.

Related help

If the next step is something else

Related service