Skip to content
All posts

The Stack We Use and Why

ctrl.alt.elite team··4 min read
engineeringstrategybehind-the-scenes

Founders sometimes ask what technologies we use. Usually because they've been told by a previous developer that their project needs some specific framework or language, and they want a second opinion.

Our answer is boring on purpose. We use a small, proven stack and we use it on nearly everything. Here's what it is and why.

Next.js

Next.js is our default framework. It handles server-side rendering, static site generation, API routes, and file-based routing out of the box. One framework covers what used to require three or four separate tools.

Why not something else?

We've used plenty of alternatives over the years - plain React with Express, Gatsby, Nuxt, SvelteKit. They all work. But Next.js hits the best balance of flexibility, ecosystem, and deployment simplicity for the projects we take on.

For a founder who needs a marketing site, a web app, and an API, Next.js handles all three in one codebase. That means fewer moving parts, faster development, and easier handoff.

Tailwind CSS

Tailwind is utility-first CSS. Instead of writing custom stylesheets, you compose styles directly in your markup. It sounds messy until you try it - then you never go back.

The case for Tailwind

  • Speed - styling is inline with the component, so you're not jumping between files
  • Consistency - the design system is baked into the utility classes (spacing, colours, typography all follow a scale)
  • No dead CSS - only the utilities you use end up in the final bundle
  • Easy to hand off - any developer who knows Tailwind can read and modify the code immediately

The objection

"But the HTML looks messy." It does if you're used to seeing clean class names. But we'll take readable, self-documenting markup over a stylesheet with 200 orphaned classes any day.

Vercel

Vercel is where we deploy. It's the company behind Next.js, so the integration is seamless - push to GitHub, get a production deployment in under a minute.

What makes it worth it

  • Preview deployments - every pull request gets its own URL, so clients can review changes before they go live
  • Edge network - sites are served from the closest data centre to the user
  • Zero configuration - no Docker files, no CI pipelines, no server management
  • Analytics - built-in performance and usage tracking

For the projects we build - marketing sites, SaaS platforms, e-commerce - Vercel handles the infrastructure so we can focus on the product.

Stripe

For anything involving payments - subscriptions, one-time purchases, invoicing - we use Stripe. It's the standard for a reason.

Why Stripe over alternatives

  • Developer experience - the API is well-documented and predictable
  • Subscription management - billing cycles, prorations, upgrades, cancellations all handled
  • Global payments - currencies, tax calculation, and compliance built in
  • Checkout and customer portal - pre-built UI for common flows, saving weeks of development

We've used PayPal, Square, and various payment gateways. Stripe wins on developer experience by a wide margin.

PostgreSQL

When a project needs a database, it's PostgreSQL. Reliable, performant, well-supported by every hosting provider. We typically run it on Supabase or Neon for managed hosting with connection pooling.

We avoid NoSQL unless there's a specific reason for it. For the applications we build - user accounts, orders, subscriptions, content - relational data modelling is the right fit.

What we don't use

Equally important is what we leave out:

  • No heavyweight state management - React Server Components and URL state handle most cases
  • No CSS-in-JS - Tailwind replaces it with better performance
  • No monorepo tooling - our projects are single applications, not platform ecosystems
  • No microservices - a monolith deployed to Vercel scales further than most startups will ever need

The philosophy

We optimise for three things: speed of development, ease of handoff, and long-term maintainability. Every tool in the stack earns its place by being the simplest option that solves the problem well.

Founders don't need cutting-edge architecture. They need a product that works, ships fast, and can be maintained by any competent developer after we hand it over. That's what this stack delivers.