Database-First Case Study:Tables Before One Screen

In this database-first case study, I designed the database before building a single screen — and 18 months later, at 1,000 tables and still under development, it has never needed a rebuild. Not once. This is the case study: what those unglamorous first weeks cost, and exactly what they bought.

The method itself — why your data must come before your screens — has its own post: database-first development. This one is the proof. A method is easy to nod along to and easy to abandon the moment you are impatient to see something on screen. So here is what actually happened when I bet an entire product on doing the boring part first: FIKR Space, now 11 integrated products and more than 3 million lines of code, all standing on a data foundation designed before any of it existed.

Database-first case study: two and a half weeks with nothing to show

Phase one — one week mapping domains. Before a single line of code, I listed every area the system would ever touch. More than 20 domains in total, falling into five groups:

• Core: organizations, users, teams, permissions
• Product: projects, tasks, objectives, sprints
• Money: cap tables, funding rounds, transactions, valuations
• Platform: accelerator programs, applications, cohorts, curriculum
• Support: comments, attachments, notifications, activity logs

Phase two — one week designing every table. Every table got the same backbone: which organization owns the record, who created it and when, who last changed it and when, and deletions that hide records instead of destroying them. On top of that backbone, each domain got its specific fields and its lists of statuses and types stored as editable data — never baked into code.

Phase three — three days mapping relationships. A full map of how everything connects: which records belong to which, which link many-to-many, which — like comments and attachments — can attach to anything.

Total: about two and a half weeks. The whole foundation, designed and connected — before one screen existed. To anyone watching, I had built nothing. People thought I was crazy: "Why not just start building and figure it out as you go?" Because I had no time to rebuild, no money to waste, and no margin for error. The database had to be right the first time.

The bookThe Solopreneur RevolutionLuis Gonçalves on building a solopreneur business with AI while employed.Get the book →

What the database-first foundation actually bought

Then the payoff started — and never stopped. Here is every major redesign FIKR Space went through, and what each one required from the database:

Five UI overhauls. Zero database changes. The screens are windows into the data — I could re-cut the windows endlessly because the walls never moved. That asymmetry is the entire case for database-first: you can completely redesign your UI; you cannot completely redesign your database.

The foundation bought two more things money cannot retrofit. First, a single source of truth: the dashboard and the task list can never disagree, because every screen asks the same tables the same questions. Second, customer isolation from day one: every record names the organization that owns it, so one customer's data cannot leak into another's account — and every feature I have added since inherited that protection automatically.

How could I possibly know I'd need 1,000 tables?

I didn't. I did not know every table in advance — some domains evolved, and fields were added along the way. But I knew the system: a multi-tenant platform for startups, investors, and accelerators, handling real money, needing complex permissions and audit trails, with multiple products sharing one foundation. Knowing the system tells you what kinds of tables must exist — entities, relationships, lookups, audit logs — even before you know every field. When new needs appeared, they fit the existing patterns instead of fighting them.

That is the architect's half of the job — the full role division is in you are the architect, AI is the builder. AI generated every migration exactly as I specified. It made zero architectural decisions. Pure execution. And it fought the discipline constantly: forgetting the organization tag, skipping indexes, proposing shortcuts — the warning signs are cataloged in 11 signs AI is confidently wrong.

The counterfactual: what skipping it costs

Here is what the UI-first version of this story looks like. Week one, you build a beautiful dashboard and create a table to feed it. Week two, you build a task list and create another table. Week three, the dashboard says 15 tasks and the task list shows 18 — because you now have two sources of truth, and nobody knows when they diverged or which one is right.

Now scale that up. Suppose I had skipped customer isolation and needed to add it later: every table changed, every query rewritten, every access rule created, all existing data migrated. Weeks of high-risk work touching everything at once — the kind of surgery that kills solo products. Because it was designed in from day one, there was never anything to retrofit.

And the money? The entire tool bill for building all of this was €3,250 — the breakdown is in the €3,250 stack. The expensive input was never cash. It was the discipline to spend two and a half weeks on foundations while there was nothing to demo. Hundreds of features later, every one of them fitting together, that remains the highest-return investment I have ever made in a product.

12 weeksYour corporate career was never the planApply to the Solopreneur Accelerator.Apply now →

Frequently asked questions

Why design the entire database before any UI?

Because the UI can change and the database cannot — at least not cheaply. Screens are windows into the data; redesign them as often as you like. But restructuring the data underneath a live product means touching every feature at once. Get the foundation right and everything built on it stays standing.

How long did designing the database take?

About two and a half weeks: one week mapping more than 20 domains, one week designing every table with a shared backbone, and three days mapping the relationships between them. That is the full price of the foundation — measured against 18 months of building with zero rebuilds.

Did the database ever need to be rebuilt?

No. Not once in 18 months. Fields were added and some domains evolved, but always inside the existing patterns. Five complete UI redesigns — dashboard, navigation, layout, styling, mobile — required zero database changes between them.

Do I need 1,000 tables for my product?

No. That number reflects 11 integrated products sharing one foundation. The principle scales down to any size: list every entity in your system, map how they relate, design all of it before building screens. The discipline is the same whether your product needs a dozen tables or hundreds.