What a prototype can demonstrate
An MVP built with Claude, Cursor, Lovable, v0, Codex or similar tools can help test a hypothesis and collect feedback. Validation still depends on the evidence gathered: an app that opens does not by itself prove market demand or production readiness.
- A prototype clarifies flows and hypotheses to test
- Real users, payments and data require additional checks
- An audit lists findings before the implementation is estimated
What the audit checks
There is no single defect shared by every generated project. We check authorisation, secrets, validation, error handling, data, backups and monitoring to establish which risks actually exist in that codebase.
- Authentication and role-based authorisation, including database policies
- Secrets and keys, to confirm they are not exposed in client code
- Server-side validation and handling of untrusted input
- Errors, loading states and behaviour when a service is unavailable
- Queries, indexes and data structure against expected volumes
- Backups, logs and monitoring included in the agreed scope
The audit: what we look at, in what order
Before proposing any work we read the code and use the application. The output is a document listing what we found, ordered by actual risk. It usually takes 2–5 working days.
| Area | What we check | Why it matters |
|---|
| Security | Authentication, per-role permissions, database policies, exposed secrets, input validation | Reduces the risk of unauthorised access or operations |
|---|
| Data | Table structure, relations, indexes, migrations, backups | Late data-model changes can affect migrations and existing features |
|---|
| Reliability | Error handling, loading states, edge cases, what happens when a call fails | Helps keep the flow understandable when something fails |
|---|
| Performance | Slow queries, bundle size, images, Core Web Vitals | Can affect user experience, infrastructure cost and technical SEO signals |
|---|
| Maintainability | Duplication, types, folder structure, abandoned dependencies | Influences the time and cost of future changes |
|---|
| Going live | Environments, variables, domain, monitoring, logs | Makes problems easier to detect and diagnose |
|---|
What we leave alone
An honest audit also says what to keep. Rewriting to personal taste burns budget and leaves the product where it was.
- If a library works and has no known holes, it stays, even where we would have picked another
- If the design holds up, we do not redo it just to sign it
- If a piece of code is ugly but isolated and stable, it is low priority: we flag it and move on
- If the MVP is already solid, we say so and you pay for the audit only
Indicative bands (2026)
Price depends on the findings, the scope and the product decisions still open. The audit separates contained fixes, structural work and any parts that may need rebuilding before the main budget is committed.
| Engagement | Indicative band | What it covers |
|---|
| Audit only | €800 – €1,500 | Full review and a document with priorities, risks and effort estimates. Deducted from the quote if you go ahead |
|---|
| To production, contained scope | €3,500 – €6,500 | Security and permissions fixed, error handling, correct deployment, basic monitoring |
|---|
| To production, broad scope | €6,500 – €12,000 | Wider refactoring, revised data model, performance, minimal documentation |
|---|
| Ongoing technical ownership | from €9,000 | We become the product's technical lead: evolution, maintenance and new features |
|---|
How it runs
No stage starts before you have seen and approved the previous one. The audit is also the point where you can stop: the document is yours and you can hand it to anyone.
- Read-only access to the repository and the live application, if there is one
- Audit in 2–5 working days, with a document and a walkthrough call
- Fixed quote on the work you choose, with dates
- Delivery in blocks to limit interruptions, where the intervention allows it
- Handover with access, essential documentation and a walkthrough
Frequently asked questions
Is AI-generated code throwaway?
That cannot be established without reading the project. Sometimes contained fixes are enough; in other cases changing the existing structure costs more than rebuilding part of it. The audit documents the reasons for that decision.
Why an audit before a quote?
Because without opening the code any number would be unreliable. Two MVPs that appear to do the same thing can require very different work. The audit defines the risks and makes the subsequent quote testable.
Which tools have you worked with?
We can audit projects started with Claude Code, Cursor, Lovable, v0, Bolt or Replit where the stack matches our experience, including Next.js, React, Supabase and Firebase. For other foundations we first confirm the technical scope.
Do you use AI to write code yourselves?
We use AI tools during development, but review their output and directly verify permissions, data models, security and application behaviour. The tool does not replace technical accountability for the result.
Do I keep the audit document?
Yes. It is yours and you can use it however you like, including to get competing quotes. If you go ahead with us, the audit cost is deducted from the quote for the work.
How long until it is live?
As an initial reference, after the audit a contained scope may take 2–4 weeks and a broad one 4–8. The final estimate depends on the findings, external dependencies and product decisions still open.