Software Engineering Blog | AI, Web & Mobile | Mobilions

Tag: app security

  • Lovable, Bolt, Cursor to Production: What Actually Needs Rebuilding

    Lovable, Bolt, Cursor to Production: What Actually Needs Rebuilding

    Moving a Lovable, Bolt, or Cursor app to production feels like you have to throw it out and start over. You do not. Taking an AI app to production means keeping the parts that already work and rebuilding a short, specific list of the parts that do not. This post is that list.

    The mistake most founders make is treating it as all or nothing. Either the AI build is “real” and they ship it as is, or it is “fake” and they scrap everything. The truth sits in the middle. A good chunk of what these tools generate is fine to keep. A small, predictable set of things has to be redone before real users and real data show up.

    Here is what to keep, what to rebuild, and how to tell the difference for your own app. Think of it as a field guide to taking an AI app to production.

    Key takeaways

    • Taking an AI app to production is a rebuild of specific parts, not a restart. Most of the app survives.
    • You almost always keep the interface, the core user flow, and the idea itself.
    • You almost always rebuild authentication, the data model and its security, secret handling, payments, and error handling.
    • The database and backend logic are the “it depends” pieces. Keep them if they are clean and correct, rebuild if they are tangled.
    • Do it in order: security first, then data, then performance, then structure. A full restart is rare and only makes sense when the core data model is wrong.

    Production ready is not demo ready

    A demo has to work once, for you, with clean input. Production has to work a thousand times, for strangers, with messy input, while protecting their data. Those are different jobs, and AI builders are built for the first one.

    That is not a knock on the tools. Lovable, Bolt, and Cursor are very good at turning an idea into something you can click in an hour. The gap shows up later, when the thing that demoed well meets a hundred real users. Knowing which parts close that gap is the whole game, and it is the real work of taking an AI app to production.

    What you almost always keep

    What to keep and what to rebuild when taking an AI-built app to production.

    Start with the good news, because it is most of the app.

    The interface. The screens, the layout, the components, the styling. AI tools are strong here, and there is rarely a reason to rebuild a frontend that already looks right and works. Keep it.

    The core user flow. The path a user takes through the app, the steps, the order of screens. If it makes sense and people can follow it, that design work is done. It carries straight into production.

    The idea and the validation. The most valuable thing the AI build gave you is proof that people want this. That does not get rebuilt. It is the reason to rebuild anything at all.

    Basic CRUD and content. Simple create, read, update, delete screens and the copy on them are usually fine. They just need the security layer underneath them fixed, which is a different job from rebuilding the screens.

    What you almost always rebuild

    This is the short list that turns an AI app to production into a safe one. It is short, but it is not optional.

    Authentication and access control. AI builders wire up a login that works, then leave the rules about who can see what wide open. This gets rebuilt properly, with real checks on every request, so one user cannot read another user’s data.

    The data model security. If you are on Supabase or Firebase, Row Level Security is usually off, which means your tables are readable by anyone. The schema is often fine. The rules protecting it are not. Those get rebuilt.

    Secret handling. API keys for Stripe, OpenAI, or your database tend to sit in the frontend where anyone can read them. Every one of those gets rotated and moved server side. This is not negotiable before launch.

    Payments and money paths. A demo checkout that works on a happy path is not a payment system. Real payments handle failures, refunds, retries, and edge cases. That logic gets built for real.

    Error handling. AI code assumes everything succeeds. Production code assumes things fail and handles it, so a user sees a clear message instead of a blank screen while their data quietly disappears. This gets added across the app.

    What depends on your build

    Two pieces sit in the middle, and the answer is “look before you decide.”

    The backend and business logic. If the AI wrote clean, separated logic, keep it. If it is one tangled block where every function knows about every other, it is cheaper to rebuild that layer than to keep patching it. Most AI builds land somewhere between, so you keep the sound parts and redo the messy ones.

    The database schema. Usually you keep it. The tables and relationships the AI designed are often reasonable. You rebuild the schema only when it is fundamentally wrong in a way that every feature depends on, which is the one case that can justify a bigger teardown.

    How to decide, piece by piece

    When you are not sure whether to keep or rebuild something, run it through three questions.

    Is it correct? Does it actually do the right thing for real inputs, not just the demo input?

    Is it secure? Can a user reach data or actions that are not theirs?

    Will it scale? Does it still work at a thousand rows and a thousand users, not just ten?

    If a piece is a yes on all three, keep it. If it fails any one, rebuild that piece. This keeps you from the two expensive mistakes: shipping something broken because it looked done, and rebuilding something that was already fine. That triage is the heart of any AI app to production plan.

    The order for taking an AI app to production

    The order to take an AI app to production: security, data, performance, structure.

    Sequence matters, because the risks are not equal. Do it in this order.

    Security first. Close the data access holes, rotate and move the keys, fix authentication. These are the things that get you breached, so they go first. Many of these are the same six places vibe-coded apps break, and the fixes carry straight over.

    Data second. Make sure the model is sound and the queries are safe. Performance third: add the indexes and fix the slow queries before growth, not after. Structure last: refactor the tangled parts once the app is safe and fast, so it can take new features without breaking.

    That order means the scary risks are gone early, and the slower cleanup happens on an app that is already safe to run.

    How much you rebuild, and how long it takes

    The rebuild list above is real work, but it is a slice of the app, not the whole thing. For a sound AI build with the usual issues, the security and data pass is often a few days. A fuller hardening, with payments and structure, runs one to three weeks. Add the fact that you are keeping the interface and the flow, and you are miles ahead of a from-scratch build.

    Compare that to the alternative. Scrapping a working app and rebuilding everything throws away the parts the AI got right, which is most of it. The point of moving an AI app to production is to spend your money only where it is needed.

    When to actually start over

    Sometimes a full restart is the honest answer. It is rare. It comes down to one thing: the data model.

    If the way the app stores and relates data is fundamentally wrong, and every screen and feature is built on top of that wrong model, patching it costs more than rebuilding. That is the case where you keep the interface and the idea, and rebuild the engine underneath. For everything short of that, a targeted rebuild beats a restart.

    What a real one looks like

    A founder came to us with a Cursor and Bolt build. A booking app, live, paying customers, growing. He assumed he needed a full rewrite before he could scale. He did not.

    We kept the entire frontend and the booking flow, which were good. We rebuilt authentication so users could only see their own bookings, turned on Row Level Security, moved the Stripe and database keys off the browser, and added real handling to the payment path. Then we added tests around booking and checkout. About two weeks. The app he already had went to production, minus the parts that would have leaked data or lost payments.

    That is the usual shape of an AI app to production. Keep most, rebuild the risky slice, ship.

    An honest caveat

    Not every AI build is worth taking forward. If you built it to test an idea and the idea did not land, do not spend a week hardening it. Throw it away and move on. That is what prototypes are for.

    The rebuild advice here is for the app that got real, that has users or is about to. When there is something real to protect, the keep-versus-rebuild split saves you both from shipping something unsafe and from paying for a rewrite you did not need.

    Where Mobilions fits

    We have shipped software since 2016: 250+ projects for 100+ clients across 20+ countries. A large and growing part of that work now is taking AI builds to production, the exact keep-versus-rebuild call this post is about.

    Our AI code cleanup service starts by drawing that line for your app: what stays, what gets rebuilt, and in what order. We close the security gaps first, then the data and payment paths, and add the testing that keeps it stable.

    If you would rather build the next version cleanly from the start, our approach to custom AI software development keeps the speed without the rebuild later.

    FAQ

    What does it mean to take an AI app to production?

    Taking an AI app to production means getting an app built with tools like Lovable, Bolt, or Cursor ready for real users and real data. It involves keeping the working parts and rebuilding security, payments, and error handling. A demo works once. Production works safely at scale.

    Do I have to rebuild my whole AI-built app for production?

    No. Most of the app usually survives, including the interface and the core user flow. You rebuild a specific list: authentication, data security, secret handling, payments, and error handling. A full rebuild is only needed when the core data model is wrong.

    What can I keep from a Lovable or Bolt build?

    You almost always keep the frontend, the screen layouts, the user flow, and the basic create and read screens. These are what AI tools do well. The idea and the validation carry over too. What needs work is the security and reliability layer underneath.

    What always needs rebuilding before production?

    Authentication and access control, the data model security (like Row Level Security), secret and API key handling, the payment path, and error handling. These are the parts AI builders skip to make the demo work, and they are the parts that leak data or lose money in production.

    Is a Cursor or Bolt app good enough for production?

    It is a strong first version, not a finished product. The generated app is fine to build on, but it needs a hardening pass before real users arrive. With that pass, a Cursor or Bolt app can absolutely run in production.

    How long does it take to move an AI app to production?

    For a sound build with the usual issues, the security and data pass is often a few days. A fuller pass with payments and structure runs one to three weeks. It is faster than a rewrite because you keep the interface and the flow.

    How much does it cost to make an AI app production ready?

    It depends on how deep the problems go, but it is far cheaper than a full rebuild because most of the app is kept. You pay to redo a specific slice, mainly security, payments, and error handling, not the whole application.

    Should I rebuild my AI app or start over?

    Rebuild the risky parts and keep the rest, which is the common case. Start over only when the core data model is fundamentally wrong and every feature depends on it. For everything else, a targeted rebuild is cheaper and faster than a restart.

    How do I know which parts to rebuild?

    Run each piece through three questions: is it correct, is it secure, and will it scale. If it passes all three, keep it. If it fails any one, rebuild that piece. This keeps you from shipping something broken or paying to redo something that was fine.

    Is AI-generated code safe for production?

    Not by default. Studies have found a large share of AI-generated code ships with security vulnerabilities. The code is a fine starting point, but it needs a security review and rebuild of the sensitive parts before it faces real users.

    Can I scale an app built with AI tools?

    Yes, once the performance and security parts are rebuilt. Missing indexes, exposed data, and no error handling all cap how far an AI build can grow. Fix those, and the app scales like any other well-built product.

    What is the difference between demo ready and production ready?

    Demo ready means it works once, for you, with clean input. Production ready means it works repeatedly, for strangers, with messy input, while protecting their data. AI tools deliver demo ready. The gap between the two is the rebuild list.

    Do I need a developer to take my AI app to production?

    For the security and payment parts, yes. Those are the pieces where a mistake leaks data or loses money, and they need someone who has done it before. The interface and flow you can often keep as is, which is what makes the job smaller than a rewrite.

    Will I lose my work if I rebuild parts of the app?

    No. A proper rebuild keeps the frontend, the flow, and the data you already have. Only the specific weak parts get replaced, and the app stays the app your users know. You are upgrading the engine, not buying a new car.

    Which AI coding tools need the most rebuilding for production?

    They are more similar than different. Lovable, Bolt, Cursor, and Replit all produce a working demo and leave the same gaps: open data access, exposed keys, thin payment logic, and no tests. The rebuild list is nearly the same regardless of which tool built the app.

    What should I do first when taking an AI app to production?

    Start with security. Check whether users can reach each other’s data, whether any secret keys are in the frontend, and whether login can be bypassed. Fix those before anything else, because they carry the most risk, then move to data, performance, and structure.

    The next step

    You do not need to rebuild your app. You need to know which five or six parts to rebuild, and to do them in the right order. Keep the interface and the flow that already work, redo the security and payment layer that does not, and ship.

    If you have an AI build with users on it, start by listing what is correct, secure, and ready to scale, and what is not. That list is your plan for taking your AI app to production.

    If you want a second set of eyes before you launch, tell us what you built and we will help you draw the keep-versus-rebuild line. It is the call we make every week.

  • The 6 Places Vibe-Coded Apps Break (and How to Fix Each)

    The 6 Places Vibe-Coded Apps Break (and How to Fix Each)

    Vibe coding gets you a working app in an afternoon. It rarely gets you an app that survives real users. The demo logs in, saves data, looks clean, and then the first hundred people show up and the cracks appear: leaked data, a login anyone can bypass, a screen that takes nine seconds to load.

    That gap is predictable. Vibe-coded apps tend to break in the same six places, every time, because the AI optimized for a demo that runs, not a product that holds. The good news is that each of those six failures has a known fix. This guide walks through all six, in the order they usually bite, with the exact thing to change.

    None of this means vibe coding is bad. It is a real shift, and it is here to stay. It just needs a second pass before you put real people and real data behind it.

    Key takeaways

    • Vibe coded apps almost always break in the same six areas: database access, exposed secrets, input validation, performance, missing tests and error handling, and architecture.
    • The root cause is not weak AI. These tools are built to produce a demo that works, so they skip the hardening that production needs.
    • Security is the one that hurts most. Veracode found that 45% of AI-generated code samples failed security tests, and cross-site scripting slipped through 86% of the time.
    • Most vibe-coded apps can be fixed in place. A full rebuild is only needed when the data model itself is wrong.
    • Before launch, check five things: row level security, secret keys, payments, a real login test, and one outside security review.

    What vibe coding actually is

    Andrej Karpathy coined the term in February 2025, describing a way of building where you describe what you want in plain English and let the model write the code, to the point where you can almost forget the code exists. Collins Dictionary liked the idea enough to name “vibe coding” its Word of the Year 2025.

    It is not a fringe habit either. In Y Combinator’s Winter 2025 batch, a quarter of the startups had codebases that were about 95% AI-generated, according to partner Jared Friedman. These are technical founders choosing speed. Tools like Lovable, Bolt, Cursor, Replit, and v0 turn a prompt into a running app in minutes.

    So the trend is real and the output is real. The problem starts when a prototype gets promoted to production without anyone hardening it first. Here is where that goes wrong.

    Six places vibe-coded apps break: data access, secrets, input validation, performance, tests, architecture.

    1. Your database is wide open

    This is the vibe coding failure we see most at Mobilions, and it is the one that leaks data.

    Tools that wire up Supabase or Firebase create the tables and get your app reading and writing fast. What they usually skip is Row Level Security, the rule layer that decides who can see which rows. With it off, every signed-in user can read every other user’s records, and often anyone with your public key can read the whole table from a browser.

    You can check this in about a minute. Open your Supabase project, go to the Authentication or Policies tab, and look at each table. No policies listed means the table is open.

    How to fix it. Turn Row Level Security on for every table that holds real data. Write a policy so a user can only touch their own rows, usually by matching the row’s user id to auth.uid(). Then test it as two different accounts and confirm neither can see the other’s data. This one change closes the most common vibe coding data leak.

    2. Your secret keys are sitting in the browser

    The second break is secrets baked into the frontend. To make the demo work end to end, AI tools often hardcode API keys for Stripe, OpenAI, your database, or a third-party service straight into the client code.

    Anything in the frontend is public. A curious user opens developer tools, reads the bundle, and there is your key. Bots scan public code for exposed keys around the clock, so this is not a maybe.

    How to fix it. Treat every key that shipped in the frontend as already leaked and rotate it. Move secret keys to the server side, into environment variables or a secrets manager, and call the paid service through your own backend endpoint. The browser should never see a secret key again. Publishable keys meant for the client are fine to leave, but know the difference before you ship.

    3. Nothing checks what users type

    Vibe-coded apps trust their inputs. The form works when you type a normal name, so it looks done. It is not.

    This is where the security numbers get loud. Veracode’s 2025 report tested more than 100 AI models across four languages and found 45% of the code samples failed security tests by introducing an OWASP Top 10 vulnerability. Cross-site scripting alone got through in 86% of the relevant cases. Newer, smarter models did not do any better on security.

    Cross-site scripting and SQL injection both come from the same habit: taking whatever a user submits and using it directly, in a page or a database query, without cleaning it first.

    How to fix it. Validate and sanitize every input on the server, not just in the browser. Use parameterized queries so user text can never run as a command. Escape anything you render back onto a page. The OWASP Top 10 is the checklist to run against here, and it is free.

    4. It works at ten rows and dies at ten thousand

    Performance is the quiet one. The app feels instant in the demo because the demo has twelve rows. Real usage brings ten thousand, and the same screen now crawls.

    Three patterns cause most of it. Missing database indexes, so every lookup scans the whole table. N+1 queries, where loading a list fires one more query per item instead of one query total. And selecting entire tables when the screen needs ten rows.

    How to fix it. Add indexes on the columns you filter and sort by. Replace N+1 loops with a single joined query or a batched load. Paginate long lists and select only the columns you use. None of this is exotic, and it usually turns a nine-second screen into a fast one without touching the design.

    5. There are no tests and no safety net

    Ask an AI agent to add a feature and it will happily rewrite code that already worked. Without tests, nobody notices until a user does. This is the complaint behind every “the agent broke my login” post.

    Two things are missing at once. Tests, so a change that breaks checkout gets caught before it ships. And error handling, so when something does fail, the user sees a clear message instead of a blank white screen while your app silently loses their data.

    How to fix it. Add tests around the flows that matter most first: signup, login, payment, anything that touches money or accounts. Wrap risky operations in real error handling with fallbacks and clear messages. Add basic logging so you find out about failures before your users email you.

    A little test coverage on the critical paths is what turns a scary codebase into one you can change with confidence. This is the core of proper software testing, and it is worth doing early.

    6. The code cannot grow

    The last break shows up later, when you try to add the third or fourth big feature and everything slows to a crawl. The app was generated as one tangled piece, so every change risks breaking two things you did not touch.

    Vibe coding is great at a first version and weak at structure. There is no clear separation between the screens, the business logic, and the data. Feature five takes a week because the AI has to reason about the whole app at once, and so do you.

    How to fix it. Refactor into clear layers as soon as the app is worth keeping: a data layer, a logic layer, and the interface. Pull shared logic out of the screens. You do not need a rewrite for this. You need someone to draw the boundaries the AI never did, so the next ten features do not each cost a week.

    Why this keeps happening

    It is tempting to blame the tools, but that misses the point. Lovable, Bolt, Cursor, and the rest are doing exactly what they promise: turn an idea into a running app fast. Hardening is a different job, and they were never asked to do it.

    The mistake is human. A prototype gets users, the users make it feel real, and nobody stops to ask whether the thing was ever built to carry real data. Speed to a demo and readiness for production are two separate milestones. Vibe coding nails the first and skips the second, and the skip is invisible until it is not.

    Treated as a prototyping method, vibe coding is one of the better things to happen to software in years. Treated as a finished product, it is a data breach with a nice landing page.

    What a cleanup actually looks like

    A founder came to us with a Bolt-built scheduling app. Real customers, real bookings, growing fast. Then two users reported seeing each other’s client lists.

    It was Row Level Security, off on every table. Anyone logged in could read every booking in the system. We turned on policies, rotated the Stripe and database keys that were sitting in the frontend, added indexes to the two tables that were timing out, and wrote tests around booking and payment.

    Four days of work. No rebuild, because the data model was sound. The app the founder already had was fine. It just needed the second pass that vibe coding does not include.

    That is the usual shape with vibe coding. Most vibe-coded apps do not need to be thrown away. They need someone to walk the same six places and close each one.

    Five checks before you launch a vibe-coded app

    Five checks before launching a vibe-coded app.

    If you are about to put a vibe-coded app in front of real users, run these first:

    1. Is Row Level Security on for every table with real data, tested as two different users?
    2. Are all secret keys on the server, with anything that shipped in the frontend rotated?
    3. Do payments handle failures and refunds, not just the happy path?
    4. Would a test catch a broken login or checkout before your users do?
    5. Has anyone outside the build looked at it for security?

    Any “no” on that list is a reason to pause. These five catch the worst of the vibe coding failures, and the first four you can often handle yourself. The fifth is where an outside set of eyes pays for itself.

    Where Mobilions fits

    We have been building and fixing software since 2016: 250+ projects for 100+ clients across 20+ countries. A growing share of that work now is exactly this, taking an app that started with vibe coding and getting it ready for real users.

    Our AI code cleanup service walks all six of the places above, closes the security holes first, then the performance and structure problems, and leaves you with the app you thought you had.

    If you are not sure whether yours needs a light pass or a deeper rebuild, that is the kind of call a fractional CTO makes well, and it is usually cheaper to ask early than to find out from a user.

    If you would rather build the next version properly from the start, our approach to custom AI software development keeps the speed of AI without the six breaks.

    FAQ

    What is vibe coding?

    Vibe coding means building software by describing what you want in plain language and letting an AI model write the code, often without reviewing it line by line. Andrej Karpathy coined the term in early 2025, and Collins Dictionary named it Word of the Year 2025.

    Is vibe coding good or bad?

    It is genuinely good for prototypes, internal tools, and testing an idea fast. It becomes risky when a prototype ships to real users with real data, because the AI skips the security and structure that production needs. The method is fine. Shipping it unchecked is the problem.

    Can vibe coding build a real production app?

    Yes, but not on its own. A vibe-coded app can become production ready after a hardening pass that adds database security, moves secret keys to the server, validates inputs, fixes performance, and adds tests. The build is a strong first draft, not the finished product.

    Why do vibe-coded apps break in production?

    They break because the tools optimize for a working demo, not a hardened product. The common failures are open database access, exposed API keys, no input validation, missing indexes, no tests, and tangled structure. Each is predictable and fixable.

    Is AI-generated code secure?

    Often not by default. Veracode’s 2025 study found 45% of AI-generated code samples introduced an OWASP Top 10 vulnerability, with cross-site scripting slipping through 86% of the time. AI code needs a security review before it goes live, the same as any code.

    How do I know if my vibe-coded app is safe to launch?

    Check five things: row level security on every table, secret keys kept server side, payments that handle failures and refunds, tests around login and checkout, and one outside security review. If any answer is no, pause and fix it first.

    How much does it cost to fix a vibe-coded app?

    It depends on how deep the problems go, but most cleanups are far cheaper than a rebuild. A typical security and performance pass on a sound app runs a few days of work. A rebuild is only needed when the data model itself is wrong.

    Should I rebuild or fix my vibe-coded app?

    Fix it if the data model is sound and the problems are security, performance, and structure, which is the common case. Rebuild only when the core data design is wrong in a way that every feature depends on. Most vibe-coded apps do not need a rebuild.

    What are the most common vibe coding mistakes?

    Leaving Row Level Security off, hardcoding API keys in the frontend, trusting user input without validation, skipping database indexes, and shipping with no tests. All five are common, and all five are quick to fix once you know to look.

    Is vibe coding good for MVPs?

    It is one of the fastest ways to build an MVP and validate an idea. Just treat the result as a prototype. Before you take payments or store personal data, run the six-point hardening pass so the MVP does not become a liability.

    Can vibe coders build complex applications?

    Vibe coding handles a first version of most apps well. Complexity is where it strains, because the generated code lacks the structure needed to add features safely. Complex apps usually need an engineer to set the architecture the AI never did.

    Vibe coding vs traditional coding, which is better?

    They are better at different jobs. Vibe coding wins on speed to a first version. Traditional engineering wins on security, scale, and long-term maintenance. The strongest teams use vibe coding to move fast, then apply real engineering before real users arrive.

    What tools are used for vibe coding?

    The common ones are Lovable, Bolt, Cursor, Replit, and v0, plus general assistants like ChatGPT and Claude. They differ in polish, but they share the same blind spot: they produce a working demo and leave production hardening to you.

    Do real companies actually use vibe coding?

    Yes. A quarter of Y Combinator’s Winter 2025 startups had codebases that were about 95% AI-generated. The difference between the ones that scale and the ones that stall is whether they hardened the code before growth, not whether they used AI to write it.

    How do I make my vibe-coded app secure?

    Start with the highest-impact fixes: turn on Row Level Security, move secret keys off the frontend and rotate the exposed ones, validate every input on the server, and run your code against the OWASP Top 10. Then add tests around login and payment.

    How long does it take to make a vibe-coded app production ready?

    For a sound app with the usual issues, a focused hardening pass is often a few days to two weeks. Apps with deeper data-model problems take longer. The security fixes come first because they carry the most risk.

    Can I scale a vibe-coded app?

    Not until the performance and structure breaks are fixed. Missing indexes, N+1 queries, and tangled code all cap how far an app can grow. Once those are addressed, a vibe-coded app can scale like any other well-built product.

    The next step

    Vibe coding is not going anywhere, and it should not. It is the fastest way to turn an idea into something you can click. Just remember that a running demo and a launch-ready product are two different things, separated by the six places above.

    If you already have a vibe-coded app with users on it, start with the five-point launch check today. Fix what you can, and get an outside review on the rest before the numbers grow.

    If you want that review from a team that does it most weeks, tell us what you built and we will point you at the shortest fix. Finding a leak yourself is a Tuesday. Finding out from a customer is a very different day.