Fixed fee. Findings delivered whether or not you engage us to fix them.

Vibe Code Audit: A Fixed Fee Review of What You Actually Built

Vibe coding is the now common practice of describing what you want to an AI tool and accepting the code it produces without reading much of it. It genuinely works. It gets a founder from idea to running product in a weekend, and it has put real software in the hands of people who could never have written it. What it does not do is tell you what it left out, and the things it leaves out are consistently the same ones.

This is the productised version of that check. A known price agreed before we start, a defined scope, a written report ranked by real consequence, and a walkthrough where you can ask the awkward questions. Any repair is quoted separately, after the findings exist, because bundling the two gives whoever is doing the finding a reason to find more.

Book a Vibe Code Audit (03) 9003 0111

Realistic ROI

8 to 14 findings

Is the typical yield on a first review

That is what a first review returns in our own engagements: commonly two or three items with real consequence and a longer tail of smaller reliability and hygiene issues. A short report is a good outcome, not a failed audit

6 review areas

Define the scope, agreed in writing

Authentication and authorisation, database access rules, exposed secrets, input handling, error handling, and data exposure

5 to 10 business days

Is the usual turnaround from access granted

Faster if the application is small and access is ready on day one, slower if we are waiting on hosting console permissions

Two documents

Findings first, then a separate repair quote

You can take the findings to your own developer with no obligation, and plenty of clients do

Four Things That Make This Audit Different From a Scan

Automated tooling has its place and we use it. It is not what you are paying for, because the faults that matter in AI built applications are logic faults, and scanners do not understand your logic.

The serious faults are logic, not patterns

A scanner is very good at spotting a dependency with a known vulnerability or a hard coded string that looks like a key. It cannot tell you that a signed in customer can retrieve another customer’s order by changing a number in a request, because that requires understanding what the number means and who is supposed to own it. Almost every genuinely serious finding in an AI built application is of that second kind. It is found by a person following the data, not by a tool matching a pattern.

Findings are useless without consequence and effort attached

A list of fifty items with severity labels and no context is a way of transferring anxiety, not information. Each finding in our report says what it is, exactly how someone would reach it, what the worst realistic outcome looks like for your business, and roughly what it takes to fix. That is what lets you make a decision: fix these three now, schedule these four, and consciously accept the rest. Some findings are genuinely fine to leave, and we say which.

The audit is priced separately from the repair on purpose

If one number covers both the finding and the fixing, the party doing the finding is paid more for finding more. That is a bad incentive even when everyone is honest, and it makes the report impossible for you to sanity check. We agree the audit fee before starting, deliver the findings regardless of what happens next, and quote remediation afterwards against a specific list you can put out to anyone. It is a less profitable structure and a far more defensible one.

It is a point in time review and we will keep saying so

The report describes what was true on the days we looked, in the code and configuration as they then stood, using the methods described in the scope. It is not a certificate and it does not make an application secure. You will deploy changes, a dependency will update, a service you rely on will change a default, and your position will move. The value is an accurate picture now plus enough visibility, through logging, to notice the next problem yourself.

The Six Areas We Review

This is the scope, agreed in writing before we start. Anything outside it is named as out of scope rather than quietly skipped.

Who you are versus what you may do

Authentication and authorisation

We check how sessions are established, how long they last, what happens when one expires, and whether password reset and email change flows can be abused. Then, separately, whether every endpoint asks what the caller is permitted to do rather than merely who they are. Generated applications very often get authentication right and authorisation wrong, because hiding a menu feels like protecting a feature. We test by issuing privileged requests as an ordinary account.

Whether the data defends itself

Database access rules

Hosted databases can enforce, at the row level, who may read or write each record. We check whether those rules are enabled, whether they actually express your ownership model, and whether any table holding personal or commercial information is readable by an anonymous or arbitrary signed in caller. This is where the most consequential findings usually sit, and it is also frequently a same day fix once the ownership model is written down properly.

What ships to every visitor

Exposed secrets and keys

We inspect the client bundle, the repository history, and the hosting configuration for credentials that should never leave a server: payment provider keys, email sending keys, storage credentials, model provider keys, webhook signing secrets and service level database keys. Anything in the browser bundle is public, and credentials committed to a public repository are found by automated scanners within minutes. Findings here come with a rotation list as well as a fix.

What the server accepts

Input handling and validation

Every field that reaches a query, a file path, an email, a template or a page gets looked at. Some of what we find is a security issue: values passed into queries without parameterisation, file uploads with no type or size limits, user supplied content rendered without escaping. Much of it is a reliability issue that presents as a mysterious bug, such as an apostrophe in a surname breaking a search. Validation belongs on the server, not only in the form.

What happens when it fails

Error handling and observability

We look for failures that produce a blank screen, a spinner that never resolves, or worse, a silent success where the user believes something saved and nothing was written. We also check what your errors leak: stack traces and database messages returned to the browser tell an attacker a great deal. Finally, whether anything is recorded at all, because an application with users and no logging cannot be diagnosed after an incident, only guessed at.

What the server sends versus what the screen shows

Data exposure through the interface

A screen showing a name and suburb is often fed by a response containing the whole record, and a list view often retrieves every row and filters in the browser. None of it is visible in normal use and all of it is available to anyone who opens developer tools. We map what each endpoint returns against what the interface needs, and flag anywhere personal information, internal notes, pricing or other accounts are travelling to a browser that has no business receiving them.

What the Audit Covers, and What It Deliberately Does Not

Task	Traditional	What the audit gives you	Notes
Row level database rules	Assumed to be on because the tool set it up	Verified table by table against your ownership model	The single highest yield check on AI built applications. Frequently never enabled at all, because a new table is unprotected until someone switches it on.
Server side permission checks	Assumed because the menu is hidden	Tested by making privileged calls as a normal user	Interface visibility is presentation. The endpoint is the boundary that matters.
Secrets in the client bundle	Nobody has looked	Bundle, repository history and hosting config inspected	Comes with a rotation list, because a key that was exposed stays exposed until it is replaced.
File uploads	Works, therefore fine	Type, size, storage permissions and public URL behaviour checked	Open storage buckets are a common and quiet finding, especially where uploads are user photos or documents.
Error and failure states	Discovered by users	Mapped, with leakage of internal detail flagged	Improving these usually does more for how the product feels than any new feature.
Dependency vulnerabilities	Never checked	Automated check included, results triaged not dumped	Included, but it is the cheapest part of the review and rarely where the real risk sits.
Penetration testing	Often conflated with an audit	Explicitly out of scope	A code and configuration review is not an adversarial test. If you need the latter, say so and we will scope it separately.
Formal compliance certification	Sometimes expected from an audit	Explicitly out of scope	This report is not an ISO or SOC 2 artefact. It can inform that work, it does not substitute for it.

What You Should Insist On From Any Audit, Including Ours

A written scope before any money changes hands

You should know exactly which areas are being reviewed, which are not, what access is required, and what the deliverable looks like. Vagueness at this stage is how a review turns into an open ended engagement. Ask for a sample report structure if you have not bought one of these before. Anyone who will not show you the shape of the deliverable in advance is asking you to buy something you cannot evaluate.

The findings must be yours regardless of what you do next

A report you can only act on by hiring the author is not a report, it is a sales instrument. Insist that the deliverable is written so another competent developer can act on it without the author present, and that you are free to do exactly that. We build our reports that way and a meaningful number of clients take them to their existing developer. That is a fine outcome and it is one of the reasons the audit is priced independently.

Read only access at first, and credentials handled properly

An audit does not require the ability to change anything, so start with read only access to the code and the hosting or database console. Create a separate account for the reviewer rather than sharing your own login, and remove it when the work finishes. If you are asked to email a service level database key or paste a production credential into a chat window, that is a warning about how the rest of the engagement will be run.

Understand what a finding about personal information obliges you to do

If a review finds that personal information was accessible without authorisation, you may have obligations under Australian privacy law to assess whether it was actually accessed and, in serious cases, to notify affected individuals and the regulator within defined timeframes, and the assessment must be completed within 30 days. Whether the Privacy Act applies to you at all depends on turnover and on what you hold: as at August 2026, businesses turning over $3 million or less are generally outside it, but health information, trading in personal information and several other categories pull you in regardless of size. That is the first thing to establish, not the last. The assessment is also far easier while the logs still exist. Patching the hole first and then wondering is the sequence that destroys your own evidence, so raise it as soon as it is found rather than at the end of the project.

Do not accept a bundled audit and fix price

Even from us. When one fee covers finding and fixing, the incentive runs the wrong way and you have no way to test whether the list is honest. Separate documents let you price the repair against the market, split it across whoever you like, and defer the items you decide to accept. It costs the supplier some margin and it is the only structure that makes the findings independently credible.

Treat the report as a snapshot with a shelf life

The value decays from the day it is delivered. New code, updated dependencies and changed platform defaults all move your position. If the application is going to keep evolving, the useful investment is not an annual audit ritual, it is getting basic logging, error reporting and a deployment process with a rollback in place, so you can see problems yourself between reviews. We would rather leave you with that capability than with a recurring dependency on us.

How the Yes AI Audit Is Run

Fixed fee, agreed in writing, before anything starts

One number for the review, known in advance, not an hourly arrangement that grows with what we find. The repair is a second document produced afterwards against a specific list. If the scoping call suggests you do not need a full audit, we will tell you that instead of selling you one.

A report you can act on without us

Every finding written so a competent developer who has never spoken to us can implement the fix: what it is, how it is reached, the realistic worst outcome, and indicative effort. Ranked by consequence rather than by scanner severity. Delivered as a document you own, with a live walkthrough so you can push back on anything.

We will tell you when the answer is not what we sell

Sometimes the structure genuinely cannot carry what you want next and remediation is money into a hole, in which case we say rebuild and are happy for you to take that conclusion to whoever you like. Sometimes an application is in better shape than the owner fears and the honest report is short. A short report is not a failed audit.

Straight about what you are really asking for

A good share of the people who book an audit actually want somebody to finish building the product. That is a legitimate and much larger engagement with a different shape and a different price, and it is far better established on the first call than discovered halfway through. Tell us if that is where you are heading and we will scope it honestly.

How a Vibe Code Audit Runs

Five steps from first call to a ranked list. It stops at the list on purpose.

Scoping call

What it was built with, what it does, who uses it, what data it holds, and what is worrying you. Twenty to thirty minutes. We confirm whether an audit is the right purchase or whether a shorter conversation would serve you better.

Scope and fee agreed in writing

The six review areas, anything explicitly excluded, the access required, the deliverable format, and the fixed fee. Nothing starts until you have that document and are comfortable with it.

Read only access provisioned

A separate reviewer account on the code repository and the hosting or database console, with read permissions only, removed at the end of the engagement. No production credentials by email or chat.

The review

Manual review across the six areas, supported by automated checks for dependencies and exposed strings. Findings are reproduced and evidenced rather than asserted, so each one comes with the exact steps that demonstrate it.

Report, walkthrough, and a separate repair quote

Written findings ranked by consequence, delivered and walked through live. If you want the work done, remediation is quoted as its own document against that list. If you want to take it elsewhere, the report is written so you can.

FAQ

What is a vibe code audit?

It is a structured review of an application that was largely generated by an AI coding tool rather than written line by line. The term vibe coding describes building by describing what you want and accepting the output without reading much of it, and the audit exists because that method produces a recognisable set of gaps. In practice it is a technical and security review across six areas: authentication and authorisation, database access rules, exposed secrets, input handling, error handling and data exposure. The deliverable is a ranked written report, not a pass or fail verdict.

What does the report actually contain?

Every finding is written up with four things: a plain description of what it is, the exact steps showing how it is reached so you can reproduce it yourself, the realistic worst outcome for your business if it were exploited or simply encountered by an ordinary user, and an indicative effort to fix. Findings are ordered by consequence rather than by an abstract severity score. There is also a short summary you can hand to a board or an investor, a list of credentials that need rotating if any were exposed, and an explicit statement of what was out of scope.

How long does it take and what do you need from me?

Five to ten business days from the point access is working is the usual range, faster for a small application where access is ready on day one. What we need is read only access to the code repository and to the hosting or database console, ideally as a separate reviewer account rather than your own login, plus about thirty minutes of your time to explain what the application is meant to do. The ownership model matters most: who is supposed to be able to see what. Without that, we can only guess at whether a rule is wrong.

How much does it cost?

It is a fixed fee agreed in writing before we begin, so your exposure at the audit stage is known and capped. The number depends on the size of the application and how many distinct user roles it has, and it is set on the scoping call once we understand those. Remediation is quoted afterwards as a separate document against the specific findings, and larger structural work sits within our consulting ladder and is scoped properly rather than estimated on a phone call. We will not give you one combined figure covering both.

Will my app be secure once you have finished?

No. An audit is a point in time review and nobody should describe an application as secure on the strength of one. What you get is an accurate picture of your position on the days we looked, a set of specific faults with fixes, and, if you take the remediation, visibility through logging that you did not have before. Tomorrow you will deploy a change, a dependency will update, or a platform will alter a default, and your position will move. Treating a report as a certificate is how organisations end up confidently wrong.

Is this the same as penetration testing?

No, and the difference is worth understanding before you buy either. A code and configuration audit reads the application from the inside, with access to the source, looking for faults in logic, permissions and handling. A penetration test attacks it from the outside with limited knowledge, looking for what an adversary can achieve in practice. They find overlapping but different things. For a young product built with an AI tool, the audit almost always finds more per dollar, because the faults are structural and visible in the code. If a customer or an insurer is specifically requiring a penetration test, that is a separate scope and we will say so.

Can you just fix everything as you go?

We deliberately do not, and it is worth explaining why. Fixing during the review means you never see the unfiltered findings, cannot price the work against the market, and cannot verify that the list was honest, because the evidence has been repaired. It also means the review stops being a bounded, fixed fee purchase. So the audit stops at the ranked list, then you decide: fix everything with us, fix the serious items only, take the list to your own developer, or accept the risk on some of it deliberately. All four are reasonable and we have seen clients choose each of them.

Know What You Built, at a Price Agreed Up Front

Book a scoping call. Twenty minutes, no charge, and you will leave knowing whether you need the full audit, a couple of targeted checks, or nothing at all. Call (03) 9003 0111 if you would rather talk it through first.