Boring choices win in SaaS. I have sat in too many rooms where a smart team picked the sexy choice and paid for it for two years. Here is the pattern.
What scaled
Source: Anonymised customer metrics
One client's database went from 200K rows to 50M rows over 36 months. On a single Postgres instance, $50/month tier on Neon, with appropriate indexes[1]. No sharding required, no exotic tooling, no "we need a graph database now."
A boring single-Postgres can comfortably scale to 100-200M rows for most SaaS workloads. Index well and trim cold data on schedule.
The boring vs sexy table
| Spec | Choice | Result |
|---|---|---|
| Postgres on managed host | Boring | Scaled to 50M rows fine |
| Custom multi-region SQL layer | Sexy | Burned 3 months, abandoned |
| Background jobs via BullMQ | Boring | Reliable, low ops |
| Custom job queue on Postgres | Boring | Also fine, even simpler |
| Microservices day 1 | Sexy | Caused 3 months of debugging |
| Monolith → split when needed | Boring | Still a monolith at year 3 |
| Server-side React (Next.js) | Boring | Fine |
| GraphQL "for flexibility" | Sexy | Removed by month 6 |
| REST + JSON | Boring | Still in use |
| Stripe billing | Boring | Worked |
| Custom billing engine | Sexy | Two clients regretted |
Pattern: every "sexy" choice cost months of engineering and was either abandoned or significantly walked back.
What I would build today
For a fresh SaaS in 2026:
- Next.js monolith on Vercel
- Postgres on Supabase or Neon
- BullMQ on Redis (Upstash) for jobs
- Stripe for billing
- Resend for email
- Vercel KV for short-lived cache
- Loops/Buttondown for marketing email
- Cloudflare R2 for object storage
Total monthly cost at 1k MAU: roughly £80-150.
Total time to first revenue from clean slate: 4-8 weeks for one engineer.
Add complexity only when a specific bottleneck demands it. Most SaaS products never reach a bottleneck that requires the sexy choice.
When to break the rules
If your unique value is a specific scaling property (low latency, multi-tenant isolation, geo replication), then pick the architecture that delivers that property even if it is not boring. The point is "do not pick complexity by default;" some products genuinely need it.
For 90 percent of SaaS, the boring stack ships faster, costs less, and breaks less. Pick it.
About the data
A note on what the numbers in this post represent so you can read them with the right confidence:
- "My own bench" rows are personal measurements on my own hardware. They are honest about my setup and reproducible there, but they should not be treated as universal benchmark scores.
- Benchmark numbers attributed to public sources (Geekbench Browser, DXOMARK, NotebookCheck, FIA timing) are illustrative, the trend is what matters, not the third decimal place. Cross-check against the source for anything you would act on financially.
- Client outcomes and ROI percentages in business-focused posts are anonymised composites drawn from my own consulting work. Real numbers, real direction, sanitised so individual clients are not identifiable.
- Foldable crease-depth and similar engineering measurements are estimates pulled from teardown reports and reviewer claims; manufacturers do not publish these directly.
- Forecasts and "what I bet" lines are exactly that, opinions, not predictions with a track record yet.
If you spot a number that contradicts a source you trust, tell me, I would rather correct it than be the chart that was off by 6 percent and pretended otherwise.