I've noticed something when talking to small business owners.

A lot of people hire developers or agencies to build a website, app, ordering system, dashboard, etc., without really knowing what the different pieces do.

And I don't think you need to become technical.

But knowing the basic vocabulary helps a lot. You can understand what you're paying for, ask better questions, and have a better conversation when someone says "we need a server," "the backend is done," or "we need to set up a database."

So I wrote this in very simple terms. Technical people will probably simplify some of this further, but this is mainly for business owners who have little or no tech background.

First, the basic words

Server

A server is basically a computer somewhere that is connected to the internet and can run your software.

It has CPU, memory, storage, etc., just like other computers. The main difference is that it is set up to be accessed over the internet and run things continuously.

Your developer puts software and logic on this machine.

When someone visits your website or uses your app, their request may eventually reach this server.

You don't necessarily buy and physically keep this computer. Usually, you rent computing resources from companies such as Amazon, Google, Microsoft, or other hosting providers.

This is where terms like AWS EC2, Google Cloud, Azure, Heroku, etc. come in.

Think of the server as the place where the work behind your software happens.

Client side

The client side is what the customer actually sees and interacts with.

Your website in a browser is a client.

Your mobile app is also a client.

For example, when someone visits your website, the server can send information to their browser. The browser then renders that information into the page they see.

The customer sees the business name, products, buttons, images, forms, and so on.

So when a developer says "this is frontend" or "this is client side," they usually mean the part that runs on or is presented to the user's device.

A very simplified flow is:

Customer opens browser -> browser requests your website -> server sends the required response -> browser displays it.

Server side

The server side is where things happen that the user usually does not directly see.

For example:

• checking whether a user can log in
• calculating an order total
• deciding whether an order should be accepted
• talking to a payment provider
• saving an order
• checking permissions
• sending a request to another service

This is often called the backend.

A customer might click "Place order," but the actual logic for placing that order can happen on the server.

The customer sees the result. They don't necessarily see the code or the rules behind it.

Database or DB

A database is where your application stores structured data so it can find and use it later.

For example:

• users
• customer details
• product names
• prices
• orders
• transaction records
• addresses
• IDs
• other information created by the business or users

The important part is this:

If your software needs to remember something and retrieve it later, you will probably need some kind of storage.

A database is software that helps store and retrieve that structured information efficiently.

For example, when someone asks, "Show me all orders from this customer," the application can ask the database for that information.

The database itself also needs somewhere to run. Depending on the setup, it may run on a server or be provided as a managed service.

Images and files

Images, PDFs, documents, videos, and other files are often stored separately from the main database.

For example, imagine you run an ecommerce business.

Your database might contain:

The actual image file may live somewhere designed for file storage.

Your application stores the location of the image and then loads it when needed.

This is why you may hear about services for file or object storage.

The basic idea is simple: the database can store information about the file, while another storage system stores the actual file.

Domain

A domain is the human-friendly address people remember.

For example:

yourbussines .com

Without a domain, people could theoretically access a service using a numerical IP address. But nobody wants to remember something like that.

So the domain gives your business an easier address to use.

You can buy and manage domains through domain registrars.

One important thing to understand: buying a domain does not automatically mean you have a website or server.

A domain is the address.

You still need to tell the internet where that address should point.

IP address

An IP address is an address used for communication over the internet.

Very roughly, your domain helps people find the correct destination.

When someone types:

your business website

the internet uses DNS to figure out where that domain should go.

For a simple example, it might eventually point to an IP address associated with your server.

Then the request reaches the server, and the server responds.

There are more details involved in real systems, but this is enough to understand the basic flow.

DNS

DNS is what helps connect a human-friendly domain name to the technical destination behind it.

You can think of it like a directory.

You remember:

yourbusiness's website

DNS helps the internet find where that should go.

So if someone says, "We need to change the DNS records," they are usually talking about changing how your domain points to or connects with another service.

This is useful vocabulary to know because DNS changes often come up when moving websites, changing servers, setting up email, or connecting external services.

Now let's see how all of this works together

Let's say you own a business and want a very basic portfolio website.

You want a page that says:

Information about your interior business, like you name, store location, etc.

No login. No orders. No customer dashboard. Just information.

Someone types:

abcinteriors com

The basic flow looks something like this:

1. The person enters your domain in their browser.
2. DNS helps direct that domain to the correct destination.
3. The browser sends a request.
4. Your server receives the request.
5. The server sends back the information for the page.
6. The browser renders it and shows the page to the visitor.

You may also hear about a URL like this:

abcinteriors *com/

The / is commonly used to represent the root or home path.

Then you might have:

abcinteriors *com/about

abcinteriors *com/contact

Those are different routes or paths.

A route is basically an address inside your application where something specific happens or is shown.

So /about might show the About page.

/contact might show the Contact page.

What if you add images?

Now your portfolio has photos of your work.

Your browser still requests the website.

The website response can include information telling the browser where the images are located.

For example, the page might effectively say:

"Show this image from this location."

The browser then requests that image and displays it.

So you may have:

Domain -> website/server -> page information -> browser

And separately:

Browser -> image URL -> image storage/server -> image returned -> browser displays image

Again, this is simplified, but it helps explain why your developer may talk about the website, API, database, and file storage as separate things.

Now you want customers to place orders

This changes things.

Suppose the customer visits:

abcinteriors*com/order

They see a form.

They enter:

• name
• phone number
• product
• quantity
• address

Then they click:

"Place order"

Now something needs to actually happen.

The button can trigger a request from the client to your server.

For example, conceptually, the request could go to something like:

/placeorder

The name doesn't have to be exactly that. Your developer decides how the routes or API endpoints are structured.

The server receives the order details.

Then the server-side logic can do things such as:

• check whether the required information exists
• calculate or verify the order
• create the order
• send information somewhere else

At this point, your website is doing more than displaying information.

There is an application processing an action.

This is what people generally mean when they talk about a web application.

A simple marketing or portfolio site mainly presents information.

A web application allows users to do something and has logic handling those actions.

The line can sometimes be blurry, but that distinction is useful for a business owner.

What if you want a WhatsApp notification when an order is placed?

Let's say every new order should send you a notification.

Your server receives the order.

Then your server can communicate with another service through an API.

API is another word worth knowing.

An API is a way for one piece of software to communicate with another piece of software using defined rules.

So your order system might say:

"An order was just placed. Here are the details."

And send that information to a service that handles messaging.

That service processes the request according to its API.

The important thing here is that your software does not need to personally "know how WhatsApp works internally."

It follows the interface or API provided by the service it is integrating with.

So the flow could look like:

Customer clicks "Place order"
-> request goes to your server
-> server processes the order
-> server calls an external API
-> you receive a notification

But where is the order stored?

This is where the database comes in.

Imagine you only receive the order as a notification.

You see it.

You deal with it.

But your own application has not saved it anywhere.

The next day, if you want your website to show:

"Here are all orders from customer X"

where will it get that information from?

It needs to have stored it.

Without persistent storage, once the current processing is finished, your application may have nothing saved to look up later.

This is where people sometimes use the word stateless.

A stateless part of a system does not automatically remember previous interactions just because they happened before.

If you want something remembered, you store it somewhere.

For orders, that might be a database.

So when the customer clicks "Place order," the flow could now be:

Customer enters order details
-> client sends request to server
-> server validates/processes the request
-> server saves the order in the database
-> server sends a WhatsApp notification
-> server returns a response to the customer

Now you can later build something like:

/find-my-orders

or a customer dashboard.

The application receives a request asking for the customer's orders.

The server checks who the customer is and asks the database for the relevant records.

The database returns the matching information.

The server sends the result back.

The client displays it.

That is the basic pattern behind a huge number of applications.

One thing that helped me understand all this: follow the request

When you're confused about a technical system, ask these questions:

Who is making the request?

A customer? A browser? Your mobile app? Another service?

Where does the request go?

Your server? An external API? A payment provider?

What happens there?

Is information checked? Is business logic running? Is a calculation happening?

Where is the data stored?

A database? File storage? Nowhere?

What comes back?

A webpage? A success message? An error? A list of orders?

If you can follow those five questions, a lot of software architecture starts making more sense.

A small example of the whole thing

Let's say you run a custom cake business.

A customer visits:

My cakes .com

The browser is the client.

The domain helps them reach the correct destination.

Your server provides the application.

The customer sees your products and clicks "Order."

The client sends the order details to your server.

The server runs the business logic:

"Is the required information present?"

"Is this product available?"

"What is the final price?"

Then the server stores the order in your database.

If the customer uploaded a reference image, that file may go to file storage.

The server can then call another company's API to send you a notification.

Later, you log into your admin panel.

Your browser asks the server:

"Give me today's orders."

The server asks the database.

The database returns the orders.

The server sends them to your browser.

Your browser displays them.

That's the whole idea.

There can be many more layers in a real system, but a lot of them are variations of:

A client asks for something -> a server processes it -> the system may store or retrieve data -> the server sends back a result.

Why I think business owners should know this

You don't need to know how to write the code.

But if you're paying someone to build software for your business, knowing the vocabulary helps.

You can ask things like:

• Where is this application hosted?
• Who owns the server account?
• Who owns the domain?
• Where is the database hosted?
• Where are uploaded files stored?
• What happens when a customer places an order?
• Is the order stored before or after a notification is sent?
• What external APIs are we dependent on?
• If we change developers, do we have access to the server, domain, database, and source code?
• What will I need to keep paying for every month?
• If this server goes down, what stops working?

You don't need to micromanage developers with these questions.

The point is to understand what you own, what you're renting, and what the different parts of your system actually do.

If you're a non-technical business owner, I'd be interested in knowing which technical terms confuse you the most. Things like API, hosting, cloud, server, database, frontend, backend, authentication, DNS, etc.

I can add them to this vocabulary list and explain them using business examples.

If you read this far and have a question, ask in comment or shoot a DM.