What software is made of

When you have a house built, you don’t need to know how to mix concrete. But if you can’t tell the foundation from the facade, you can easily end up paying for golden door handles in a house that’s sitting on mud. Software is the same. You don’t need to know how to code. You just need to know what pieces the thing is made of, where the expensive work happens, and what developers are actually talking about when the word “backend” comes up in a meeting.

This lesson is that vocabulary and map. We’ll go through the five main pieces and at the end put them back together, so you can see how your click travels from the screen to the data and back again.

Frontend: what the user sees and touches

The frontend is everything in front of your eyes. Buttons, forms, the app screen on your phone, the table you type into. It’s the part people mistake for the whole product, because it’s the only part they’ll ever see.

And that’s exactly where the first trap is. A pretty frontend tempts you into thinking the job is done. The client sees the clicked-together screens, likes them, and asks why it isn’t live yet. But what you’re looking at is the shop window. Behind the glass there might be nothing at all yet.

The frontend’s job is to make things show up nicely and clearly and react to what you do. It does not decide whether a given user is actually allowed to delete that invoice, nor whether the number on the invoice is correct. That’s somebody else’s job.

Backend: the logic the user never sees

The backend is the brain of the whole thing, and it runs hidden away on a server, out of the user’s sight. This is where everything that turns a pretty screen into a real product happens:

• Rules. What’s allowed and what isn’t. That an order can’t be placed without an address, that a discount can’t be applied twice.
• Calculations. The price with tax, shipping by weight, how much credit you have left.
• Who’s allowed to do what (permissions). The accountant sees invoices, the part-timer doesn’t. This must never be handled in the frontend, because the frontend can be bypassed.
• Talking to the outside world. Charging a payment through a payment gateway, sending an email, checking stock.

This is where most of the real work and most of the cost hides. It’s why two apps that look the same at first glance can cost ten times as differently. One just shows pictures; the other, under the hood, is guarding rules, money, and permissions.

A handy rule of thumb: the frontend handles “how it looks,” the backend handles “what actually happens.” When a developer asks you for a decision about rules and permissions, they’re working on the backend, and that’s the expensive part.

Database: where the data lives

The database is where the software remembers things even after you close the browser. Customers, orders, invoices, who logged in and when. Without it, the app would be like a person with short-term memory loss: every morning it would forget who you are.

It’s such a crucial piece that the entire next lesson is devoted to it. For now, remember one thing: your data is usually the most valuable thing you have in the whole system. Why that’s the case, and how not to lose it, we’ll dig into right after this.

API: how the individual pieces talk to each other

The frontend, the backend, and other systems all have to talk to each other somehow. That’s what an API is for. Picture a waiter in a restaurant. You at the table (the frontend) can’t see into the kitchen and don’t want to go there. You tell the waiter what you want, he carries it to the kitchen (the backend), and brings you back a finished plate.

The API is that waiter. It’s an agreed-upon list of what you can order and in what form you’ll get it. You don’t need to know how the kitchen works; you just need the menu.

Systems from different companies talk to each other over an API in exactly the same way. When an online shop shows you the live delivery status from a carrier or charges a payment through a payment gateway, it’s sending orders through their API. That’s why it’s worth asking: “Can it talk to our accounting system over an API?” If it can, you save yourself the manual re-keying of data and the errors that come with it.

Infrastructure and hosting: where the whole thing runs

Software has to physically run on some computer, twenty-four hours a day. That computer is called a server, and the fact that your app lives on it is called hosting. These days it almost never sits under a desk; it runs in the cloud, meaning on rented computers owned by big providers.

That brings a few things that hit you directly, in your wallet and in your sleep:

• Running costs. Hosting is paid monthly, whether the product is used by ten people or ten thousand. The heavier the load, the bigger the bill.
• Scaling. When an ad goes out at eight on a Friday evening and a surge hits, well-built infrastructure takes on more power. Badly built infrastructure crashes at exactly the moment you’re making the most money.
• Security and backups. This is where your data lives, so this is where you deal with who can reach it and what happens if the server fails. A topic for its own lesson; for now it’s enough to know it isn’t free and can’t be cut corners on.

How it all comes together into a product

Let’s trace the path of a single click. A customer in an online shop hits “Pay.”

The frontend wraps up that command and sends it over an API to the backend, which runs on a server somewhere in the cloud. The backend checks the rules (is the item in stock? does the price match?), asks the payment gateway over another API to charge the money, saves the result to the database, and sends back a response. The frontend receives it and shows “Thanks for your order.” For the customer it’s an instant; under the hood, five pieces had to work it out together.

And that’s exactly why it pays to know this vocabulary. When you can say “this is a frontend problem, it’s just displaying wrong” instead of “it doesn’t work,” you save hours of back-and-forth and often money on hunting for a bug in the wrong place. You don’t need to know how to build. You just need to know what to ask and where the expensive work happens. Next time we’ll look at the database, the most valuable thing you have in the whole system.