← Blog · Jun 18, 2026 · Engineering
The stack we use in 2026 (and why)
We don't believe in the "most modern" stack, but in the boring stack that ships: proven technology, with a large community, that a small team can maintain without surprises. These are our default choices for 2026 and, more importantly, when we step away from them. Clear defaults let us start fast and save our decision energy for what's genuinely specific to each project.
Frontend: Next.js (React) by default
For corporate sites, SaaS and MVPs we use Next.js: SSR/SSG/ISR when SEO matters, App Router for apps with sessions, and a huge ecosystem. When a project is a simple landing page or an internal tool with no need for React, we don't force Next.js: plain HTML + CSS + a little JS performs better and loads faster. For very interactive, lightweight UIs we also consider SvelteKit.
Backend: Node/Express or FastAPI, depending
Node + Express/Fastify when front and back share a language and the team iterates fast. Python + FastAPI when data, AI or automation is involved: the scientific and scraping ecosystem is unmatched. The decision is driven by the problem domain, not by fashion.
Data: Postgres almost always
Postgres is our default database: solid relational, JSONB for the flexible bits, built-in full-text search, and pgvector for semantic AI search without standing up another database. We add Redis for cache, queues and rate limiting. We only leave Postgres for a concrete reason (massive time series, graphs, extreme scale), never by default.
Payments, auth and integrations: don't reinvent
- Payments: Stripe (Checkout, Billing, Connect). The Customer Portal saves us building subscription management.
- Auth: managed providers (Clerk, Supabase Auth) or solid libraries; we don't build auth from scratch unless there's a very specific requirement.
- Transactional email: Resend or Postmark, with versioned templates.
- Observability: Sentry for errors, structured logs and basic alerting from day one.
Infrastructure: PaaS first, complexity later
We deploy to a simple PaaS (Railway, Render, Fly.io, Vercel) with managed Postgres and CI/CD on GitHub Actions. This covers 95% of projects and leaves all the time for the product. Kubernetes and multi-region architectures only arrive when volume and requirements justify them, not because they look good on a diagram. For clients with their own VPS we use Docker + Nginx + PM2 with reproducible deploys.
Off the default: when the project decides
- Bots and real-time: Node with the channel's official library (Discord.js, Telegraf), queues and workers; WebSockets/Socket.IO for live overlays.
- Games: Unity for mobile/casual; no forcing the web here.
- Media/AI pipelines: Python with FFmpeg, Puppeteer and AI APIs, orchestrated by queues.
- 3D and experiences: Three.js on Next.js when the brand calls for it.
The rule is simple: defaults to move fast, judgment for the specific. A predictable stack is what lets us deliver on time and keep the software alive after handover.
FAQ
Why Postgres and not NoSQL?
Most products have relational data. Postgres does that excellently, with JSONB for flexibility and pgvector for AI. Starting with NoSQL is usually premature optimization.
Do you always use the same stack?
We have defaults, not dogmas. When a project needs something else (bot, pipeline, game, real-time), we pick the right tool.
Why PaaS and not Kubernetes?
K8s solves problems most projects don't have yet, with heavy operational complexity. A PaaS deploys in minutes and scales for 95% of cases.
Have a project and unsure about the stack?
We choose the right technology for the problem with you and deliver at a fixed price by milestones. No over-engineering.
Related resources
- When Next.js makes sense for a corporate site — the SSR/SSG/ISR detail.
- SaaS multi-tenant backend — patterns and stack for a B2B SaaS.
- LLMs in production — what we build around a model.
Published: June 18, 2026 · Written by the RoviDev studio.