Why Your AI-Built App Gets Slow With Real Users

The demo was instant. Three months later, with a few hundred customers and a few thousand records, the dashboard takes eight seconds and users are complaining. Nothing was changed, so what happened?

The data grew. Code generated by AI tools is written to work, and with ten test rows almost anything works. The problems only appear when the same code meets real volumes. This post covers the six usual causes, how to tell which one you have, and how to fix them. It is part of the guide to making an AI-built prototype ready for real users.

How do you find what is slow?

Measure before changing anything. Open the slow page with the browser’s developer tools on the Network tab and reload. You are looking for three things: requests that take longer than a second, responses that are very large, and dozens of requests where a few would do.

Then look at the database. In Supabase, run the slow query with explain analyze in the SQL editor; its documentation suggests looking for sequential scans and high cost numbers, and offers an index advisor that recommends indexes for a given query (Supabase).

The six usual causes

1. Loading the whole table and filtering in the browser

The page asks for every order, then filters, sorts and counts them in JavaScript. With 50 orders, fine; with 50,000, the browser downloads megabytes to show a list of 20. The fix is to ask the database for exactly what the page shows: the filter, the sort and the limit go into the query, and totals come from a count or a small summary query.

2. Missing indexes

A query that filters by user_id, status or created_at without an index reads the whole table every time. Supabase’s guidance is to index the columns used in filters and joins (Supabase). This is often the single biggest win, and one line of SQL per index.

3. Slow row-level security policies

Security policies run on every row a query touches. Written the obvious way, they can be the slowest part of the query. Supabase’s own tests show large gains from three changes: indexing the columns a policy uses (over 100 times faster on large tables), wrapping auth.uid() in a select (179 ms down to 9 ms) and adding the same filter to the query itself (171 ms down to 9 ms) (Supabase). If you haven’t set up policies yet, start with Supabase RLS for AI-built apps.

4. One request per item

A list of 30 projects where each card fetches its owner, its tasks and its comments separately makes 90 requests to show one page. The fix is to fetch related data in one query (Supabase supports selecting related tables in the same request) or to load the details only when a card is opened.

5. No pagination

Lists that load “everything” get slower every day. Worse, APIs cap how many rows one request returns, so a list can silently stop showing new records once it passes the cap. Page through results with a limit and an offset or a cursor, and show the total separately.

6. The hosting plan

Free plans are built for trying things, not for customers. Supabase’s free plan, for example, includes a 500 MB database and pauses projects after a week of inactivity (Supabase); the first visitor after a pause waits for it to wake up. Before launch, move to a paid plan and check where your database and hosting run: a server on another continent from your users adds delay to every request.

Which fix comes first?

Start with the page users complain about, then measure its slowest request. In most AI-built apps the order is the same: indexes first (minutes to add, often the biggest gain), then the queries that load too much, then pagination, then the number of requests per page. Fix one, measure again, and stop when the page is fast enough. Rewriting the app for speed is rarely needed.

Speed problems and security problems often share a cause: the browser doing work the server should do. When you fix one, check the other; secret keys in your frontend covers the security side.