How to Make Your AI-Built App 10x Faster Without a Rewrite

How to Make Your AI-Built App 10x Faster Without a Rewrite

Your vibe-coded app is slow. You are not sure which part is slow, how slow it actually is, or what to fix first. The conventional answer — "profile it and fix the bottleneck" — is correct but useless without knowing what the common bottlenecks look like in AI-generated code specifically.

At Mendly Labs, we have cleaned up Cursor, v0, Lovable, Bolt and Replit apps every week for over a year. The same six performance killers appear in almost every codebase, in roughly the same order of impact. Fix these six things and you will not need a rewrite — you will need a Weekend Cleanup sprint.

Why AI-generated code is almost always slow at production scale

AI coding tools generate code that solves the immediate problem correctly. They do not optimise for performance unless you explicitly ask — and even then, they optimise locally, not globally. They do not see that the dashboard page makes 47 database calls. They do not notice that the component re-renders 12 times on every keystroke. They do not know that your images are 4MB PNGs being served uncompressed.

These are not bugs. They are the natural output of a tool designed for correctness at small scale. The gap between "correct at small scale" and "fast at production scale" is where vibe-coded apps break, and it is entirely fixable without throwing away the product.

Before you touch a single line of code, check your current state: paste your worst component into our free code health scanner and get a Spaghetti Score that surfaces the structural issues. It costs nothing and takes thirty seconds.

Fix 1: N+1 database queries (highest impact, most common)

This is the performance killer that shows up in 90% of Lovable and Supabase-backed apps. It's also failure pattern #3 in why Lovable apps break in production — the two problems are usually the same bug wearing different hats.

An N+1 query looks like this: your page loads a list of N items, and then for each item, makes one more database call to fetch related data. For a page with 50 items, that is 51 database calls. For a page with 200 items, that is 201 calls — each of which adds latency, and all of which hit your Supabase connection pool simultaneously.

How to find it: look for useEffect or .then() chains inside loops, or forEach / .map() blocks that contain await supabase.from() calls.

The fix: replace the loop with a single query that uses a JOIN or a select('*, relatedTable(*)') pattern:

// The N+1 pattern (slow)
const projects = await supabase.from('projects').select('*');
for (const project of projects.data) {
  const members = await supabase
    .from('members')
    .select('*')
    .eq('project_id', project.id); // One query per project
}

// The fixed pattern (fast)
const projects = await supabase
  .from('projects')
  .select('*, members(*)'); // One query, all data

This single change has cut dashboard load times from 8 seconds to under 800ms in Lovable apps we have worked on.

Fix 2: Missing database indexes

Your queries are correct. They are just scanning the entire table every time.

When you query WHERE user_id = 'abc123', Supabase needs to find all rows where user_id matches. Without an index on user_id, it reads every row in the table — 10 rows is fine, 100,000 rows takes several seconds.

AI tools create tables and columns. They almost never create indexes.

How to find missing indexes: in Supabase, go to Database → Query Performance. Any query with "Seq Scan" (sequential scan) on a large table is a missing index.

The fix: add indexes on every column you filter, sort or join on:

-- Add these in Supabase SQL Editor
CREATE INDEX IF NOT EXISTS idx_projects_user_id ON projects(user_id);
CREATE INDEX IF NOT EXISTS idx_messages_thread_id ON messages(thread_id);
CREATE INDEX IF NOT EXISTS idx_orders_created_at ON orders(created_at DESC);

Adding indexes takes seconds in Supabase and has zero downtime. It is one of the highest-leverage changes you can make to a slow app.

Fix 3: Uncontrolled React re-renders

Your frontend is re-rendering on every keystroke, every scroll event, every state update — including state updates that are completely unrelated to what is on screen.

AI-generated React components frequently:

• Put everything in one giant component so any state change re-renders everything
• Use object literals or array literals directly in props (style={{ color: 'red' }} creates a new object on every render)
• Miss useMemo or useCallback on expensive calculations
• Fetch data inside components that re-render frequently

How to find it: install the React DevTools browser extension and turn on "Highlight updates when components render." Click around your app and watch everything that flashes. Anything that flashes on an action unrelated to it is an unnecessary re-render.

The fix — four targeted changes:

1. Move state as close as possible to where it is used (state lifting anti-pattern)
2. Replace const options = { key: 'value' } in render with const options = useMemo(() => ({ key: 'value' }), [])
3. Wrap event handler functions in useCallback
4. Split the giant component into smaller ones so only the part that needs to update does

This is covered in detail as part of our Refactor Sprint at ₹14,999, where we split god-components as a first step.

Fix 4: Unoptimised images

This one is embarrassingly common in vibe-coded apps and has a disproportionately large impact on page load time.

AI tools reference images without concern for file size, format, or loading strategy. In practice this means: 3MB PNG files being downloaded on mobile, images that are 2000×2000 pixels being displayed at 200×200, and images loading all at once even those below the fold that the user may never scroll to.

Google's Core Web Vitals — which are a confirmed ranking factor — are heavily affected by image performance. A slow LCP (Largest Contentful Paint) almost always traces back to a single large unoptimised image.

The complete fix:

• Convert all images to WebP or AVIF — typically 60–80% smaller than PNG or JPEG at equivalent quality
• Use next/image (Next.js) or equivalent — it handles format conversion, lazy loading, and responsive sizing automatically
• Set explicit width and height on every image — prevents layout shift (CLS), another Core Web Vitals score
• Add loading="lazy" on any image not visible above the fold

For apps hosted on Vercel, next/image does all of this automatically. If you are not using it, you are leaving significant performance on the table.

Fix 5: No caching layer for repeated data

Your app is fetching the same data on every page load, every component mount, every route change. Data that does not change frequently — user profile, app configuration, dropdown options, pricing tiers — is being re-fetched from the database on every request.

The fix depends on what type of data it is:

• Static data (pricing, config, public content): use Next.js static generation or revalidate — fetch once at build time or cache with a TTL
• User-specific data that changes occasionally (profile, settings): use react-query or SWR — these cache the response client-side and only re-fetch when stale or invalidated
• Frequently changing data (live feed, notifications): fetch fresh, but debounce the requests so you are not hammering the database

Adding react-query to an existing app takes less than a day and typically reduces database load by 40–70% for most user flows.

Fix 6: Render-blocking JavaScript and fonts

Your page is white for two seconds before anything appears. This is almost always render-blocking JavaScript — scripts that must finish loading before the browser can paint anything on screen.

AI-generated apps often:

• Import large libraries at the top level when only a small part is needed
• Load third-party scripts (analytics, intercom, chat widgets) synchronously in <head>
• Use Google Fonts via the standard <link> embed, which blocks rendering until the font loads

The fix:

• Use dynamic imports for large components not needed on initial load: const HeavyChart = dynamic(() => import('./HeavyChart'), { ssr: false })
• Move third-party scripts to load with strategy="lazyOnload" (Next.js Script component) or add async / defer attributes
• Self-host fonts or use font-display: swap to prevent font-loading from blocking render
• Audit your bundle size with next build --debug or the Webpack Bundle Analyzer — find imports that are unexpectedly large

How to measure your current performance

Before fixing anything, get a baseline:

1. Google PageSpeed Insights (pagespeed.web.dev) — paste your URL and get your Core Web Vitals score on mobile. Below 50 is critical. Above 90 is good.
2. Chrome DevTools → Network tab — sort requests by size. Any file over 500KB is suspicious. Any response time over 500ms on a simple data query is an N+1 or missing index.
3. Supabase Dashboard → Query Performance — shows your slowest queries by total time. These are your database bottlenecks.
4. Our free code health scanner — paste a component and get a Spaghetti Score that surfaces structural problems including deep nesting and missing error handling.

The order in which to fix things

Based on what we see in Mendly engagements, fix in this order:

1. N+1 queries — biggest impact, fast to fix
2. Missing indexes — five minutes of SQL, massive gains
3. Unoptimised images — use next/image, done
4. Render-blocking scripts — move to async or lazyOnload
5. Re-renders — profile first, fix the worst offenders
6. Caching — add react-query or SWR to high-frequency data paths

If all six problems are present — and they usually are — the combination of fixes typically moves a PageSpeed mobile score from 20–40 to 80–90+ and cuts database latency by half or more.

When to get help

If you have been staring at slow performance for more than a few days without a clear picture of what to fix, the fastest path is a professional audit.

Mendly's Weekend Cleanup sprint at ₹4,999 specifically targets the performance layer: N+1 queries, missing indexes, image optimisation, and the top re-render offenders — delivered in 48 hours with a Loom walkthrough of every change. The Refactor Sprint at ₹14,999 goes deeper: full code restructure, database hardening, auth hygiene, and a 14-day bug warranty.

Every engagement starts with a free 48-hour audit — no GitHub access needed, no commitment required. Send us a Loom or a repo link and we will tell you exactly where the performance ceiling is and what it will cost to raise it. Not sure if a cleanup sprint covers it, or if your app needs something more structural? Our refactor vs. rewrite framework walks through exactly how to decide.

For the security and data compliance side — which almost always surfaces alongside performance issues — run our free exposed secret scan and DPDP compliance check before or alongside the performance work.

The complete MVP-to-production guide covers performance as part of the broader hardening picture if you want to tackle everything systematically.

Frequently asked questions

How much faster will my app actually get? It depends on how many of the six problems are present, but the combination of fixes typically moves a PageSpeed mobile score from 20–40 into the 80–90+ range and cuts database latency by half or more. N+1 queries and missing indexes alone usually account for most of the gain.

Do I need to fix all six problems, or just the biggest one? Fix in the order listed above — N+1 queries and missing indexes first, since they take the least time and produce the largest improvement. Re-renders and caching matter, but they are worth tackling once the database-level issues are resolved.

Is a slow app also a security risk? Often, yes. The same missing RLS policies and exposed keys that create security gaps frequently sit right next to the N+1 queries causing the slowness — they come from the same "speed over structure" defaults. Why Lovable apps break in production covers the security side in detail.

Keep the vibe. Fix the code. Get your free performance audit →