The database decision that saves you later.

Strategy · 5 min read

Nobody gets excited about database structure. There are no screenshots to show. No animations to demo. It's invisible work that sits underneath everything your app does. But getting it wrong is one of the most expensive mistakes you can make, because fixing a database after development has started means rebuilding from the foundations up.

I learned this the hard way working on an education app. The content needed structure: questions, topics, modules, difficulty levels, progress tracking. How those categories related to each other, how they nested, how they filtered. All of that had to be mapped out before a single line of code was written.

Why content structure comes before code

Think of your database like the filing system in a warehouse. If you set up the shelves wrong at the start, every item you add goes in the wrong place. And when someone needs to find something, they're pulling open every drawer looking for it. That's what a bad database structure does to your app. It makes everything slower, harder to search, and more expensive to maintain.

With the education app, the questions didn't just need to be stored. They needed to be tagged by topic, difficulty, module, and certification pathway. A single question might belong to multiple modules. A topic might span multiple difficulty levels. And the user's progress needed to track which questions they'd answered, which they got right, and which they should see again. Those relationships had to be designed before development, not discovered during it.

I spend time during the design phase mapping this out with the client in spreadsheets. Rows of content. Columns of attributes. Relationships drawn out on a whiteboard. It's not glamorous work. But it's the cheapest point in the project to make changes. Rethinking a spreadsheet costs nothing. Restructuring a database after it's been built and populated with live data costs thousands.

Technical debt starts here

Research from Qiu, Li and Leung found that database design shortcuts become compounding technical debt. That means the cost of fixing them doesn't stay the same over time. It grows. A shortcut you take in month one becomes a constraint in month six that costs three times as much to fix because everything else has been built on top of it.

I've seen this happen. A client wants to add a new category to their app six months after launch. Should be simple, right? But the original database wasn't designed to handle dynamic categories. It was hardcoded for the five categories they started with. Adding a sixth means changing the database schema, updating the API, modifying the interface, and testing everything again. A job that should have taken a day takes two weeks because of a decision made before development started.

The fix is to think about flexibility upfront. Not every possible feature. Just the obvious growth paths. If your app has categories now, it will probably need more categories later. Build the structure to support that. If your content has difficulty levels, make those levels configurable rather than fixed. Small decisions early prevent big headaches later.

What this means for you

If your app has content, and most apps do, you need to think about how that content is organised before your developer starts building. What are the categories? How do they relate to each other? Can an item belong to more than one category? How will users search, filter, and browse? Those aren't technical questions. They're product questions. And you're the best person to answer them because you know your domain.

When I walk a client through this process, I ask them to describe how their users would look for information. Not how the app should work technically, but how a real person would think about finding what they need. That conversation reveals the structure. The database just formalises it.

It's the least visible part of the entire project. But it's the part that determines whether your app scales gracefully or collapses under its own weight.

Sources
Database Design and Technical Debt (Qiu, Li & Leung, 2016, IEEE) - Database design shortcuts become compounding technical debt, with restructuring costs growing significantly over time.

Related blog posts:

The content bottleneck nobody plans for →

Scope creep starts with "while we're at it" →

Your timeline is wrong →