A tech stack for startups, element by element

The table

Which technologies do we build products with?

Fourteen elements in six families: the technologies the group actually uses, in My Web Lab and Giallo Studio projects, in Athleex and on this site. Pick a tile: alongside, you'll see why we use it, when we choose something else and where we've used it.

How to read it

Family at the top, symbol in the middle, name at the bottom. The colour shows the family.

Frontend
Backend and data
Mobile
AI and automation
Infrastructure
Motion and 3D

Next.js

Family: Frontend

Why we use it: One framework for the website, the web app and the API, with fast static pages search engines can read: SEO starts in the code.
When we don't: An internal tool nobody searches for can get by with something simpler; a brochure site updated by non-developers is better on a CMS.
Where we've used it: My Web Lab's custom websites and web apps, the Athleex web app and this site.

React

Family: Frontend

Why we use it: Interfaces built from reusable components, a huge ecosystem and developers who are easy to hire.
When we don't: On pages that are mostly text it's more than you need: there, shipping as little JavaScript as possible matters most.
Where we've used it: Wherever we use Next.js: My Web Lab projects, Athleex, this site.

TypeScript

Family: Frontend

Why we use it: Types from the interface down to the database: many bugs surface while you write the code rather than when a user finds them.
When we don't: For a one-off script or a throwaway experiment.
Where we've used it: Across the group's whole shared stack.

PostgreSQL

Family: Backend and data

Why we use it: A solid, open-source relational database: transactions, constraints, full-text search and extensions, with no vendor lock-in.
When we don't: For caching, or huge volumes of genuinely unstructured data, there are better tools to run alongside it.
Where we've used it: The Athleex database, with nightly backups and an off-site copy.

Prisma

Family: Backend and data

Why we use it: A TypeScript ORM: a readable database schema, typed queries and migrations versioned with the code.
When we don't: For very complex analytical queries we write SQL by hand, next to Prisma.
Where we've used it: The Athleex web app.

Capacitor

Family: Mobile

Why we use it: Turns the same web codebase into real iOS and Android apps with access to native features: one codebase, one team.
When we don't: Games, heavy 3D or very intensive use of native features are better served by a native app or another framework.
Where we've used it: The Athleex iOS and Android apps.

StoreKit 2

Family: Mobile

Why we use it: Apple's framework for in-app purchases: you need it when you sell digital content or features inside an iOS app.
When we don't: When the app sells nothing inside it, or sells physical goods and services.
Where we've used it: Athleex: App Review rejected one version under the in-app purchase rules (guideline 3.1.1); with StoreKit 2 it was approved.

AI agents

Family: AI and automation

Why we use it: Language models connected to tools, with narrow permissions and every step logged: they take on repetitive work that involves reading and writing text.
When we don't: If the process never changes, a workflow is cheaper and more predictable; if a mistake is costly, a person decides.
Where we've used it: Giallo Studio's projects for Italian SMEs.

n8n

Family: AI and automation

Why we use it: A workflow orchestrator: connects apps and APIs with flows you can see, change and audit easily.
When we don't: For the product's core logic, which belongs in the application code with its tests.
Where we've used it: The group's process automation, with Giallo Studio.

Hetzner

Family: Infrastructure

Why we use it: Servers in Europe at predictable cost, which we run ourselves: the data stays in the EU.
When we don't: If nobody on the team wants to run servers, a managed platform costs more but takes work off your plate.
Where we've used it: Hosts Athleex, on European servers we manage.

GitHub Actions

Family: Infrastructure

Why we use it: Automated CI: on every change, tests, type checks and builds run on their own before anything reaches production.
When we don't: A minimal static site only needs its hosting platform's automatic deploys.
Where we've used it: The Athleex CI.

Three.js

Family: Motion and 3D

Why we use it: 3D in the browser with WebGL: scenes, materials and lighting for experiences a still image can't give.
When we don't: Where speed matters more than the scene, or when a rendered image says the same thing.
Where we've used it: The 3D scenes on this site.

GSAP

Family: Motion and 3D

Why we use it: Precise, scroll-linked animation that respects people who prefer less motion on screen.
When we don't: A simple transition only needs CSS.
Where we've used it: The group's shared stack, this site included.

Blender Cycles

Family: Motion and 3D

Why we use it: Photorealistic rendering for images and sequences: believable light and materials without weighing the page down.
When we don't: When you need real-time interaction: that's a job for Three.js.
Where we've used it: The images on this site.

Combinations

What stack for an MVP, a SaaS or an app?

The same elements combine differently depending on what you're building. These are starting points, to be adapted to the project.

Technology combinations by type of product
What you're building	Elements	Why
Web MVP	Next.js React TypeScript PostgreSQL Prisma	One codebase for interface and API, and relational data from day one: quick to change, and nothing to throw away when customers arrive.
SaaS	Next.js TypeScript PostgreSQL Prisma Hetzner GitHub Actions	Subscriptions, roles and many customers' data call for a solid database, CI and infrastructure whose costs you control.
iOS and Android app	Next.js React Capacitor StoreKit 2	The same web codebase becomes a store app; StoreKit 2 comes in if you sell digital content inside the iOS app.
AI features and automation	AI agents n8n TypeScript PostgreSQL	The model works from the backend, repetitive flows run in an orchestrator, and the data stays where you control it.
Launch website	Next.js GSAP Three.js Blender Cycles	Fast static pages search engines can read; motion and 3D only where they help people understand the product.

Square frosted-glass tiles in a grid, some tinted lilac, one raised towards the light

Criteria

How do you choose a startup's tech stack?

Pick mature technologies that plenty of developers know and that don't lock you into one vendor: the stack should get you to launch quickly and let a new team carry on.

People: How many developers know it? A rare stack makes hiring, and switching suppliers, hard.
Maturity: Documentation, regular releases, a community that answers. This month's novelty is paid for in maintenance.
One codebase, many channels: Web, apps and API from the same code: less work and fewer bugs as the product grows.
Running costs: Hosting, database and AI model calls should stay predictable as users grow.
A way out: Code and data must stay yours and portable: no platforms you can't leave.

Need to decide without a technical co-founder? That's what a fractional CTO is for.

Questions about the tech stack

What is the best tech stack for a startup?

There isn't one that suits every startup: what matters is that it's mature, widely known among developers and fits what you're building. For web apps and SaaS a very common combination is TypeScript with Next.js, React and PostgreSQL, which is also our own base.

Is Next.js a good choice for a SaaS?

Yes, for most SaaS products: it keeps the interface, the API and indexable public pages in a single project. We use it for the Athleex web app, our own SaaS. Unusual workloads get dedicated services alongside it.

Why PostgreSQL rather than a NoSQL database?

Because almost every startup product has relational data: users, subscriptions, orders, permissions. PostgreSQL handles them with transactions and constraints, and stores semi-structured JSON too. A NoSQL database joins in when there's a specific need.

Capacitor, React Native or Flutter for a startup's app?

Capacitor makes sense when you already have a web app and want iOS and Android apps on the same codebase with one team: it's what we chose for Athleex. React Native or Flutter make sense when the app is the main product and needs highly polished native interfaces.

Do you always use these technologies?

No: they're a starting point, not a rule. If your project already has a stack that works, or a requirement these technologies don't cover well, we talk it through before writing any code.

Choosing the stack for your product?

We reply within one business day.

Let's talk