Our Tech Stack in 2026: What We Use and Why

We get asked this a lot

"What do you build with?" It's one of the first questions on every scoping call. And honestly, the answer is less exciting than people expect. We use boring, proven tools. That's the point.

Here's the full breakdown of what we reach for in 2026 and why.

Frontend

**Next.js + React.** This is our default for almost everything. Server-side rendering, static generation, API routes, great developer experience. We've been on Next.js since version 12 and we've watched it mature into something really solid. The App Router took some getting used to, but at this point we're fully bought in.

**Tailwind CSS.** We resisted this one for a while. It looked messy in the markup and we were happy with CSS modules. But once we actually used it on a few projects, the speed improvement was undeniable. We ship UI 2-3x faster with Tailwind than we did before. Every developer on the team can jump into any component and understand the styling immediately.

**Framer Motion** for animations. We used to reach for GSAP or custom CSS animations, but Framer Motion's React integration is just cleaner. It handles layout animations, exit animations, and scroll-triggered effects without fighting the framework.

**TypeScript everywhere.** We stopped writing plain JavaScript for client projects around 2022 and haven't looked back. The upfront cost of types pays for itself tenfold when you're debugging at 9pm or onboarding a new developer to an existing codebase.

Backend

**Node.js** is our primary backend runtime. Most of our projects are JavaScript/TypeScript across the stack, which means one language, one mental model, and easier code sharing between frontend and backend.

**Python** for anything ML-adjacent or data-heavy. Some client projects involve data pipelines, scraping, or integrations with AI APIs where Python's ecosystem is just better.

**PostgreSQL** for the database. Almost always. It's reliable, it scales, it has excellent tooling, and we know it inside and out. We've used MongoDB on a few projects and regretted it every time. Relational data wants a relational database.

**Prisma** as our ORM. We went through a Knex phase, a raw SQL phase, and a Drizzle phase. Prisma won for us because the schema file is incredibly readable, migrations are painless, and the type generation means our database queries are fully typed end-to-end.

Infrastructure

**Vercel** for most frontend deployments. The DX is unmatched — push to main, it's live in 30 seconds. Preview deployments for every PR. We've tried self-hosting Next.js on AWS and it's fine, but Vercel just removes friction.

**AWS** for anything more complex. When a project needs custom infrastructure — background workers, message queues, specialized databases, file processing pipelines — we're on AWS. Usually a combination of ECS, RDS, S3, SQS, and CloudFront.

**Vercel or Railway** for smaller projects. Not everything needs a full AWS setup. For simpler apps, managed platforms save us (and the client) money on ongoing infrastructure management.

What we stopped using

**MongoDB.** We used it early on because "it's flexible." Turns out, flexibility without structure just means you end up with a mess of inconsistent documents. Schema-less sounds appealing until you're debugging why half your user documents have a "name" field and the other half have "fullName."

**Create React App.** Dead technology. Next.js replaced it for us years ago.

**Heroku.** The pricing got weird and the DX fell behind. Railway does everything Heroku did, better and cheaper.

**Styled Components / CSS-in-JS.** The runtime cost wasn't worth it, and Tailwind solved the same problems without the overhead.

How we choose technology for client projects

We default to our standard stack unless there's a specific reason not to. The bar for introducing something new into a client project is high: it needs to solve a problem our current tools can't, and we need to have at least one team member with production experience using it.

The worst thing we can do is experiment on a client's dime. New frameworks introduce new bugs, new learning curves, and new unknowns. Our clients are paying us to build a reliable product, not to pad our resumes.

When a client comes to us with an existing codebase in a different stack — Django, Rails, Laravel, whatever — we'll work with it. We're not going to tell you to rewrite your entire app in Next.js just because it's what we prefer. We meet you where you are.

The honest truth about tech stacks

Your tech stack matters way less than people think it does. A well-built Rails app will outperform a poorly built Next.js app every time. What matters is that the team knows the tools, the architecture is sound, and the code is maintainable.

We've seen startups fail because they spent months debating frameworks instead of shipping. And we've seen startups succeed on tech stacks that would make Hacker News cringe.

Pick boring tools, write clean code, ship fast. That's the whole playbook.