The Humble Stack Manifesto
Right-sized architecture for builders who ship.
Complexity is the enemy of execution.
Modern software culture has confused possibility with necessity. Just because you can deploy 14 microservices doesn’t mean you should. Most products that succeed do so because of focus, not architecture.
The Hyperscaler Tax
The real cost of a hyperscaler isn’t the compute bill. It’s the engineering time absorbed by infrastructure that your product doesn’t need yet. Configuration, debugging IAM policies, deciphering pricing models, migrating between deprecated services. These hours don’t ship features.
Hidden costs calculated as engineering hours spent on infrastructure vs. shipping features.
Meanwhile, a Humble Stack runs on $50/mo and you spend your time building product.
One server is not naive. It’s honest.
A single modern VPS from Hetzner or OVHcloud is absurdly powerful. Most teams dramatically underestimate what one machine can do — because they’ve never tried.
16+
Fast Cores
64GB
RAM
NVMe
Storage
100K+
Concurrent Users
This is enough to run web apps, APIs, background jobs, queues, and AI workloads — scaling vertically long before you need to scale organizationally. PostgreSQL alone on this hardware can handle millions of rows with sub-millisecond query times.
Ship fast. Close the loop. Repeat.
Speed is a feature. The team that ships and learns fastest wins — not the team with the most sophisticated pipeline.
Humble stacks
- CI pipelines are fast and understandable
- Deployments take seconds, not rituals
- Fewer moving parts = fewer failure modes
- Rollbacks are trivial
- Debugging happens in one place
- Local dev mirrors production exactly
Hyperscaler abstractions
- Slower deployments through multi-stage pipelines
- Harder to reason about system behavior
- Longer feedback loops between code and reality
- More ceremony, less shipping
- Local dev is an approximation at best
- “Works on my machine” is structural, not accidental
The fastest feedback loop wins. Everything else is ceremony.
Built for the AI era
AI-augmented development changes what “fast” means. When an AI assistant can generate a feature in minutes, your bottleneck shifts from writing code to deploying and validating it. A humble stack closes that loop in seconds — push, deploy, verify. No staging environment choreography. No cross-service integration dance.
There’s a subtler point: AI tools reason better about simple architectures. When your entire system fits in one mental model — database schema, API layer, business logic, deployment — an AI assistant can hold the full context. Scatter that across 12 microservices with their own repos and deploy pipelines, and you’ve made AI assistance nearly useless.
The humble stack isn’t just compatible with AI-driven development. It’s the architecture that AI-driven development naturally wants.
Security by simplicity
Every service you deploy is an attack surface. Every network boundary between services is a potential misconfiguration. Every shared secret is a credential that can leak. Every dependency is a supply chain risk.
A humble stack has one perimeter to harden, one set of dependencies to audit, one system to patch, one set of logs to review. Your security posture is a function of your surface area.
This isn’t theoretical. The majority of breaches exploit misconfigurations, not zero-days. Fewer moving parts means fewer things to misconfigure.
Operational calm beats architectural vanity
Calm teams ship more. Distributed systems demand distributed expertise: SRE maturity, observability stacks across services, on-call rotations, runbooks for failure modes you’ve never actually seen. This is organizational overhead that compounds.
When your system fits in one person’s head, debugging is straightforward, deployments are boring, and 3 AM pages are rare. That’s not a limitation — it’s a competitive advantage.
Most teams adopt microservices as a status symbol. The teams that ship fastest treat operational simplicity as a first-class requirement.
Who builds like this
This isn’t a fringe position. Some of the most successful products in history were built on architectures far simpler than what most startups deploy on day one.
Stack Overflow
One of the most trafficked sites on earth. Famously ran on ~9 servers for years, serving millions of developers daily.
Basecamp / 37signals
Multi-billion dollar business built by a small team on a handful of servers. Wrote the book — literally — on staying small.
900 million users at the time of acquisition. ~50 engineers. Erlang on FreeBSD. No microservices.
Craigslist
One of the top 20 most visited sites globally for over a decade. Tiny engineering team. Minimal architecture.
Pieter Levels
Nomad List, Remote OK, Photo AI — each running on single servers, generating millions in annual revenue.
Lichess
The world's second-largest chess platform. Open source, running on donated servers. Serves millions of games daily.
These aren’t outliers. They’re evidence that product focus beats infrastructure investment at almost every stage.
European sovereignty is a feature
Infrastructure is political. When your data sits in a US hyperscaler’s European region, it’s still subject to the CLOUD Act — US authorities can compel disclosure regardless of where the server physically sits.
Choosing European providers — Hetzner, OVHcloud, Scaleway — keeps data under EU jurisdiction in practice, not just on paper. It aligns with GDPR, supports a resilient local tech ecosystem, and removes a dependency on companies whose priorities may not align with yours.
Digital independence isn’t nationalism. It’s about control, predictability, and optionality.
Cost efficiency is strategic, not cheap
Low infrastructure cost isn’t about saving money. It’s about buying freedom.
€40–€80 /month for a server that does the job.
When your infrastructure costs two orders of magnitude less, you can self-fund longer before raising, survive revenue dips without cutting team, experiment without budget approval, and keep pricing competitive because your margins aren’t eaten by cloud bills.
Every euro not spent on infrastructure is a euro spent on product, people, or runway.
When to graduate
The humble stack isn’t a religion. It’s a starting position — and for many products, it’s the ending position too.
There are genuine reasons to distribute. But they’re fewer than most people think:
Throughput ceiling
A single machine genuinely can’t handle your load — measured, not projected.
Regulatory geography
Regulations demand that data lives in specific jurisdictions.
Organisational boundaries
Team size requires service boundaries that mirror team structure. Conway’s Law applies whether you want it to or not.
Divergent scaling
Specific subsystems have fundamentally different resource characteristics — e.g., a compute-heavy ML pipeline beside a latency-sensitive API.
The key word is “when reality demands it.” Not when a conference talk recommends it. Not when a vendor’s solution architect suggests it. When your dashboards show you’ve actually hit the ceiling. Most teams never get there. The ones that do will know it unmistakably.
Taste is a technical skill
There is elegance in restraint. A humble stack reflects confidence over insecurity, clarity over abstraction, and craft over cargo-culting.
“Build the simplest thing that can win today. Evolve only when reality — not hype — demands it.”
The Humble Stack is not about being small forever. It’s about staying in control at every stage.
If this resonates with how you think about building software, we should talk.
Get in touch →