New blogMaking an AI Agent You Can Trust With Money

★ AI chatbot · stack

Best Tech Stack for an AI chatbot MVP

My opinionated stack for an AI chatbot MVP, layer by layer, with why I'd pick each tool and what would change my mind. Adjust the answers to fit your team.

  • Runs in your browser
  • No signup
1What are you building?

Used for the cost estimate link below. The stack itself comes from your answers.

2Who's building it?
3Where does it run?
4What does it need?
5Any regulated data?
6How big in year one?
7How tight is the budget?

Your stack

Tech stack for AI chatbot

9 layers, picked for your answers. Boring where it should be, so your effort goes into the product.

Cost this out →
  • AI features: log every prompt and response, keep an eval set, and cap spend per user from day one.
  • Frontend

    Next.js (React + TypeScript)

    Server rendering for SEO, file-based routing and the biggest React ecosystem. TypeScript end to end catches whole classes of bugs before users do.

    What would change my mind
    A purely internal tool with no SEO needs, where a plain Vite + React single-page app is simpler.
    Alternative
    Vite + React SPA, or Remix / React Router
  • Backend / API

    Next.js route handlers + server actions

    No separate service to deploy: the API lives next to the UI and shares types with it. Plenty for an MVP and well beyond.

    What would change my mind
    Several clients (mobile, partners) hitting the API, long-running work, or a separate backend team.
    Alternative
    A standalone Node.js + Fastify service
  • Database

    PostgreSQL (managed: Neon or AWS RDS)

    Relational, transactional and boring. JSON columns cover the semi-structured bits, and pgvector covers embeddings if you add AI.

    What would change my mind
    Truly schemaless, write-heavy event data at very high volume. Add a specialised store for that slice only.
    Alternative
    MySQL, or MongoDB for document-shaped data
  • Auth

    Clerk

    Prebuilt sign-in UI, organisations, roles and MFA. Hours instead of weeks for a B2B-ready login.

    What would change my mind
    Per-user pricing at consumer scale, or a hard requirement to keep auth in-house.
    Alternative
    Auth.js (NextAuth)
  • Hosting

    Vercel

    Git push to deploy, preview URLs for every branch and no servers to manage, which is exactly what an MVP team needs.

    What would change my mind
    Long-running processes, heavy compute or strict data-residency requirements.
    Alternative
    Netlify, or Railway for a container
  • AI layer

    Vercel AI SDK behind your own wrapper + pgvector

    One thin internal interface over the model API, so you can switch or route models as prices change. Embeddings live in pgvector, inside the Postgres you already run.

    What would change my mind
    Tens of millions of vectors or heavy filtering, which is when a dedicated vector database earns its keep.
    Alternative
    A dedicated vector database (Qdrant, Pinecone)
  • Background jobs

    Inngest or Trigger.dev

    Durable background functions with retries, schedules and a dashboard, written in the same TypeScript codebase.

    What would change my mind
    Very high throughput or strict data residency, which points to a queue in your own cloud.
    Alternative
    BullMQ + Redis
  • Analytics

    PostHog

    Product analytics, funnels, session replay and feature flags in one tool, with a generous free tier.

    What would change my mind
    A marketing-only site, where a simple privacy-friendly counter like Plausible is enough.
    Alternative
    Plausible (simple), or Mixpanel
  • Email

    Resend

    Reliable transactional email with a clean API and good deliverability defaults.

    What would change my mind
    Marketing campaigns and newsletters, which belong in a separate tool.
    Alternative
    Postmark

This is the stack I'd pick.

Want me to build on it? I ship MVPs on exactly this kind of stack.

Start with a scoping call
01

What makes an AI chatbot different

An AI chatbot is mostly a retrieval and evaluation problem. The model is a dependency you rent; the quality comes from what you feed it, how you chunk your data and whether you can measure answers before and after every change.

02

Risks to plan for

No evals

Without a fixed set of questions and expected answers, every prompt tweak is a guess. Build the eval set first.

Messy source data

Scanned PDFs, tables and stale pages cause most bad answers. Budget time for ingestion and cleanup.

Runaway token cost

Long contexts on every request add up. Cache, trim and route easy questions to cheaper models.

03

The stack at a glance

With the preset answers for an AI chatbot (you can change them above), this is the stack layer by layer.

Recommended stack by layer
LayerPickAlternative
FrontendNext.js (React + TypeScript)Vite + React SPA, or Remix / React Router
Backend / APINext.js route handlers + server actionsA standalone Node.js + Fastify service
DatabasePostgreSQL (managed: Neon or AWS RDS)MySQL, or MongoDB for document-shaped data
AuthClerkAuth.js (NextAuth)
HostingVercelNetlify, or Railway for a container
AI layerVercel AI SDK behind your own wrapper + pgvectorA dedicated vector database (Qdrant, Pinecone)
Background jobsInngest or Trigger.devBullMQ + Redis
AnalyticsPostHogPlausible (simple), or Mixpanel
EmailResendPostmark

Want the price tag too? Run the same product through the AI chatbot cost estimate.

04

Questions founders actually ask

Do I need a vector database for a chatbot?
Usually not at first. pgvector inside the Postgres you already run handles embeddings for most MVPs, with one less system to operate.
Python or TypeScript for an AI chatbot?
Either works. TypeScript keeps one language across the stack. Python makes sense if your team already lives in the ML ecosystem or needs heavier data processing.
Should I fine-tune a model?
Not for an MVP. Retrieval over your documents plus a well-tested prompt is cheaper, faster to change and easier to debug.
Why does the picker recommend boring technology?
Because an MVP's job is to find out whether people want the product. Mature, widely used tools have answers on the first page of search results, easy hiring and few surprises, so your risk stays in the product rather than the infrastructure.
Is this stack good enough to scale?
For the vast majority of startups, yes. Postgres, a mainstream framework and managed hosting carry companies a long way. When something does need to change, it's usually one layer at a time, and the picker shows what would trigger that change.
05

Stack by product type

06

More from the workbench

Fine print

Tools: on the house.
Engineer: by the hour.

The opinion was free. The implementation is where I come in.

I'm Himanshu, an AI and full-stack engineer. I build MVPs, AI agents and the growth plumbing around them for early-stage startups.