We've shipped over 50 products. The ones that are still running — years later, at scale, without drama — all have something in common: boring architecture.
Not boring as in uninspired. Boring as in predictable, well-understood, and deliberately un-clever. The kind of architecture that doesn't make a great conference talk but makes a great Tuesday at 3am when something breaks and the on-call engineer needs to fix it in ten minutes.
The allure of the shiny thing
Every new project starts with the same temptation. A CTO reads about a new framework. A senior engineer wants to try event sourcing. Someone suggests microservices for a product that doesn't exist yet.
We've been there. Early in our history, we over-engineered things. We chose technologies because they were interesting, not because they were right. We learned the hard way that the cost of architectural novelty compounds over time — in onboarding new engineers, in debugging production issues, in the 2am calls that shouldn't have happened.
Now we actively resist it. Not because we're against innovation — we build AI systems and RAG pipelines for a living. But because the infrastructure those systems run on should be the most boring thing in the stack.
What boring looks like in practice
PostgreSQL over the new hotness. We've used Postgres on more projects than any other database. Not because it's exciting, but because it handles 95% of use cases, has decades of tooling, and every engineer we hire already knows it. We reach for DynamoDB or Redis when there's a specific reason — high-throughput key-value access, caching — not as a default.
Serverless Lambda over Kubernetes for most things. Kubernetes is powerful. It's also complex, expensive to operate, and overkill for most products under 10 million users. AWS Lambda with CDK gives us auto-scaling, zero server management, and costs that scale linearly with usage. We run 30+ Lambda functions on some projects. Total infrastructure cost: under 50 EUR/month.
Monolith first, microservices never (usually). We've built exactly one project that genuinely needed microservices from day one — an enterprise mentoring platform with distinct domains, separate scaling needs, and a team large enough to manage the operational overhead. Every other project started as a monolith. Most stayed that way. They're easier to debug, easier to deploy, and easier to reason about.
React, not the framework of the month. We use React, Next.js, and Vue.js because our entire team knows them deeply. When a new frontend framework appears (and they appear monthly), we evaluate it honestly: does it solve a problem we actually have? Usually the answer is no. Our clients don't care what framework we use. They care that the product works.
The cost of interesting decisions
Every architectural choice has a maintenance cost. The clever ones cost more.
None of these are bad technologies. They're all excellent — for the right problem. But most products don't have the problems these technologies solve. They have the problems that PostgreSQL, a well-structured API, and a straightforward deployment pipeline already handle perfectly.
When we choose exciting tech
We're not Luddites. Our AI work uses cutting-edge models, vector databases, and agentic workflows. But we're deliberate about where we put the complexity.
The rule: Innovation belongs in the product layer. The infrastructure layer should be boring.
When we build a RAG pipeline, the retrieval logic, embedding strategy, and prompt engineering are novel. The database is Postgres. The API is FastAPI. The deployment is Lambda. The CI/CD is GitHub Actions.
When we build a real-time driver tracking app, the GPS processing and matching algorithms are complex. The backend is Node.js. The database is MySQL. The cloud is standard AWS.
The boring foundation lets us spend our complexity budget on the parts that actually differentiate the product.
How we make the call
For every technology decision, we ask three questions:
The 5-year test
Our longest client engagement is over 5 years. The architecture we chose at the start — Python, Django, PostgreSQL, Redis, AWS — is still the architecture today. It handles 160 million annual shoppers. It's been extended, optimized, and refactored hundreds of times. But the foundation never needed replacing.
Compare that to projects we've inherited from other agencies — built on bleeding-edge stacks that the original team understood but nobody else does. We've spent months just migrating away from abandoned frameworks before we could add a single feature.
Boring architecture is a gift to your future self. And to every engineer who will work on the product after you.
The paradox
The most innovative products we've built run on the most predictable infrastructure. A premium fashion platform serving 160 million shoppers — running on Python, Django, and PostgreSQL. A nationwide EV charging network — running on Node.js and DynamoDB. An employee benefits marketplace with a 4-year engineering partnership — running on Vue.js, Laravel, and MySQL.
The innovation is in what the product does, not in how it's deployed. The architecture is invisible to users. They don't care about your database choice. They care that the product is fast, reliable, and does what it promises.
Boring architecture makes exciting products possible. That's the case, and after 80+ products, we're more convinced than ever.