The Tech Stack Behind Novemind — What We Use and Why

People sometimes ask me what stack we use at Novemind. It's a fair question — the tools a team picks usually say something about how they think.

But the honest answer is it depends on the project. We're not married to a single stack, and I'd be suspicious of any agency that is. What I can share is the toolkit we reach for most often, and the principles that guide the choices.

Frontend

Most of our web work is React with Next.js, on the App Router. This site you're reading is built on that exact stack — server-rendered for SEO, MDX for the blog, image optimization out of the box.

For styling, we use Sass for older codebases, Tailwind CSS for newer ones. TypeScript wherever the project will live longer than six months.

When the project is content-heavy (marketing sites, documentation, blog-driven), Next.js is hard to beat. When it's a SaaS dashboard, we'll often pair it with TanStack Query for data fetching and shadcn/ui for components.

For mobile, React Native when cross-platform matters and the app isn't pushing the OS to its limits. Native Swift / Kotlin when it does.

Backend

The backend choice depends on the workload, the team that has to maintain it, and the constraints of the project:

• Node.js for typical API servers, real-time features, and anything closely tied to the frontend
• NestJS when a Node service grows beyond a handful of routes and benefits from opinionated structure, DI, and TypeScript-first conventions out of the box
• Laravel for projects where the client team is PHP-fluent or the domain (admin panels, CMS-heavy products, e-commerce backends) maps cleanly onto its conventions. The ecosystem is mature and the productivity is genuinely hard to beat
• Python for AI workloads, data pipelines, and ML-heavy services
• Go for high-throughput services, networking-heavy workloads, and CLIs — anywhere the deployment story (a single static binary) and concurrency model actually earn their keep
• PostgreSQL as the default database, full stop. Boring, fast, mature, handles 95% of what people reach for "exotic" databases for
• Redis for caching, session storage, and rate limiting
• pgvector for embedding storage when AI features are involved (we'd rather use Postgres than add a separate vector database for most projects)

The language choice often follows the team more than the technical requirements. A Laravel app maintained by a team that already knows Laravel will outship a "more modern" Node rewrite that no one on the client side can confidently touch.

We rarely reach for microservices early. A well-structured monolith on Postgres can take a startup very far before infrastructure complexity actually pays off.

AI / LLM stack

This is the area moving fastest, and we try to stay pragmatic:

• OpenAI and Anthropic APIs for most production workloads
• Local / open-weight models when data sensitivity, cost, or latency demand it
• LangGraph or direct SDK calls — depends on whether we need orchestration or just inference. We default to less framework, not more
• pgvector or Pinecone for vector storage, depending on scale

The principle here: AI components should slot into a normal application architecture, not become the architecture themselves. Agents are tools, not magic.

Infrastructure and DevOps

• Vercel for Next.js apps and marketing sites — the developer experience is hard to beat for this category
• AWS or Hetzner for backend services, depending on budget and compliance requirements
• Docker for containerization, GitHub Actions for CI/CD
• Cloudflare for DNS, edge caching, and basic security

We avoid infrastructure complexity until the application actually needs it. A Vercel deploy and a managed Postgres on Render is a perfectly good production setup for most projects under 100k users a month.

The principle: boring where boring is enough

Underneath all of this is a single bias: we pick boring tools for the parts that aren't differentiated, and modern tools where modernity actually pays for itself.

Authentication? Use a battle-tested library, don't roll your own. Database? Postgres. Hosting? Whatever has the best operational track record. Background jobs? Boring queues that have existed for a decade.

The exciting tooling decisions get reserved for the parts of the system that are uniquely your business — the workflows that differentiate you, the AI integrations that make your product feel different, the UX that earns customer love.

What we don't do

• No "rewrite it in [trendy language]" projects. If your existing stack works, the answer is rarely to rewrite it.
• No serverless for serverless's sake. It's a great fit for some workloads. It's a footgun for others.
• No microservices until the team size demands them. A clean monolith ships faster.
• No premature scaling. We design systems to handle 10x today's traffic, not 1000x. The latter is almost always a waste of budget.

The takeaway

Tech stacks are means, not ends. The real skill is matching the tools to the project's actual constraints — budget, timeline, team, scale, compliance — and resisting the temptation to optimize for things that don't matter yet.

If you ever want to chat about a specific stack decision, that's actually one of my favorite conversations to have. There's almost always a simpler answer than what people initially propose. You can see the kinds of projects we take on over at Novemind.