What tech stack should an AI startup use in 2026?
Short answer
For most AI startups in 2026 the right stack is a boring one: a TypeScript web front end, a Python API such as FastAPI, hosted models called only through your own backend, PostgreSQL with pgvector for data and retrieval, a queue for slow work, tracing that records tokens and cost, and one cloud region close to your users. Deviate only when a measured constraint such as latency, data residency or cost at volume forces it.
By Dr. Dulan Dias, co-founder and CTO of Tellme AI
Key facts
- PostgreSQL was the most used database in Stack Overflow's 2026 Developer Survey, used by 57.9% of respondents.
- In the same survey Python was used by 58.0% of respondents and TypeScript by 43.8%.
- As of 4 November 2026, Anthropic listed Claude Sonnet 5.5 at $2 per million input tokens and $10 per million output tokens, and its Batch API at a 50% discount on both.
- pgvector is an open-source PostgreSQL extension for vector similarity search that supports HNSW and IVFFlat indexes.
- The OWASP Top 10 for LLM Applications 2025 ranks prompt injection as LLM01 and unbounded consumption as LLM10.
- OpenTelemetry defines semantic conventions for generative AI spans, metrics and events, including provider-specific conventions for Anthropic, AWS Bedrock, Azure AI Inference and OpenAI.
- Tellme AI's production MVP was built on Next.js, FastAPI, MongoDB and AWS, with an admin portal and CI/CD, within 4 to 6 months.
- From Model to Product, Chapter 12, suggests a small team start with one backend, one database and one model.
Definitions
- Tech stack
- The languages, frameworks, managed services and infrastructure a product is built and run on. For an AI product it adds model providers, retrieval, evaluation and cost tracking.
- pgvector
- An open-source PostgreSQL extension that stores embeddings and runs vector similarity search in the same database as the rest of a product's data.
- Model gateway
- A thin layer in your backend that every model call passes through. It holds API keys, applies timeouts, retries and fallbacks, routes requests between models, and logs tokens and cost.
- Observability
- The logs, metrics and traces that show what a system is doing in production. For AI products it includes token usage, cost, latency per model call and quality signals.
The default AI startup stack, layer by layer
These defaults suit a small team shipping a web-based AI product in 2026. Each is chosen because it is widely understood, easy to hire for and cheap to change later, not because it is the newest option.
| Layer | Sensible default | Deviate when |
|---|---|---|
| Front end | TypeScript with a React framework such as Next.js, streaming model output to the page | You need a native mobile app, offline use or models running on the device |
| API and backend | Python with FastAPI, typed request and response schemas, versioned endpoints | The team is fluent in another stack and all the AI work is hosted API calls |
| Models | One hosted provider plus a fallback, called only from the backend | Data control, steady high volume or latency make open-weight or self-hosted models pay |
| Model gateway | Your own small module for keys, timeouts, retries, routing and cost logging | Several teams share models and need central quotas |
| Data and retrieval | PostgreSQL for product data, pgvector for embeddings, object storage for files | Vector volume, query load or filtering needs outgrow one database |
| Background work | A job queue with workers for slow and batch tasks | Long multi-step workflows need durable state, retries and human approval steps |
| Evaluation | A versioned set of real cases scored in CI before each change | Never; only the tooling grows |
| Observability | Structured logs and traces per model call with tokens, cost and latency | Volume makes sampling and a dedicated LLM tracing tool worthwhile |
| Cloud and deployment | Containers on one managed cloud, one region near users, CI/CD from day one | Customers require a specific region, their own cloud or on-premises deployment |
Why a boring stack is the right choice
An AI startup's real risk sits in the product: whether the model's output is good enough, whether users trust it and whether the unit economics work. Every novel infrastructure choice adds a second source of risk unrelated to those questions. Mainstream tools also make hiring easier: in Stack Overflow's 2026 Developer Survey, PostgreSQL was the most used database and Python the most used language after JavaScript, SQL and HTML/CSS.
Chapter 12 of From Model to Product, Building a Complete AI Product, makes the same case for small teams: start with one backend, one database and one model, accept that some decisions are temporary, and keep the system easy to change. Split a component out only when its boundary becomes real, as the AI system reference architecture explains.
Models: rent the capability, own the interface
Start with a hosted model from a major provider. Training or hosting your own model before you have users is a cost with no evidence behind it. As of 4 November 2026, Anthropic listed Claude Sonnet 5.5 at $2 per million input tokens and $10 per million output tokens, with batch requests at half price, so for most early products model fees are small next to salaries.
What you should own is the interface. Call models only from your backend, never from the browser, so keys stay secret and you can add caching, rate limits and a second provider without shipping a new client. Keep prompts in version control and provider-specific code behind one module. Running LLM APIs reliably covers timeouts, retries and fallbacks, and open-weight vs proprietary models covers when self-hosting pays.
Retrieval and storage: start in PostgreSQL
Most AI products need three kinds of storage: product records, files and documents, and embeddings for retrieval. PostgreSQL with pgvector handles the first and third in one database, with transactions, backups and access control your team already understands. Object storage holds files and model artefacts, and a cache such as Redis earns its place once the same lookups or answers repeat.
Move embeddings to a dedicated vector database when measurements say so: collection size, query volume or filtering needs that one database cannot meet. pgvector vs a vector database sets out when to switch. A document database such as MongoDB is a reasonable alternative when records are independent and their shape keeps changing; the trade-off is that joins and relational constraints move into application code.
Orchestration and background work
Write orchestration as plain code first. A retrieval step, a model call and a validation step are a function, not a framework. Frameworks for chains and agents can speed up a prototype, but they also hide prompts, retries and costs behind abstractions you will have to debug in production; adopt one when it removes code you would otherwise maintain, not by default.
Anything slower than a user will wait for belongs on a queue: document ingestion, embedding, batch summaries and evaluation runs. The API accepts the job, a worker does it, and the client polls or is notified. When workflows run for minutes or hours, need retries across steps or pause for human approval, a durable workflow engine starts to pay for itself.
Observability, evaluation and security from day one
Log every model call with the user or tenant, feature, model, input and output tokens, latency, cost, cache hit and outcome. OpenTelemetry publishes semantic conventions for generative AI, so model calls can be traced with the same tools as the rest of the system rather than in a separate silo.
Keep an evaluation set of real cases in the repository and run it in CI whenever a prompt, model or retrieval setting changes; how to evaluate an LLM application covers the method. For security, design against the OWASP Top 10 for LLM Applications 2025: prompt injection is LLM01, and unbounded consumption, the route by which abuse turns into an outage or a large bill, is LLM10. Per-user rate limits and spend caps belong in the first release.
Cloud and deployment
Pick the cloud your team knows, ideally where you have startup credits, and run in one region close to your users; UK and EU customers often ask where their data is stored and processed. Package the backend as a container, deploy through CI/CD from the first week and keep secrets in the platform's secret manager, never in the image.
Kubernetes is rarely needed at the start; a managed container service is enough until several services need independent scaling. Chapter 13 of From Model to Product, Packaging & Deploying AI Systems, covers reproducible environments, versioning model files with the code and safe releases, and the guide to deploying a model with FastAPI and Docker shows the pattern.
From practice: the stack behind Tellme
As founding engineer at Tellme AI, Dr. Dulan Dias built the production MVP end to end within 4 to 6 months: a Next.js front end, a FastAPI backend on MongoDB, an admin portal, CI/CD and AWS infrastructure. It is close to the default above, with a document database in place of PostgreSQL.
The effort that mattered most went where a real constraint demanded it, not into novel infrastructure. Tellme uses computer vision on low-end mobile devices, and optimising that work cut battery drain on those devices by over 50%. Bringing computer vision to the edge describes the approach.
Frequently asked questions
Should an AI startup use Python or TypeScript on the backend?
Python is the safer default when the backend does anything beyond calling a model API, because evaluation, data processing and model libraries are Python-first. TypeScript on the backend is reasonable when the team is fluent in it and all the AI work is hosted API calls, since one language then covers the whole product. Either way, keep model calls behind one module so the choice can change later.
Does an AI MVP need a dedicated vector database?
Usually not. If you already run PostgreSQL, the pgvector extension stores embeddings and runs similarity search next to your other data, with one backup and one access model. Move to a dedicated vector database when measurements show the collection size, query load or filtering needs have outgrown it. Many early products need no embeddings at all, because keyword search or a database query answers the question.
Do we need LangChain or an agent framework to build an AI product?
No. Frameworks for chains and agents are optional tools, not a layer every AI product needs. A retrieval step, a model call and an output check can be a few dozen lines of ordinary code your team can read, test and debug. Adopt a framework when it replaces code you would otherwise write and maintain, and keep prompts, retries and cost logging visible either way.
Which cloud should a UK AI startup use?
The one your team already knows, ideally where you have startup credits, in a region that suits your customers. UK and EU customers often ask where data is stored and processed, including by your model provider, so check both your cloud region and your provider's data processing terms before signing enterprise customers. Switching clouds later is expensive; choosing the right region early is cheap.
How do we avoid lock-in to one model provider?
Put every model call behind one backend module that takes a request and returns a result, so provider-specific code lives in one place. Keep prompts in version control, keep an evaluation set you can run against any model, and wire up a second provider as a fallback early. Switching then becomes a measured decision: run the evaluation set against the alternative and compare quality, latency and cost.
Is Kubernetes necessary for an AI startup?
Not at the start. A managed container service runs a backend and a few workers with far less operational work. Kubernetes starts to pay when several services need independent scaling, GPU workloads need scheduling, or customers require deployment into their own clusters. Until then, the engineering time is better spent on evaluation, monitoring and the product itself.
How can a non-technical founder judge a proposed AI stack?
Ask four questions. Can we hire for it easily? Can we change model provider without rewriting the product? Do we log the cost and quality of every model call? Can one engineer explain how a request flows from the user to the model and back? A proposal built on mainstream tools that answers yes to all four is usually sound; exotic choices need a constraint that justifies them.
Sources
About the author
Dr. Dulan Dias is co-founder and Chief Technology Officer of Tellme AI in Belfast; founder of EchonLabs, grown from 2017 to more than 60 people before its acquisition in 2026; holder of a PhD in AI and data science from Queen’s University Belfast; and the author of From Model to Product.