I’ve been noticing something lately.

A lot of people are building things: apps, automations, AI tools. And honestly, they look great at the beginning.

Everything works.
The demo runs smoothly.
The interface is clean.

But… very few people actually think about the data behind it.

And you don’t feel it straight away.

Only later.

When things start to grow.

The layer no one really talks about

When we build something, we usually focus on what we see:

• the interface
• the features
• the logic
• the AI

But underneath all of that, there’s something quieter.

The way the data is structured.

And that’s what ends up defining if your system feels simple… or messy.

If it scales… or starts breaking.

If it’s clear… or confusing.

Why do people skip it

Most of the time, it’s not even a conscious decision.

It’s just that today it’s so easy to build without thinking about it.

You have spreadsheets, no-code tools, APIs, AI outputs…

You connect a few things and suddenly… It works!

So you move on.

But what’s really happening is:

You’re not removing complexity… you’re just postponing it.

And then reality hits

At the beginning, speed wins.

But after a while, the questions start showing up:

• Where is this data actually coming from?
• Why do we have duplicates everywhere?
• Can we even trust this?
• How do we connect this with anything else?
• Why is it so hard to change one simple thing?

And this is usually where systems start to feel heavy.

Not because of the code.

But because the data underneath was never really thought through.

So… should we start with the database?

Not really.

Trying to design the perfect database from day one is a bit like trying to design a whole city before knowing how people will live in it.

But starting with zero structure is like building houses with no roads.

So the answer sits somewhere in the middle.

The way I approach it

Before I start building anything, I just pause and think about three things:

What is actually happening?
What’s the real-world process here?

What exists in this system?
Users, bookings, documents, tasks, prompts… what are the core things?

How do they connect?
Who relates to what? What changes over time?

That’s it.

Not a perfect design.
Just a clear mental picture.

Because here’s the thing

Development gives you features.

But data gives you memory.

And memory is what allows a system to:

• grow
• connect
• learn
• evolve

This becomes even more obvious with AI.

You can have great prompts, great models…

But if your data is messy, fragmented or inconsistent,

Your AI will reflect exactly that.

A small shift that helps a lot

Instead of asking:

“What should I build?”

I’ve found it much more useful to ask:

“What needs to exist for this to work?”

And that naturally brings you to:

• entities
• relationships
• structure

And from there, everything else becomes clearer.

Final thought

You don’t need to get everything right from the start.

But you do need to respect the role of data.

Because in the end:

Interfaces are what people see.
Logic is what we write.
But data is what the system remembers.

And what it remembers… shapes what it can become.