We Fixed an AI-Built App: What We Found

The application fetched records by their database ID without checking whether the logged-in user was allowed to see that record. Any authenticated user who knew or guessed the numeric ID of a record belonging to another company could retrieve it directly via the API. The IDs were sequential integers starting at one, so there was nothing to guess. You could enumerate them trivially.

This was not a subtle edge case. It was the fundamental access control check, missing from every data retrieval endpoint in the application. The AI tool had written the code to fetch data. It had not written the code to confirm you were allowed to see that data before fetching it.

The database had eleven tables. None of them had indexes on any column except the primary key. Foreign key relationships existed in the application code but not in the database schema itself, meaning the database could not enforce them and they were routinely violated. One table that stored line items for invoices had no relationship to the invoice it belonged to that the database knew about; the link was a column called invoice_id that was never indexed and could contain anything.

A query that listed all invoices for a client, with their line items, their payment status, and the associated client details, took twenty-three seconds on forty accounts. On four hundred accounts it would have been unusable.

Several operations in the application were not atomic. Specifically, generating and assigning invoice numbers used a two-step process: read the highest existing number, add one, write the new invoice with that number. With a single user this works. With two users doing it simultaneously there is a race condition that produces duplicate invoice numbers. The founder had three clients who used the tool regularly and had already noticed occasional duplicate numbers, which they had assumed was a bug they had not yet reported.

It was not a bug in the traditional sense. It was a fundamental failure to understand that databases need transactions when multiple users might modify shared state concurrently.

The application had grown through iteration. The founder had used the AI tool to add features over eight months by describing what they needed and accepting what the tool produced. The result was a codebase that had no consistent structure, no separation of concerns, and no documentation. Business logic was scattered across controllers, middleware, and database queries with no discernible pattern.

We asked the founder to walk us through what a specific calculation did. They could not. They had never written the code that did it; they had accepted the output the tool produced. The calculation was correct for the cases they had tested but broke for edge cases they had not considered, which the tool had no way of anticipating because it did not know the edge cases existed.