Web Application Architecture for SMEs in Plain English: What to Know Before Talking to Developers (2026)

A business owner wanted a booking and customer management system and spoke to two developers. The first proposed “a monolith on a VPS”. The second suggested “a React frontend, an API backend and a cloud database”. Both pitches sounded credible, but the owner had no idea how they differed or which suited the business.

This article explains web application architecture, the structure of a web app, in plain English for SME owners who don’t write code but do have to make decisions about budget, time and risk. The goal isn’t for you to design the system yourself. It’s for you to ask the right questions and understand the answers.

What Is Web Application Architecture?

Web application architecture is the set of decisions about which parts a web app is split into, what each part does, how they talk to each other and where they run. Think of it as a house plan: before laying bricks, you need to know where the kitchen goes and how the plumbing runs. Get it wrong at the start and you can fix it later, but it’s expensive and disruptive.

Almost every web app has three main layers:

Frontend: what users see and click, such as booking screens, forms and dashboards.
Backend (server side): the part that calculates, checks permissions, saves data, sends emails and connects to other systems.
Database: where customer, order, product and history data is stored.

Around these sit supporting components such as file storage, email delivery, payment processing and APIs connecting to external services. If you’re not sure whether you need a web app or just a website, browse our web application examples for business first.

Why Business Owners Need to Understand This

Many people assume architecture is purely the developer’s concern, but the choice affects your business directly:

Monthly costs: some architectures need several servers or many cloud services.
Dependence on one person: an unnecessarily complex system is hard to hand over to someone else.
Speed of adding features: an architecture that matches your team size makes changes quicker.
Data risk: backups and security are set by the architecture.
Ownership: whose accounts hold the data and code, and what happens if you part ways with the developer.

Monolith vs Separate Frontend and Backend

This is usually the first question. Here’s the simplest way to put it.

A monolith has the frontend and backend in one project, running on one server. Examples include systems built with Laravel, Django, Ruby on Rails, or WordPress rendering pages on the server.

A decoupled (API-first) setup has the frontend as a separate app (for example React, Vue or Next.js) talking to a backend through an API, which is a separate project. Data travels back and forth as JSON.

Aspect	Monolith	Separate frontend and backend
Initial complexity	Low, one project	Higher, two parts to maintain
Time to first version	Often faster for small teams	More setup time
Adding a mobile app later	An API has to be added	Reuse the existing API
Deployment	One place	Two places, versions must stay in sync
Finding someone to maintain it	Not hard for a popular framework	Two technologies to cover
Suits	Internal tools, booking systems, small to mid-sized CRMs	Multi-channel systems, e.g. web + app + partners

For most SMEs building their first system, a well-organised monolith is usually the most cost-effective starting point. A small team can maintain it easily, and parts can be split out later when there’s a real reason. Microservices (breaking the system into dozens of small services) suit organisations with several development teams working in parallel and are rarely needed by an SME. If someone proposes them, ask: “What problem does this solve that a monolith can’t?”

Where the System Runs and Where Data Lives

Hosting Options: Where Will the System Live?

Hosting affects stability, cost and how much maintenance you take on.

Shared hosting: inexpensive and fine for ordinary websites, but often restricted on background jobs, language versions and resources. Not a great fit for web apps with many concurrent users.
VPS (virtual private server): your own virtual machine. Very flexible, but someone has to maintain the operating system, apply security updates and set up backups.
PaaS (platform as a service): the platform manages the servers and you just deploy code. Convenient, but costs can rise with usage.
Full cloud (e.g. AWS, Google Cloud, Azure): the most flexible, with every service imaginable, but complex to configure and costs need close monitoring.
Static or edge hosting for the frontend: if the frontend is built as static files, it can sit on services like Cloudflare Pages or Vercel. Fast and low-maintenance.

The important point is that hosting, domain and cloud accounts should be in your business’s name, with developers given access, not held in a developer’s personal account.

The Database: The Hardest Part to Change

Code can be rewritten and screens redesigned, but data is a business asset, and the database structure is the hardest thing to change once a system has been running for a while.

Databases fall into two broad types:

Relational (SQL) databases such as MySQL, PostgreSQL and MariaDB store data in linked tables. They suit typical business data such as customers, orders and invoices, where accuracy matters.
NoSQL databases such as MongoDB and Firestore store data more flexibly. They suit some jobs, such as data whose shape changes often, or certain real-time apps.

For most business systems, an SQL database is the safe choice: reporting is easy, integrity can be enforced and it’s very widely used. Questions to ask your developer:

Where is the data stored, and who has access?
If we stop working together, in what format can we export all of it?
How is customers’ personal data encrypted or access-restricted?

Backup and Recovery: Agree on It from Day One

A system without backups that can actually be restored is gambling the whole business’s data on luck. A widely used rule is 3-2-1: at least three copies, on two different media or services, with at least one copy outside the main system.

What to specify in the scope of work:

Item	What to agree
Database backup frequency	Daily at minimum; transaction-heavy systems may need more
User-uploaded files	Backed up separately, or kept in storage with its own redundancy
Retention	How many days or months to keep
Backup location	Off the main server and in the business’s own account
Restore testing	Real test restores on a schedule, not just checking the files exist
Acceptable downtime	How many hours until the system must be back, and how many hours of data you can afford to lose

The last two have technical names, RTO and RPO. You don’t need to memorise the terms, but you should be able to answer “how much would it hurt the business if the system were gone for half a day?” and have the developer design for that. If the system does go down, there’s a response plan in what to do when your website is down.

Security Basics SMEs Shouldn’t Overlook

You don’t need a security team, but you do need these basics covered:

HTTPS on every page, no exceptions.
Role-based permissions: staff see only the data their job requires.
Hashed passwords, with two-factor authentication (2FA) for administrators.
Framework and library updates on a schedule, with a named person responsible.
Validation of user input, to block basic attacks such as SQL injection and XSS.
Secrets kept out of the code: database passwords and API keys shouldn’t sit in shared code files.
Activity logs: who changed what, and when.
PDPA compliance: collect only the data you need and publish a privacy policy. Read more in website privacy policy and PDPA.

Scaling Later: Don’t Over-Provision

A common mistake is designing for a massive user base on day one when the business has a few dozen users. The result is a longer build, higher running costs and needless complexity.

A more sensible approach is design so you can scale, but don’t scale yet. For example:

Store user uploads in object storage from the start, so you can add servers later.
Run heavy jobs, such as bulk emails or report generation, in a background queue so users don’t wait.
Cache data that is read often but changes rarely.
Write the code in clearly separated modules, in case a part needs to become its own service one day.
Monitor performance so you know where the real bottleneck is before spending more.

A typical scaling path is: upgrade the server, move the database to its own machine, add caching, then add more application servers. Each step is taken only when real signals call for it.

Questions to Ask Your Developer Before the Project Starts

Take this list into your first meeting:

Why this architecture, and is there a simpler option?
Which language and framework, and how easy is it to find someone to maintain it?
Where does the code live (e.g. a Git repository), and does the business have access?
Whose name are the hosting, database and domain accounts in?
How are backups done, and how often are restores tested?
Is there a staging site separate from the live system?
What are the monthly running costs after launch, and how do they grow with usage?
Is there system documentation and a handover guide?
Who is responsible for security updates after handover?
If we want a mobile app or new integrations later, how much would need to change?

If you’re still weighing up building versus buying, see custom software vs SaaS.

At Southern Whale we’re a freelance team helping SMEs in Southern Thailand plan systems that fit the size of the business, without needless complexity, and with the business owning all its data and accounts. We can help sketch the architecture through our system design service and build it through our software development service. If you already have a system in mind, give us the rough outline on LINE OA and we’ll help you work out which structure to start with.

Web Application Architecture FAQ

Does an SME need microservices?

Usually not. Microservices suit organisations with several teams and very large systems. For an SME, a monolith with well-separated modules is easier and cheaper to maintain.

Can we start with a monolith and split it up later?

Yes. If the code is organised into clean modules from the start, parts can later be split out into an API or separate service without rebuilding the whole system.

Should we use a big cloud provider or a plain VPS?

It depends on who maintains it. Without anyone to manage servers, PaaS or managed services reduce the burden. With someone experienced, a VPS is good value and gives you control. Big cloud providers make sense when you need several specialised services.

Who should own the business’s data?

The business, always. Database, hosting, domain and code repository accounts should be in the business’s name, with developers given access.

Do we need a mobile app as well?

Not necessarily. A web app designed to work well on mobile covers most needs. If you plan an app in future, design the backend as an API from the start.

Should the system have a staging environment?

Yes. It lets you test new features and updates before they reach the live system, reducing the risk of breaking things during working hours.

Summary

Good web application architecture for an SME isn’t the most fashionable stack. It’s the one that fits your team size, maintenance budget and business plans. Start with a well-organised monolith, or separate the frontend when there’s a clear reason. Choose hosting based on who can look after it, use a database that suits business data, agree on backups, security and ownership from day one, and scale only when real signals appear. With that, you can talk to developers with confidence.