Why your database design decides your AI velocity.

01

The pattern.

It goes the same way almost every time. The first feature is astonishing — a working surface in an afternoon, data persisting, everyone pleased. The second feature takes three days. The third turns into a migration, a backfill and an argument.

Nothing has gone wrong with the tooling. What happened is that the schema was generated to satisfy the first screen, and screens are a poor description of a business.

02

Why models get schemas wrong.

A model optimises for the request in front of it. Asked to build a booking form, it will produce a table that stores a booking form very well: flat, denormalised where convenient, with the fields the form happens to show.

It has no access to the things that actually determine the shape — that bookings will later need to belong to an organisation, that prices change over time and history must be preserved, that a cancellation is not a deletion. Those facts live in your head or in a conversation nobody transcribed.

This is not a limitation that better prompting fixes. It is missing information, and the fastest way to supply it is to make the decisions yourself first.

03

Decisions to make by hand.

A short list, settled before volume coding starts, prevents most of the expensive rework. None of it takes long — an hour with a whiteboard usually covers it.

• Identity: what the keys are, and whether identifiers are ever exposed publicly
• Tenancy: whether rows belong to a user, an organisation, or both, and how that is enforced
• Time: what needs history, what needs an audit trail, and what can be overwritten
• Deletion: what is genuinely removable and what must only ever be marked inactive
• Money: currency, precision, and whether a stored price is a snapshot or a reference
• Fixed sets: which enumerations will grow and therefore belong in a table, not in code

04

Treat migrations as a first-class surface.

The point of getting the shape roughly right is not to avoid changing it — you will change it. The point is that changes stay routine.

That means migrations are reviewed like application code, run the same way in every environment, reversible where the operation allows, and safe to apply while the service is running. A schema you are frightened to alter will slow every subsequent feature, no matter how quickly the code around it can be generated.

05

How we sequence it.

On our own engagements, structure comes before volume: architecture, content model and data shape are agreed and written down before the accelerated build begins. It is deliberately the least impressive phase of the project and the one that decides how the rest goes.

After that the tooling can run hard, because the expensive decisions are already made and a reviewer has something concrete to check the output against.