StackThe tools we reach for first · and why

We pick boring tools on purpose.

Fuselab is small. The apps we build often outlive the engagement by years. So we pick a default stack of well-understood, well-supported tools — the kind a sensible engineer can pick up two years from now without a séance. Here it is, with the honest reason each one beat its alternatives.

Our default stack

Eight tools. One repeatable build.

These are the defaults — not the rules. If a project genuinely calls for something different we'll say so on the discovery call. But this is where we move fastest and ship safest.

01

Next.js

React framework · App Router · v16

What it is — A React framework that handles routing, server rendering, data fetching and the production build in one place. One repo, one deploy.

What we use it for — The shell of nearly every app we ship — marketing sites, admin dashboards, customer portals, this site included.

Why this over the alternatives — We weighed Remix (now folded back into React Router), SvelteKit (great DX, smaller pool of senior engineers to hand the codebase off to) and a plain Vite + Express split (more moving parts to maintain). Next won on ecosystem size, documentation quality and the fact that Vercel's own product runs on it — when something breaks at the framework level, someone with commit access has usually already filed the bug.

02

TypeScript

Typed JavaScript · v5

What it is — JavaScript with a compile-time type system. Catches a category of bugs before the code ever runs.

What we use it for — Every line we write, front end and back end. No untyped JavaScript files in our repos.

Why this over the alternatives — We tried plain JavaScript with JSDoc annotations on a couple of older projects — the IDE support, refactoring safety and onboarding speed aren't comparable. The cost of TypeScript is a slightly slower first draft. The benefit is that renaming a database column doesn't quietly break a screen nobody opened during testing.

03

Tailwind CSS

Utility-first CSS · v4

What it is — A CSS framework where you compose styles from small utility classes (`flex`, `px-4`, `text-ink`) instead of writing custom stylesheets.

What we use it for — Visual styling on every app we build. Design tokens — colours, spacing, type scale — live in one config file and theme the whole app.

Why this over the alternatives — We've used CSS Modules (verbose, lots of file-jumping), styled-components (runtime cost, dying ecosystem) and vanilla CSS (fine until two engineers touch the same component). Tailwind gives the team a shared vocabulary, kills the “where is this rule defined” hunt, and produces a tiny CSS bundle in production. v4's token system means rebranding a client's app is a config edit, not a refactor.

04

Clerk

Hosted authentication & user management

What it is — Sign-up, sign-in, MFA, sessions, organisations, social login and a polished user-management UI — all behind a few React components.

What we use it for — Every app where someone has to log in. Includes admin tooling for our clients to invite their own staff and manage roles without us in the loop.

Why this over the alternatives — We've shipped Auth0 (excellent, gets expensive quickly past the free tier), NextAuth (free, but a lot of glue code and brittle on major upgrades) and Supabase Auth (fine, but the React DX trails). Clerk's Next.js integration is the best in the category right now, the free tier is generous, and the pricing stays sensible until a client has well over ten thousand monthly active users — by which point they can afford it.

05

Supabase

Managed Postgres · storage · realtime

What it is — A hosted Postgres database with an API layer, file storage, realtime subscriptions and an admin UI sat on top.

What we use it for — The primary database on every app, plus file storage when it suits the project. Standard SQL underneath — nothing exotic.

Why this over the alternatives — Firebase locks you into Google infrastructure and a proprietary query language we'd rather not own. PlanetScale was the obvious MySQL choice until they killed their free tier and we lost trust in the roadmap. Neon is excellent but you have to wire up storage, auth-adjacent tooling and admin separately. Supabase is boring, well-understood Postgres — easy to back up, easy to hire for, and easy to migrate off the day a client outgrows it.

06

Prisma

Type-safe ORM & migrations · v7

What it is — A database client and migration tool that generates TypeScript types from your schema, so the database and the code can never disagree.

What we use it for — All reads, writes and schema changes against Postgres. The schema file is the single source of truth.

Why this over the alternatives — We've used raw SQL (fast to start, slow to maintain on a team), Drizzle (genuinely close — Prisma 7 caught up on performance and we already had the muscle memory) and TypeORM (we don't, any more). Prisma's generated types catch the silent bugs that used to ship to production, and the schema-first migration workflow means a junior engineer can add a column without breaking anyone's day.

07

Railway

PaaS hosting for apps, jobs & databases

What it is — A platform-as-a-service that hosts the app backend, scheduled jobs, workers and (when needed) auxiliary databases — deployed from a git push.

What we use it for — Where the production application runs. Background jobs, scheduled tasks and any worker process we need also live here.

Why this over the alternatives — Heroku invented this category, then got expensive and lethargic after the Salesforce acquisition. Render is fine but the developer experience trails Railway by about a year. Fly.io is brilliant if your project genuinely needs regions and Docker — most don't, and the extra surface area is a tax. Railway's interface is clear enough that a non-technical client can glance at their own logs without us holding their hand, which matters when we hand the keys over.

08

Resend

Transactional email API

What it is — A modern transactional email API for sending system-generated emails — receipts, notifications, password resets, contact form submissions.

What we use it for — The contact form on this site, password reset flows, delivery note emails on adMES, and any other system email a client app needs.

Why this over the alternatives — SendGrid's developer experience rotted slowly and never recovered from the Twilio acquisition. Postmark is excellent and we'd happily use it on a project that justifies the price. Mailgun's dashboard is from a different decade. Resend's API was clearly written by people who'd recently been frustrated by SendGrid's — and it shows. Cheap to start, easy to migrate off if a client ever needs enterprise-grade deliverability reporting.

How we choose

Four rules for a stack you can hand over.

The reasoning behind every entry above. We'd rather be a year late to a shiny tool than a year deep in a rewrite.

Boring beats clever

If a tool needs a blog post to justify it, it's probably not load-bearing yet. We pick the dull, well-documented option and save the cleverness for the product.

Hireable, not heroic

You should be able to hire a contractor in a week if we get hit by a bus. Every choice on this page is in the top three for its category, by job-market size.

Easy to leave

Standard Postgres. Standard React. Standard SMTP-shaped APIs. The day a client outgrows us, we'd rather help them migrate than hold them hostage to a proprietary lock-in. Code lives in GitHub, transferred to your org on handover if agreed.

Paid where it pays

We'll happily pay for a hosted service when the alternative is owning the on-call rotation ourselves. Clerk, Supabase, Railway and Resend all earn their fees.

When we deviate

Stack-agnostic where it actually matters.

The list above is what we default to — not what we insist on. We'll happily build on whatever a client already runs, integrate with whatever's in their existing stack, or pick a different tool entirely if the project genuinely calls for it.

Case · 01

You already have a stack

If your team is on Django, Rails, .NET or anything else with a heartbeat — we’ll build into it rather than start a parallel codebase. The point is to extend what you have, not replace your engineers.

Case · 02

The project has hard constraints

Air-gapped deployments, regulated industries, on-premise hosting, specific certifications. Some of the choices above (Railway, Clerk, Supabase) assume the cloud is fair game. When it isn’t, we’ll swap them out and price accordingly.

Case · 03

You want to own everything yourselves

Some clients prefer to own the auth, the email and the database outright — no third-party SaaS in the critical path. We’ll build it that way, and we’ll be straight that it costs more and ships slower.

Talk to us

Got a stack question? Ask before you commit.

If you're weighing up your own stack and want a second opinion, we're happy to be useful for half an hour without the discovery-call pitch. No strings.