FREE TOOL

Vibe-coded project readiness check

Seventeen questions you can answer without reading code: how the project was built, who can change it, what data it handles, where secrets and backups live, how it is hosted and who would notice an error. 'I do not know' is a valid answer and a signal of its own. The result says how far the project is from safe real use, which risks the answers reveal, what a review would look at first and the recommended next step: fix, stabilise, rebuild or launch with conditions.

HOW IT DECIDES

Structure and data decide, not the tool that built it

Each risk is weighed by what the project handles and whether it is already live.

Credentials in the code, no backups, no access control, no repository and hosting on someone else's account are serious on their own; with accounts or payments, more answers become serious.
Two serious risks, or one with payments involved, means not ready. One serious or three medium ones means usable with conditions.
'I do not know' is scored as a medium risk, because it usually is, and it is exactly what a review resolves first.
A rebuild is only recommended when the structural pieces are all missing; everything else is fixed in order.

WHY CARE AFTER LAUNCH

A fast build needs someone watching it

AI tools and rushed builds produce working software with nobody responsible for it the day after.

Monitoring turns the first error into an alert instead of a lost customer.
Dependency and platform updates close the vulnerabilities found after the build.
Backup checks make sure a restore works before it is needed.
A security rhythm and current documentation keep the next change from undoing the review.

HONEST LIMITS

What this check does not do

It does not read your code. It scores what you know and do not know about the project; the review reads the repository, the configuration and the deployment.
It does not give a price. Review scope depends on the size of the project and the access we get; we agree it after a first look.
It does not judge the tool. AI-built, no-code and rushed projects can be perfectly sound; the questions are about structure, data and ownership.
It does not replace testing. Even a close-to-ready project gets its launch conditions from a review, not from a questionnaire.

Questions about the check

The build works perfectly. Why would it not be ready?

Because working in a demo and surviving real use are different tests. Real use brings concurrent users, wrong inputs, expired tokens, a full disk, a platform update and someone poking at the admin URL. The questions here are about exactly those moments, and most AI-assisted builds have never faced them.

Do you criticise the person who built it?

No. The goal is to know what is safe to keep, what needs fixing and what should not be built on. Many AI-assisted builds have good design and flows and weak plumbing; we keep the first and fix the second. If the project is in better shape than you feared, we say so.

What do you need for the review?

Access to the repository or a copy of the code, a staging or production link, and whoever knows how it is hosted. If the code is not in a repository, that is the first finding and we start by putting it in one.

What happens to my answers here?

They stay in your browser until you choose to send the result through the contact form. We do not store questionnaire answers otherwise.