Talking product architecture with AI

Last episode I said
you should get the architecture words straight before you start building.

So which words are those?
This episode is the answer.

A lot of people open AI
with nothing in their head but "I want a website" and roughly what it is about.

Then AI starts asking:
Do you need a login system?
Where does the data live?
Do you want RWD?

Or it asks nothing at all
and just starts writing code for you.

You might know some of the features, and half of the questions may not mean much to you,
so you say "fine, just build it first".

AI carries on the way it assumed you meant,
and there are only two outcomes:

1. It finishes and looks nothing like what you pictured.

2. You think AI is amazing, it built you a website that runs.
But you have no idea what it is doing underneath.
Then one day it breaks.
And you do not even know what to ask.
That is where most people get stuck.
They do not know what their AI actually built.

The real problem is not the AI.
You have not learned to speak the same language as it yet.

Four words you have to understand

You do not need to be able to write any of it,
but you do need to know what each part is responsible for.
What a website is normally made of
is what people call the architecture.

It is how you tell AI what you want.

1. Frontend, the side users see

Open a web page, and the buttons, text, images and layout you see
are all the frontend's work.

Think of it as the shop floor.
The look, the flow, the lighting a customer walks into,
all frontend.

Make these clear when you talk to AI:
・Is this product for phones or desktop? (or both)
・What is the style? Clean? Warm? Professional?
・What should users see the second they land?

2. Backend, the kitchen customers never see

Customers order out front,
the kitchen cooks in the back,
then the food comes out.

The backend is that kitchen.
A user presses a button,
and code runs behind it:
check identity, calculate the result, store the data, send it back.

You might wonder:
why can't the frontend just grab the data itself?

Because once the frontend can open the database directly,
you have left the back-door key by the entrance.
The backend is the doorkeeper
that checks who gets to take things and who does not.

Make these clear when you talk to AI:
・What should happen after a user presses the button?
・Is there anything that needs to be "remembered"? (login state, for example)
・Does it need to talk to outside services? (sending email, taking payment)

3. Database, the memory

Everything that has to be "remembered"
goes into the database.

Member records, product lists, order history, comments,
all of it lives in there.

Think of it as an enormous Excel file
where each sheet records one kind of thing.

Here is an example from NaLi Match.
We have an "artists" table
and a "customer requests" table.
Between them sits a "matches" table
that records which customer got matched with which artist.
String the three tables together by ID
and you can work out how many jobs each artist took.

Make these clear when you talk to AI:
・What data do you need to store?
・Is any of that data related to the rest?
(for example: one member can post many comments)
・Which data is private to the person, and which is public?

4. UI/UX, how it looks plus how it works

UI is User Interface.
In plain words, how good it looks.

UX is User Experience.
In plain words, how smoothly it works.

People say the two in one breath,
but they are separate things.

You have definitely had this happen:
an app that looks gorgeous,
but you cannot find the "cancel subscription" button.
That is strong UI, weak UX.
Beautiful, and infuriating to use.

Pretty but painful is strong UI, weak UX.
Easy but ugly is strong UX, weak UI.
What we want is both.

Make these clear when you talk to AI:
・Who are your target users? (age, habits, pain points)
・What action do they take most often?
・Which step is most likely to stall them?

How to open the discussion

Every time I start a new project,
I send AI this first:

I want to build product X. My target users are Y. The core feature is Z.
Before we write any code, I want you to discuss the architecture with me.
Ask me questions from four angles: frontend, backend, database and UI/UX.
I will answer them one at a time, and then you turn my answers into a spec.

Send that,
and AI becomes the consultant that asks the right questions
instead of the worker rushing to build.

This is how NaLi Match got designed

A friend and I spent one day
laying out the architecture of NaLi Match.

What we did that day
was exactly the four things above.

Settle those four things first
and you will not get lost once the code starts.

One reminder

Do not worry that your question is too basic.

The word "database"
only clicked for me last year.
Before that I thought "website" and "data" were the same thing.

As long as you are willing to ask,
AI will explain it any way you can follow.

Ask,
and your world gets a little bigger.

One last reminder

Before the architecture is settled,
do not ask AI "should I use React or Next.js".

That is not what you should care about right now.
Tools get picked last, not first.

Work out what you are building,
and AI will suggest the tools that fit.

Next episode covers
how these four parts fit together and work with each other.
APIs, data flow, static vs dynamic, dev vs production.
80% of the walls vibe coders hit come back to these.