Skip to content
Start a Project

Chosen for the
problem,
not the résumé.

What we use, why we use it, and where each choice fits. From the interface to the infrastructure, the stack should suit your product - not the other way around.

Explore the stack

Web products

Next.js · React

Mobile apps

Flutter · native

APIs & services

Node.js · Python

AI, where it fits

Grounded. Evaluated.

A considered data layer

PostgreSQL · Redis
Deploy. Observe. Improve.Cloud & DevOps
Illustrative system - not a client deployment or a fixed stack.

The stack, and the reasons.

Six technology families. Explore our picks, the reasoning behind them, and where they are appropriate.

Choose a technology family

Frontend

Why these choices
Server rendering for content speed and search, client interactivity where it earns its JavaScript. One framework covers marketing sites and full applications.
Where they fit
Most web products. A pure SPA is chosen only for app-like, login-first products behind no SEO need.

Our picks

  • Next.js
  • React
  • TypeScript
  • Tailwind CSS

Mobile

Why these choices
Cross-platform for most products, native when hardware, platform APIs or polish demand it. The choice follows the product, not our comfort.
Where they fit
Two-platform products with standard UI patterns. Camera-first, OS-deep or performance-critical apps go native.

Our picks

  • Flutter
  • React Native
  • Swift
  • Kotlin

Backend

Why these choices
Typed end-to-end with the frontend; Python where the data and AI ecosystem lives. Boring, observable services over clever frameworks.
Where they fit
APIs, integrations and product services. CPU-heavy analysis moves to Python where the libraries are.

Our picks

  • Node.js
  • TypeScript
  • Python

Data

Why these choices
PostgreSQL handles relational work, JSON and search well enough for most products; Redis for caches and queues where needed.
Where they fit
Default choice. Document stores and specialised search engines earn their place at real scale, not at whiteboard scale.

Our picks

  • PostgreSQL
  • Prisma
  • Redis

AI

Why these choices
Models are components behind grounded retrieval, guardrails and evaluation. Choice of model is a cost and latency decision per task.
Where they fit
Anywhere answers must be grounded in your data. Deterministic workflows stay deterministic.

Our picks

  • LLM APIs
  • RAG pipelines
  • evaluation harnesses

Cloud & DevOps

Why these choices
Automated pipelines, preview environments and monitoring from day one. Infrastructure as reviewed code, not clicked consoles.
Where they fit
Every production system we operate.

Our picks

  • Managed cloud
  • containers
  • CI/CD
  • monitoring

The starting point is your product, your existing systems and the team that will maintain them - not a mandatory stack.

Architecture that earns
its complexity.

How we think about architecture. Concepts used where they belong, with the reasoning kept visible.

Modular first, distributed when justified
Microservices are not automatically better architecture. For many products a well structured modular application is easier to operate and maintain. We introduce distributed systems when scale, team structure or technical requirements justify the additional complexity.
API-first, always
Every system we build exposes its capability through typed APIs, even when only one frontend consumes them today. The second consumer arrives eventually; API-first costs little now and saves a rewrite later.
Events where they belong
Queues and event streams for anything that must survive spikes or retry: emails, syncs, exports, notifications. Synchronous coupling is reserved for interactions that genuinely need an immediate answer.
Caching as a decision
Cache layers are added per measured problem with explicit invalidation, never as default decoration. An unmeasured cache is a future incident.
Multi-tenancy decided early
Whether a SaaS isolates tenants by column, schema or database is expensive to change later. We decide it from the compliance and scale requirements at the start.
Migrations as projects
Data migrations are planned, rehearsed and reversible. Strangler patterns replace legacy systems piece by piece while they keep serving users.

Want this reasoning applied to your system? Explore the work or see how agents and platforms are engineered.

Technology, asked
and answered.

Practical answers about stack choices, existing systems, AI and the trade-offs worth considering.

Ask another question
How do you choose the technology stack for a project?

By the problem: content speed and search point to server-rendered web, hardware depth points native, scale and team shape decide architecture. Every major choice is written down with its rejected alternatives.

Can you work with our existing technology stack?

Yes. We take over existing codebases and extend current stacks after a structured audit, and we document everything we touch so your team stays in control.

Do you modernize legacy applications?

Yes, strangler-style: the new system replaces the old piece by piece while it keeps serving users, with rehearsed data migration and rollback paths at every step.

Which AI technologies do you use in production?

LLM APIs behind grounded retrieval, RAG pipelines, tool-calling agents with permission scopes, and evaluation harnesses. Model choice is a cost and latency decision per task, abstracted so providers can swap.

Do you recommend microservices for every project?

No. For many products a well-structured modular monolith is easier to operate and maintain. Distributed systems are introduced when scale, team structure or requirements justify the complexity.

Which is better: React or Angular?

Both are mature; the choice is organizational. React's ecosystem and Next.js win when content speed, search and product flexibility matter, which is most products. Angular suits large teams that want one prescribed, batteries-included framework. We work in React's ecosystem and will tell you when that is the wrong answer.

Is Python or Node.js better for backend development?

Node.js gives one language and one type system across the whole product, which keeps web teams fast. Python owns the data and AI ecosystem: pipelines, models and analysis live there naturally. We run both and decide per workload, not per preference.

Is WordPress or a custom-built website better?

WordPress is right when a standard content site is genuinely all you need; it is fast to launch and cheap to run. A custom build pays for itself when search performance, custom workflows, portals or integrations are the product. We build both and say which one fits your case.

What is the best technology stack for a startup or SaaS in 2026?

The boring, proven one: TypeScript with Next.js on the front, Node.js services behind, PostgreSQL underneath, managed cloud to run it. Startups die of novelty, not of Postgres. Introduce specialized technology when scale or product reality demands it, with evidence.

Which database should we choose: SQL or NoSQL?

Start relational. PostgreSQL covers relational work, JSON documents, full-text search and scale further than most products ever need. Purpose-built stores earn their place for specific workloads, time-series, caching, high-volume telemetry, not as a default. We published a full comparison on Insights.

Is Flutter still a good choice for app development in 2026?

Yes for most two-platform products: one codebase, near-native quality, strong tooling. Go fully native when the app is camera-first, platform-deep or performance-critical. Our decision framework, including when we talk clients out of Flutter, is published on Insights.

Have a stack decision you are unsure about?

Bring the problem, your current stack or the decision you are weighing up. Let's look at the trade-offs before you commit.

Ask Savo

Savo Assistant · instant answers