Every piece of custom software has two parts: the interface your team uses, and the system behind it that most people never see. That system — the backend — is where your data lives, where business rules get enforced, and where problems become expensive when the wrong decisions were made at the start.
You don't need to become a systems architect. But three or four architecture decisions made in week one of a project shape your maintenance costs, your flexibility and your risk for the entire lifespan of the software. Understanding what those decisions are is the difference between approving a design and blindly signing off on it.
What a backend actually is
When you open a portal, dashboard or internal tool, a browser or app sends a request to a server somewhere. That server runs code — the application logic — which reads or writes to a database and sends a response back. Everything you see on screen is the front end; everything on the server side is the backend.
Most business applications have three backend components:
- The application server — the code that processes requests, applies business rules (calculate this invoice, validate that order, send this notification) and coordinates the other parts
- The database — where data persists: customer records, orders, documents, history
- External integrations — the connections to other systems your business runs: accounting software, email, payment providers, ERPs
These three interact constantly. When someone submits an order, the application server validates it, writes it to the database, and triggers a confirmation via an external email service. Simple in concept — and the decisions around how they're structured matter more than which specific technology was chosen.
The decision that trips up most projects: monolith vs. microservices
Every developer has an opinion on this. Here's the version that's useful to you.
A monolith is a single application that handles everything: authentication, invoicing, reporting, integrations. Easier to build, test and deploy. One thing to monitor, one thing to scale, one set of logs when something breaks.
A microservices architecture splits the application into separate small services — one for authentication, one for invoicing, one for notifications — each running independently and communicating via APIs. Microservices are appropriate for companies like Netflix or Booking.com: huge teams, extreme scale, parts of the system that need to deploy hundreds of times per day independently.
For a business application handling hundreds or thousands of users, microservices add engineering complexity without a matching benefit. I've seen SMB projects quoted with a microservices architecture that added €25,000–€40,000 to the build cost and years to the operational complexity — for a product serving 50 internal users. For most business software, a well-structured monolith is the honest answer. If a developer proposes microservices for a business application below a few million monthly active users, ask specifically why. "It scales better" is not the reason — it costs more to build, more to maintain and more to debug.
The database decision
Two main families: relational databases (PostgreSQL, MySQL) and document or NoSQL databases (MongoDB, DynamoDB). The difference matters for your data:
- Relational databases store data in structured tables with defined relationships. Orders relate to customers, line items relate to products. They enforce data integrity by design — which is exactly what most business software needs. Default choice for anything involving financial records, customer data or operational workflows.
- Document databases store data as flexible JSON documents. Better for highly variable data structures or very high write volumes. Harder to query relationally — and in a business application, "who ordered what from which customer last quarter" is a relational query.
Most business software should use a relational database, specifically PostgreSQL — it's widely supported, has excellent tooling and any developer can maintain it. A developer choosing MongoDB for your invoicing system should have a specific reason beyond "we prefer it."
Architecture decisions that directly affect your costs
These aren't theoretical. Each one shows up in your bills or your maintenance hours:
How is data backed up, and has the restore been tested? A backup you've never restored from is not a backup — it's a plan that has never been proven. Daily automated backups with a tested restore process are a minimum standard for any application carrying business data. The hosting post covers where this fits in what infrastructure actually costs.
Is there a staging environment? Deploying untested changes directly to the live system is how you get a Friday afternoon where the checkout is broken and nobody knows why. A staging environment catches problems before they reach users. Its absence from an architecture plan is a red flag worth raising before work starts.
Are external services tightly coupled into the core? If swapping the email provider means rewriting 30% of the codebase, you're paying for that coupling on every future change. Well-structured code puts integrations behind an abstraction layer — changing one doesn't require touching the rest. This is the same structural principle as avoiding vendor lock-in applied to the code itself.
How does it handle failures? What happens when the payment provider is briefly unavailable? Does the order disappear silently, or does the application retry and alert someone? A backend with no error handling is one where bad things happen quietly. Good maintenance planning starts with a system designed to surface problems rather than swallow them.
Five questions to ask before approving the architecture
- Is this a monolith or microservices, and why is that the right call for this scale?
- Which database are you using, and why does it fit this data model?
- Where is data backed up, how often, and when was the restore last tested?
- How does the application behave when an external service goes down?
- If you handed this codebase to another developer tomorrow, how long would it take them to understand the structure?
You're not looking for technical perfection. You're looking for answers that are plain, confident and specific — and for a developer who thinks about these things before you ask. Vague answers, or defensiveness about the question, are the signal that matters.
Architecture is one of the most important conversations in a proper discovery phase — not because the choice of technology is complicated, but because the structural decisions made in week one travel with the software for its entire life. Getting them right at the start is the cheapest way to avoid an expensive rebuild later.
Planning a new build or reviewing a proposal? Get in touch and I'll give you an honest read on whether the architecture fits the problem — and where the risks are.