The AI Startup Tech Stack in 2025
Why Defaults Matter
Every engineering decision has two costs: the cost of making the decision, and the cost of living with it. Good defaults eliminate the first cost without inflating the second.
After building 50+ AI products, we've converged on a default stack that ships fast, scales reasonably, and doesn't paint you into a corner. Here's what it is and why we chose each piece.
Frontend: Next.js + TypeScript
Next.js with the App Router is our default for AI applications because the architecture maps well to how AI products work: some content is static and fast, some content is server-rendered with real-time data, and some interactions require client-side streaming.
TypeScript is non-negotiable. The complexity of AI products — varied API responses, dynamic content types, multiple data sources — makes type safety essential, not optional. Untyped JavaScript codebases for AI products quickly become unmaintainable.
Tailwind CSS for styling. It's fast to write, easy to read, and doesn't require context-switching between files.
Backend: FastAPI or Node/Express
For Python-heavy AI stacks (which often need to import ML libraries directly), FastAPI is excellent: async by default, automatic OpenAPI documentation, Pydantic for validation.
For TypeScript-consistent stacks where the team prefers one language end-to-end, Node with Express or Hono is the choice. Hono in particular is a strong option for edge deployments.
The most important decision at the backend layer is not which framework — it's designing good separation between your application logic and your AI logic. AI calls should be isolated behind clear interfaces so you can swap providers, optimize prompts, and add caching without touching application code.
Database: Postgres + pgvector
Postgres is the most capable relational database available. It handles structured data, JSON, full-text search, and with the pgvector extension, vector similarity search. For most AI applications, you don't need a separate vector database — pgvector is good enough up to tens of millions of vectors.
pgvector gives you semantic search on your data without introducing a new database system to operate. Combine with traditional Postgres indexes for hybrid search (semantic + keyword).
When to add a dedicated vector database: when you have more than 10-50 million vectors, need sub-10ms query latency at scale, or need features pgvector doesn't support (like multi-tenancy at the database level).
AI Layer: Anthropic / OpenAI + Orchestration
Our default model choices: Claude 3.5 Sonnet for reasoning-heavy tasks and long document work, GPT-4o for broad general-purpose tasks with vision requirements, and GPT-4o-mini or Claude 3 Haiku for high-volume, lower-complexity tasks.
We never hard-code a single provider. The model landscape changes too quickly. Abstract your AI calls behind a provider-agnostic interface from day one.
For orchestration of complex AI workflows (RAG pipelines, multi-step agents), LangChain/LangGraph is our default. It has rough edges and the abstraction can be leaky, but it's mature, well-documented, and has a large ecosystem. For simpler use cases (single LLM calls, basic RAG), skip the orchestration framework entirely — it's overhead you don't need.
Infrastructure: Vercel + AWS/GCP
Vercel for the frontend and API routes. It handles deployment, preview environments, and CDN without configuration. For AI applications specifically, Vercel's streaming support for Server-Sent Events is excellent.
For backend services that Vercel can't run (long-running processes, GPU workloads, background jobs), AWS or GCP. AWS has more services and a larger talent pool; GCP has better ML tooling (Vertex AI, Cloud TPU) if you're training your own models.
Container everything from the start with Docker. It eliminates environment inconsistencies and makes the eventual move to production orchestration (ECS, GKE, or similar) straightforward.
Monitoring: LangSmith + Sentry
LangSmith for AI-specific observability: tracing every LLM call, seeing inputs and outputs, measuring latency, comparing evaluations across prompt versions. If you're using LangChain, it's the default integration. If you're not, it still works with any LLM framework.
Sentry for application-level error tracking and performance monitoring. Set it up on day one. The first production incident where you have no error tracking is the last time you make that mistake.
For LLM cost tracking: LangSmith includes this. Alternatively, OpenAI and Anthropic's usage dashboards are sufficient for early-stage products.
Auth: Clerk or Auth.js
Clerk if you want authentication fully managed: user management UI, social auth, magic links, MFA, all handled. It's more expensive than building your own but saves significant engineering time. For most B2B AI products, Clerk's cost is justified.
Auth.js (formerly NextAuth) if you want self-hosted auth that integrates natively with Next.js. More configuration required, but no recurring per-user cost.
Never build custom authentication for an MVP. The security risks are too high and the time investment is too large.
What We Don't Include by Default
Some technologies are popular but we deliberately omit from our default stack:
Microservices: Start with a monolith. Microservices solve organizational scale problems, not technical ones. Most AI products don't need them.
GraphQL: REST with good API design handles most AI product needs. GraphQL adds complexity that's rarely justified in early-stage products.
Redis (as primary cache): Postgres is fast enough for most caching needs. Add Redis when you have a specific problem it solves.
Kubernetes: Managed container services (ECS, Cloud Run) are simpler and sufficient for most products. Add Kubernetes when you have multiple teams deploying independent services.
The Most Important Decision
The choice of stack matters less than you think. The most important decisions are:
- Does the team know and feel productive in this stack?
- Are you following the conventions of the framework (not fighting it)?
- Are you building the right product for the right users?
We've seen great products shipped on bad stacks and bad products shipped on great stacks. The stack is a constraint, not a solution.
Start with our defaults if you have no strong reason not to. Then change what isn't working when you have data showing it isn't working.
