JKODEZ_
// vibe-coded → production

Your AI-built app works. Will it survive real users?

The app was built with Lovable, Bolt, Cursor or ChatGPT, and it works in a demo. I turn it into an application you can safely hand to customers and employees, without throwing away what has been built.

+358 40 721 3761Stage by stage →
Contents01 Who this is for02 Typical problems03 What production-ready means04 Stage by stage05 Nothing built is thrown away06 Keep building with AI07 Tools and technologies08 FAQ
FOR BUSINESSES

A home-made tool that is already in use

Someone in the company built a tool with AI for quotes, bookings or reporting. It is in daily use and holds customer or employee data. Nobody knows how well it is protected.

FOR FOUNDERS

The MVP works, now real users are coming

Your vibe-coded MVP has convinced the first customers or investors. Next you need payments, growing user numbers and confidence that one fix will not break everything.

What is typically wrong with a vibe-coded app

These are not faults of the AI. A prototype is built to look like it works, not to last, and that is a perfectly sensible way to start. Before real users arrive, these are worth checking:

Secret keys in the browser
An API or payment service key sits in the app's code, where anyone can read it.
Database wide open
Access rules, such as Supabase RLS, are missing, and a logged-in user can see other users' data.
Login that only looks secure
Screens are hidden, but the backend answers anyone who knows how to ask.
No backups and no error tracking
When something breaks you hear it from a customer, and lost data cannot be recovered.
Every fix breaks something else
The AI fixes one thing and changes three others, because the code has no clear structure.
Only one environment
Changes go straight to production, where the real customers and real data are.

What production-ready means in practice

01

Security and access

Keys out of the browser, every user sees only their own data, and login actually protects.

02

Data and backups

Backups that have been test-restored, and a database structure that can handle growth.

03

Error tracking

Errors are visible to you before a customer calls.

04

Deployment and environments

Changes are tried in a separate environment before production, and you can roll back to the previous version.

05

Performance and costs

The app stays fast, and the cloud bill does not surprise you as users grow.

06

Personal data

GDPR basics: what data is collected, where it is and how it is deleted.

Stage by stage

STAGE 0
Initial conversation
YOUR PARTYou show the app and tell me who uses it and what worries you.
WHAT YOU GETAn assessment of whether to proceed, and a fixed price for the review.
PRICE
€0
about 1 h
STAGE 1
Review
YOUR PARTAccess to the code (for example GitHub), the database and the hosting environment.
WHAT YOU GETA short prioritised list: what is dangerous now, what is fine and what the fixes cost. No pile of reports.
PRICE
fixed
a few days
If the review turns up something urgent, such as a public key or an open database, I tell you straight away rather than at the end.
STAGE 2
Fixes in order of priority
YOUR PARTA decision on what gets fixed and in which order.
WHAT YOU GETThe most dangerous first. The app stays in use the whole time.
PRICE
per part
you can stop at any time
STAGE 3
What next
YOUR PARTA decision on how development continues.
WHAT YOU GETYou carry on with AI yourself, I continue development, or both. The source code is yours throughout.
PRICE
agreed separately

Nothing built is thrown away

Many developers look at a vibe-coded app and propose a rewrite. That is rarely the cheapest option. The app already has a user interface people know how to use, and features shaped by real needs. I fix the structure and the gaps around them and replace only the parts that will not hold.

I propose a rewrite only if it is the cheapest safe option, and then I say so in the review. The same principle guides legacy application modernisation: replace what is broken or limiting, and keep what works.

Keep building with AI

The goal is not to take the app away from you. After the fixes the app has a structure, a separate development environment and a way of deploying that let you keep vibe-coding more safely: changes made by AI do not go straight to production, and a bad change can be rolled back.

If you like, I review your changes before they are released. That way you get the speed of AI and the eyes of an experienced developer at the same time.

Apps built with which tools

AI TOOLS
LovableBoltv0ReplitCursorClaude CodeChatGPTGitHub CopilotWindsurf
TYPICAL TECHNOLOGIES
ReactNext.jsViteTypeScriptNode.jsPythonSupabaseFirebasePostgreSQLVercelNetlify.NET

If your app was built with something else, ask anyway. What matters is that the source code is available, for example on GitHub.

Frequently asked questions

THE APP OWNER ASKS

I am not a programmer. Can I even show you what I have?

Yes. Just show me the app and give me access to the service it was built with. I will work out the rest.

Does everything have to be rebuilt?

No. I fix what is dangerous or will not hold, and keep what works. I propose a rewrite only if it is the cheapest safe option.

What does this cost?

The initial conversation costs nothing. The review is fixed-price and the price is stated before you commit. Fixes are priced part by part based on the review.

Can I keep using Lovable or another tool?

Usually yes. We agree what you do in the tool and what is better done directly in the code, so that neither undoes the other's changes.

Is the app offline while it is being fixed?

No. Fixes are made in a separate environment and released once they have been confirmed to work.
THE FOUNDER ASKS

Will the app handle growth?

The review shows where the first bottlenecks are: database queries, server load or cloud costs. We fix first the ones you will hit first.

An investor wants a technical assessment. Can you help?

Yes. The review covers the same things an investor's technical assessor looks for, and the most serious ones can be fixed before the assessment.

Is our code processed in AI services?

I use AI to read and fix code with settings under which the material is not used to train models. Production data is not sent to the models. If the code must not go to outside services at all, we agree on that.

Do you offer ongoing maintenance?

Yes, under a separate agreement. Many want me to review changes before release and handle updates while they keep developing with AI themselves.

Next step

Show me the app, and already in the first conversation I can tell you what to check first and what the review costs.

+358 40 721 3761info@jkodez.com