You can write functions and classes and build algorithms. And yet, the moment it becomes "build and ship one web app," you suddenly lose your footing. What is the difference between frontend and backend? What is a React component, really? Plenty of people know programming itself yet stall on the vocabulary that shows up in the web context.
As an indie developer building apps, I was one of the people who hit this wall first. Here I lay out the terms and concepts of modern web app development as a single map, using Next.js and Supabase as examples. The specific tech is just an example; the thinking carries to other stacks.
A web app is made of three parts
First, the big map. A web app splits into three parts.
- Frontend — what the user actually sees and touches (screens, buttons, forms)
- Backend — receives requests from the front and processes data
- Database — where data is stored
The biggest difference from an ordinary program is that a web app stands on the coordination of two kinds of program: code that runs on the browser and code that runs on the server. This is exactly where people get confused first, so keep this map in mind to avoid getting lost.
The browser is "a machine that runs HTML, CSS, and JavaScript"
The frontend is simpler than it sounds. The browser receives three kinds of files, interprets them, and paints the screen. HTML handles "what to show (structure)," CSS handles "how it looks (design)," and JavaScript handles "what happens when something happens (behavior)."
You might think, "then just build with HTML, CSS, and JS." At small scale, you can. But writing all the "rewrite the screen every time the state changes" logic — a list grows when you press a button, the display shifts as you type — in raw JS quickly becomes unmanageable.
Why use a framework like React
React offers the idea of "writing the screen's look declaratively, as a function of data (state)." Instead of imperatively writing "when the button is pressed, rewrite this element," you declare "given this value, the screen looks like this." When the value changes, React rewrites only the relevant part for you.
The "component" that shows up here is easiest to grasp as a unit of screen reuse. Where an ordinary function is "input (arguments) to output (return value)," a component is "input (props) to output (the screen's look)." Swap in the feel of using functions to reuse logic, and using components to reuse screens, and it clicks.
What the framework solves for you
React is a library for building screen parts, but on its own it leaves practical gaps: how to decide which screen each URL shows (routing), how to get read by search engines, how to handle image and build configuration.
A framework like Next.js standardizes these as "rules of folder structure." In Next.js, a folder name becomes the URL path directly. Routing completes just by placing files, so "URL design becomes folder design," and hesitation drops. Building an admin screen for an app, I too leaned on that straightforwardness.
The stumbling block: "runs on the server, or the browser?"
What trips people up most in modern frameworks is that "the part run on the server" and "the part run on the browser" coexist in the same file. Ordinary programs rarely make you think about "where this runs," but in a web app it matters.
The criterion is simple: does it "need to react to user actions like clicks or form input?" If not, run it server-side, where you can write data fetching directly and it is fast. If so, run it browser-side. At first you tend to think "just make it all browser-side and it works," but that loses the benefit of running on the server. Carry the intent of carving out "only the parts that truly need interaction," and the design clears up.
Leave the foundation to a BaaS
Until recently, building a web app meant renting a server, configuring a database, and hand-rolling login and real-time communication. Hand-rolling each is high-hurdle, and you tend to run out of energy before reaching the logic you actually wanted to build.
A BaaS (Backend as a Service) provides that foundation wholesale as a service. Supabase is the representative example.
| What you want | What Supabase provides |
|---|---|
| Database | PostgreSQL (a real relational DB) |
| Login | Auth (email/password, various social logins) |
| Real-time updates | Realtime (notifies the browser of DB changes instantly) |
| File storage | Storage |
In short, a BaaS prepares a state where "you can operate the DB safely from the browser without writing server-side code yourself." When you want to stand up an app's backend quickly in indie development, that benefit is large.
A mindset for building your first one
Finally, a couple of ideas that make the first one easier. First, always be conscious of "where this code runs." Grasp that and much of the confusion dissolves. Second, do not hand-roll the basics of auth and DB; leave the foundation to a BaaS and narrow what you write to your app's own logic.
The jargon looks heavy, but much of it is just past programming knowledge translated into the web context. Build one small app all the way through, and the concepts written here start to connect into view. In the follow-up, I dig into what you will inevitably face on this foundation — DB access control (RLS), screen state management, and real-time updates — with code. For now, take one small app from start to finish.