How the parts fit together

Last episode we met the four parts:
frontend, backend, database, UI/UX.

Knowing the parts is not enough.
You also need to know
how they work together.

Without that,
you end up in the "second outcome" from EP.1.
The site runs,
and you have no idea why it runs.

This episode covers four ideas.
80% of the walls vibe coders hit come back to them.

1. API, the walkie-talkie between frontend and backend

The frontend and the backend are two separate things,
and they do not go looking for each other.

They need a walkie-talkie.
That walkie-talkie is the API.

API stands for Application Programming Interface,
which sounds complicated.
In plain words it is just "the way they talk".

Frontend says:
"Give me this member's order list"

Backend hears it:
"Sure, I will go get it from the database, hold on"

Backend has the data:
"Here you go, 5 orders"

The frontend draws those 5 orders on screen for the user.

That whole round trip
is one API request.

Every app and every website you open
is firing API requests nonstop behind the scenes.
Scrolling IG, scrolling Threads, pressing buttons, scrolling a page,
most of those actions are talking to a backend.

When you talk to AI, remember just one thing:
when you say "after this button is pressed, do X",
AI writes you an API.

2. Data flow, the six things behind one button

Four parts plus an API,
strung into one complete action. What does that look like?

Here is a real case from NaLi Match.
What happens when a customer presses "send request" on NaLi Match?

Behind one button,
six things are running.

You do not need to write any of it,
you just need to know the six exist.
When something breaks,
that is how you know which step to ask AI about.

"Nothing happens when I press it"
→ maybe step 1, the frontend never caught the event

"It throws an error message"
→ maybe step 3, the doorkeeper blocked it

"It says success but nothing got saved"
→ maybe step 4, the write failed

Know the flow
and your debugging gets precise.

3. Static vs dynamic, not every site needs a backend

This idea saves you a pile of work.

Not every site needs a backend and a database.

leoaido.com (the site you are reading right now)
is a pure static site.

No members, no backend code, no complicated server logic.
Every article is one .html file,
HTML + CSS + a little JavaScript and it is done.

The view counter in the top corner
is frontend JavaScript calling a cloud service, Supabase.
No backend of my own, and it still stores data.
That is what a static site plus a third-party service can do.

The key idea:
"Static" does not mean nothing on the site moves.
It means there is no backend server of your own running code.
You can still use third-party services (Supabase, Firebase, Disqus)
to give a static site dynamic features.

The mistake vibe coders make most:
what they need is a landing page,
and they open by asking AI for a database, a login system and APIs.

Three days later it is still not live.

You can just ask AI straight out:
"Does this product need a backend, or is pure frontend enough?"
Let AI make the call.

4. Dev vs production, two worlds

You will hit this one 100% of the time,
so I want to cover it now.

Your site actually lives in two worlds:

They are separate worlds.

Change something on your computer
and nothing changes online by itself.
You have to deploy
before the live version updates.

"But it works on my machine?"

You will hear this line a million times.
The reason is always the same:
they forgot that online is a different world.

Why does that happen?
Because the two worlds have different setups:
different file paths,
different URLs,
different API keys,
different databases.

So "it runs in dev"
does not mean "it runs in production".

EP.6 covers deploying on Vercel in practice.
But the "two worlds" idea
is one to hold onto right now.

Three light extras

These three are not core,
but every vibe coder trips over them sooner or later.
Here is a first impression,
later episodes go into detail.

A question template for vibe coders

Next time you start a project,
on top of the architecture discussion from EP.2,
you can also ask AI these:

・Does this product need a backend, or pure frontend?
・Which actions fire API requests?
・How does the data flow? List every step from button to database
・Which values go in environment variables, and which can sit in the frontend?
・What should I watch out for before deploying to Vercel?

Ask those five questions
and you will understand 80% of how your own product works.

Two technical extras (if you want to go deeper)

These two are a bit more advanced.
They will not stop you from building,
but knowing them makes you sharper.

Extra A: is it really true that no API key can go in the frontend?

As a rule, yes.
But a few keys are designed to be public.

Supabase's anon key, for example.
It is meant for the frontend,
because Supabase uses a mechanism called Row Level Security (RLS)
to control who can read and write each row at the database level.

So whether a key can go in the frontend
is not about whether it is called a "key",
it is about whether something is protecting it.

The safe habit for vibe coders:
if you are not sure, keep it in the backend.
Put it in the frontend only when the service's docs say "safe to expose in browser"
or "public anon key".

Extra B: what does a dev URL actually look like?

I wrote "http://localhost:3000" above.
That is the default URL when you develop with a framework like Next.js, Vite or React.
localhost means "your own computer",
and 3000 is the port this service is using.

If you only wrote a plain HTML file,
double-clicking it opens a URL that starts with file:// ,
which is the path to a file on your own machine.

Both count as a "dev environment",
and they share one trait:
only you can see it, nobody else can reach it.

Once it is online it becomes a real domain starting with https://,
and that is production.

Next episode covers
how to build your first web page with AI.
HTML, CSS and JavaScript,
what each of them does,
all in one episode.