How Software Fits Together

Most applications can be understood through five responsibilities. The interface collects and displays information. The application logic applies rules. The data layer remembers state. Integrations communicate with other systems. Identity and permissions decide who may see or change what.

Small tools may combine all five in one project. Large systems may split them across hundreds of services. The useful question is not how many files exist. It is which responsibility owns the behavior you want to understand or change.

Imagine a person clicks Approve. The interface packages the record identifier and the intended action into a request. A server receives it, confirms the person's identity and permission, loads the current record, applies the approval rule, saves the new state, and returns a response. The interface then shows the result.

This request lifecycle is a powerful debugging map. If the button does nothing, inspect the interface event. If the server rejects the action, inspect the request and authorization. If the screen says approved but refreshes to pending, inspect persistence. If another system never receives the update, inspect the integration and its logs.

The front end is the part delivered to the user's device: screens, forms, buttons, and client-side interaction. The back end is the part that runs under the application's control: protected logic, database access, jobs, and integrations. This is a responsibility boundary, not a judgment about which side is more important.

Anything sent to a browser should be treated as visible to the user. That is why privileged secrets and final authorization decisions belong on the back end. A hidden button is not security; the server must still decide whether the requested action is allowed.

State is information the system must remember: a user's profile, an invoice status, a document version, a workflow step, or a conversation. A database is a structured place to persist and query that state. A spreadsheet can also hold state, but it offers different guarantees, relationships, access controls, and scaling behavior.

A schema defines the shape of stored information. A useful schema reflects the domain: records have identifiers, meaningful fields, relationships, timestamps, and lifecycle states. If the data model cannot distinguish draft from approved, the interface cannot reliably recover that distinction later.

An API is a defined way for one program to ask another program for information or an action. The contract names what can be requested, what inputs are required, what result comes back, and which errors are possible. A good API lets both sides evolve without depending on each other's internal code.

Agent tools follow the same idea. A tool named send_invoice should define the invoice identifier, recipient, allowed states, confirmation behavior, result, and errors. A vague tool called do_finance_work pushes important decisions into a place you cannot inspect.

Authentication answers: who are you? Authorization answers: are you allowed to do this? Audit history answers: who did what, when, and to which record? These are separate responsibilities. A system can know a user's identity and still correctly refuse an action.

As your builds become more consequential, model these boundaries early. Start with the smallest useful roles, grant the least access required, and record actions that change money, access, public content, customer data, or other people's work.