If you look at how backend systems are actually built in Bern, you start noticing a pattern pretty quickly.
A lot of companies still rely on older stacks — C# (.NET), Java, or monolithic systems that have been evolving for years without a clear architectural reset. They still work. But working with them becomes slower and more expensive over time.
I’ve seen cases where even users inside Switzerland experience noticeable latency — not because of the network, but because the system itself wasn’t designed for modern API-based workflows.
The real issue usually appears when a business wants to move faster.
Integrations take longer than expected. Automation becomes messy. Even small changes start affecting multiple parts of the system.
At that point, the problem is no longer about the code itself — it’s about how the system is structured.
In these situations, I usually don’t suggest rewriting everything.
Instead, I introduce a FastAPI-based backend layer on top of the existing system.
This approach lets you keep what already works, while gradually improving performance and flexibility. You can expose clean APIs, simplify integrations, and reduce maintenance overhead — without taking unnecessary risks.
FastAPI also fits naturally into modern development workflows. Its structure is predictable, documentation comes out of the box, and new developers can get up to speed much faster — especially when combined with AI-assisted tools.
In practice, this leads to a backend that is simply easier to work with: faster, more flexible, and much easier to evolve over time.
When does a backend system actually become a problem?
Most systems don’t suddenly break. They just get slower to work with.
You notice it when simple changes take longer than they should. When integrations require custom workarounds. When deployments start feeling risky.
At some point, every new feature adds more friction instead of value.
This is common in systems built as monoliths or tightly coupled services. Not because they were built wrong — but because they were never designed for the way the business operates today.
Eventually, the bottleneck shifts from development speed to system structure.
Do you always need to rewrite everything?
In most cases — no.
A full rewrite sounds clean on paper, but in reality it introduces risk, long timelines, and unnecessary cost.
A more practical approach is to build a new API layer around the existing system.
This allows you to: - keep current infrastructure running - introduce modern interfaces gradually - improve performance without downtime
You don’t replace the system — you evolve it.
What does a modern backend architecture look like?
A modern backend is built around APIs, not internal system boundaries.
Instead of one large application, you get a set of smaller, clearly defined components that communicate through APIs.
With FastAPI, this typically means:
- async request handling for high concurrency
- clear separation between business logic and infrastructure
- structured data validation (Pydantic)
- automatic API documentation (OpenAPI)
The result is not just better performance — it’s predictability.
You know how the system behaves, how to extend it, and where to make changes without breaking everything else.
How does this help with integrations and automation?
Most real-world problems are not about building something new — they are about connecting what already exists.
ERP systems, CRM tools, payment providers, internal dashboards — they all need to work together.
Without a proper backend layer, every integration becomes a one-off solution.
With a structured API layer:
- systems exchange data consistently
- automation becomes easier to implement
- new services can be added without breaking existing flows
In practice, this approach is often used to extend platforms like Odoo or connect them with external systems such as payment providers, analytics tools, or custom applications.
What I focus on when building backend systems
I focus on systems that remain stable as they grow.
Not just something that works today — but something that still works a year later.
- Maintainability — code that other developers can understand and extend
- Performance — efficient handling of requests, data, and background tasks
- Reliability — predictable behavior under real-world load
- Scalability — architecture that supports growth without constant rewrites
The goal is simple: reduce long-term friction.
Final note
If your system is slowing down development, making integrations harder, or becoming expensive to maintain — it’s usually not a tooling problem.
It’s an architectural one.
And in many cases, fixing it doesn’t require starting over.
It just requires introducing the right structure on top of what you already have.