The courthouse metaphor
Imagine a small county courthouse. A member of the public walks up to the front desk and asks to file a motion. The front-desk clerk doesn't actually decide whether the motion is procedurally proper, or where the case file lives, or whether the judge is in. The clerk takes the request, walks back to the office that handles that case type, and passes the request along. The office decides what to do, possibly retrieves the case file from a filing room, possibly updates it, and sends an answer back to the clerk, who hands it to the member of the public.
That's it. That's a website.
The front desk = the browser
Your web browser — Chrome, Safari, Firefox, Edge — is the front desk. It's the part the user sees and touches. When a lawyer fills out an intake form, they are doing it in the browser. When they click a button, the browser packages up what they did and sends it on. The browser doesn't actually know anything about your firm, your matters, or your data. It is just a clerk with a clipboard.
Everything visual — colors, layout, the form fields, the buttons — is the front desk. The whole thing is built from three quiet languages: HTML for the structure ("there's a heading here, three input fields, then a submit button"), CSS for the styling ("the button is blue, the font is sans-serif"), and JavaScript for the behaviour ("when they click submit, package up these values and send them along").
The back office = the server
When the browser sends a request — say, the lawyer just submitted that intake form — the request travels across the internet to a server. A server is just a computer that's been left on, running a program that listens for requests and decides what to do with each one. "They submitted an intake form? OK, validate that the email looks like an email, save it to the case file, send a confirmation email, then tell the browser everything went fine."
The server is where the actual decisions get made. Anything that has to be private (an API key, a password check) lives on the server, because the browser is, by definition, in your user's hands. You wouldn't trust the front-desk clerk with the safe combination, and you wouldn't put your firm's secrets in the browser.
The filing cabinet = the database
When the server saves the intake form, it's saving it to a database. A database is a structured filing cabinet for software. Unlike a spreadsheet, a database can handle many people writing to it at the same time without losing rows, can answer complex questions quickly ("give me every matter where the statute date is in the next 30 days"), and can enforce rules ("every matter must have a client, every client must have an email").
Most of the data your tools handle — clients, matters, intake submissions, document records — lives in a database somewhere. You don't need to know how the database works internally. You only need to know that it exists, that it stores things, and that the server is the only thing that talks to it.
What this lets you do in conversation
Now, when a developer or a vendor uses any of these words, you can place them somewhere on the diagram. "Frontend" means the browser side. "Backend" or "API" means the server side. "Database" means the filing cabinet. "Hosting" means somebody else's computer running the server. "Deploy" means "put a new version of the back office in place."
Where BuildLegal fits
When you build a tool here, BuildLegal puts together all three pieces for you. The browser side (the form your lawyer or client sees), the server side (the logic that handles their submission, talks to AI, sends emails), and the database side (where the submissions are saved) are all stitched together by the AI as you describe what you need. You don't have to think about the seams. You just have to know they're there.