Your app was fast with five users. Now it's struggling with fifty.
You built your application with Lovable, Bolt, Replit, or another AI coding tool. During development, pages loaded quickly and everything felt responsive. Then real customers arrived. Dashboards started taking several seconds to open, searches became sluggish, and occasionally the app stopped responding altogether.
Imagine a hypothetical booking platform that displays appointments and customer histories. It works well with a handful of bookings, but after several months of activity, opening the dashboard becomes painfully slow. The founder assumes the hosting plan is too small and considers upgrading it. That might help, but the actual bottleneck could be an inefficient database query, too many requests from the browser, or the application repeatedly loading information it doesn't need.
Measure the delay before deciding what to change
An experienced developer starts by establishing where time is being spent. The browser waterfall shows which files and network requests take longest. Backend logs help identify slow server operations.
Database measurements reveal expensive queries, excessive connections, or repeated requests. A common issue is the N+1 query problem, where the application makes one database request to obtain a list and then another request for every item. Pagination and smaller payloads can also make a substantial difference when the app tries to load thousands of records at once.
For databases such as PostgreSQL, an EXPLAIN query plan helps identify inefficient data access; indexes can improve some queries, but adding them blindly creates maintenance and write overhead. Supabase's query optimization documentation covers these tradeoffs. Performance should be measured with representative data volumes and realistic concurrency. Track typical response times and p95 latency, the time within which 95% of measured requests complete, so slower users are not hidden by averages. Never run aggressive load tests or potentially modifying EXPLAIN ANALYZE statements against a live production database.
When should you bring in an engineer?
If customers are abandoning tasks because your app is slow, buying a bigger server without locating the bottleneck may simply increase your expenses. A proper performance review identifies what is slowing down and which improvements are worth making.
DitchNow, based in Haarlem, Netherlands, helps founders diagnose and improve the performance of AI-built applications as they grow beyond the prototype stage.
Discuss your app's performance with DitchNow.
Five prompts to investigate performance
Before you begin: Use these prompts one at a time in the same project conversation. Give the assistant access only to approved project materials, use synthetic test data, and review its findings before approving changes.
1. Map
Act as a senior performance engineer. Inspect my application and map the flow for [DESCRIBE SLOW FEATURE], including browser requests, backend services, database queries, and external APIs. Identify where loading, processing, and database connections occur. Produce an architecture map with relevant file references, available performance measurements, and explicit unknowns. Do not modify code or run load tests.
2. Audit
Perform a read-only performance audit using approved, sanitized browser waterfall traces, server logs, query statistics, and existing measurements. Look for slow queries, N+1 queries, excessive payload sizes, missing pagination, connection-pool pressure, and unnecessary repeated requests. Where available, inspect safe query plans using EXPLAIN. Report baseline timings, p95 latency where measurable, evidence-backed bottlenecks, and issues requiring further investigation. Do not modify production data.
3. Plan
Propose a prioritized optimization plan for the confirmed bottlenecks. Evaluate query restructuring, database indexes, pagination, reducing payload size, caching, and connection-pool configuration where relevant. For each proposed improvement, explain the expected benefit, possible tradeoffs, affected files, acceptance criteria, and how performance will be measured before and after. Do not assume that upgrading hosting is the correct first step.
4. Challenge
Perform a second-pass self-review of your own plan, challenging assumptions and overlooked bottlenecks. Design safe benchmark scenarios using representative synthetic datasets and controlled concurrency in a test environment. Consider whether the improvements create new database load, stale data, or unexpected behavior. Identify what cannot be verified without additional measurements. Do not run destructive or production load tests.
5. Implement
I approve these changes: [APPROVED SCOPE]. Implement them only in an isolated development or staging environment. Use authorized synthetic test data, run controlled benchmarks, and compare baseline versus updated response times, p95 latency, and database behavior. Report modified files, measured improvements, regressions, and outstanding risks. Do not deploy automatically or run load tests against production.