Anatomy of a Software System
Almost every app you use is made of the same three parts: a frontend, a backend, and a database. Learn how a request flows between them and you can read — and plan — nearly any product.
The Three Parts
Every part has one clear job. Naming them is the first step to directing a build.
- Frontend — what the user sees and touches; runs in the browser or the app on the device.
- Backend — the server: the logic, the rules, and the security that decide what happens.
- Database — where data is stored and retrieved, so it survives between visits.
The Request Lifecycle
The three parts are not islands — they pass a single request back and forth. Follow it end to end and the whole system makes sense.
Loading Your Task List
Say you open an app to see this week’s tasks. Watch the same round trip play out through all three parts.
You Direct, You Don’t Build
You don’t need to write each part yourself — that is what a coding agent is for. But naming the parts lets you write a plan an agent can actually execute, and spot exactly where a feature should live before a single line is written.
Build It
How to implement: take any app you use daily — notes, messaging, shopping — and sketch its three parts on paper. What is frontend? What is backend? What is stored in the database?
- Weekly AI Tasks tracker — it is exactly this shape: a frontend (the task UI), a backend (logic plus a messaging webhook), and a database (your tasks and notes).
- Personal brand site — mostly frontend, and often no database at all (a static site). That is a real architectural choice you will make in Module 4.
What you learned
Almost every system is a frontend, a backend, and a database, passing one request between them. Naming those parts is what lets you plan a build and direct an agent — and both capstones fit this exact shape.