Which model does Zheat use: ChatGPT, Claude, Gemini, or Bedrock?

Zheat ships against the API of ChatGPT, Claude, Gemini, or AWS Bedrock, chosen per project. We prototype on the same API we put in production. Bedrock is the usual pick when the workload already lives on AWS or the model must run in the client's cloud account.

Do I need LangChain to go from prototype to production?

No. Zheat uses LangChain and LangGraph when the product has to call tools in sequence, keep state, and fail in a way we can log and replay. A single retrieval-plus-answer path is often a thin Python service. LangChain is for workflows other systems have to trust.

Can Zheat work with the tools we already use?

Yes. Production work is usually Python and React or React Native on AWS, connected to the client's existing systems with MCP, RAG on their data, and n8n when operations already live in SaaS tools. We do not require you to throw away the stack you have.

Do we own the code and infrastructure at the end?

Yes. Zheat does not keep the product on a Zheat platform. You get the code, the AWS CDK definitions, and a handover. There is no long-term consulting lock-in. 60-day guarantee: bug fixes after launch, money back if we miss the agreed scope.

Expertise

The tools Zheat uses to ship AI products to production

LangChain, Python, React, React Native, AWS, RAG, MCP, and the rest of the stack Zheat uses to turn an AI prototype into a production-ready product.

Zheat puts AI in production and keeps it there. A prototype that works in a demo is not a product. We turn it into something real users can use, then stay on for drift, hallucination, and stale models.

This page is the public record of the tools we actually build with, why each one is in the stack, and when we leave it out. We do not sell a platform. We do not lock you into a long-term consulting contract. The code and infrastructure sit on your side.

Who this stack is for

This stack is for companies that already have an AI prototype, or a clear AI product idea, and do not have an in-house engineering team to take it to launch.

Typical starting points:

A ChatGPT, Claude, or Gemini prototype that works in a demo and fails with real users
An internal chatbot that needs to talk to existing business tools
A React or React Native app that needs an AI backend behind it
An AWS account with no production-ready architecture yet

If you need a staffing marketplace, a no-code toy, or a multi-year consulting retainer, this is not that.

How Zheat chooses tools

Zheat picks tools for production constraints, not for a slide. The questions we ask before adding anything to a project:

Can it run against the APIs we will actually ship, not only against ChatGPT in a browser?
Can we observe quality, latency, and cost once users show up?
Can it connect to the client's existing systems without a rewrite?
Can the client keep it after we leave?

If a tool fails those tests, we do not use it, even if it is fashionable.

Layer	Tools we ship with	Job in production
Models	ChatGPT, Claude, Gemini, AWS Bedrock	Generate answers and run agents against the API we will ship
Backend	Python, FastAPI	APIs, RAG pipelines, agent backends, AWS CDK
Agents	LangChain, LangGraph	Multi-step workflows that call tools, not one-shot prompts
Retrieval	RAG on the client's data	Ground answers in documents and catalogs the business already owns
Tool access	MCP (Model Context Protocol)	Let the model use existing business systems
Web	React, TypeScript	Product UI that real users can operate
Mobile	React Native	iOS and Android from one codebase
Cloud	AWS, serverless, CDK	Host, scale, and deploy without a long ops tail
Content	Contentful, Storyblok	Headless CMS when the product has editorial content
Automation	n8n	Connect apps and internal processes without a custom bus

Large language models: ChatGPT, Claude, Gemini, and AWS Bedrock

A large language model is the component that generates answers, drafts, and tool calls. Zheat ships against the API of ChatGPT, Claude, Gemini, or AWS Bedrock, not against a chat window.

We prototype on the same API we will put in production. A prototype that only works in ChatGPT's UI is not a product. The API has different latency, cost, rate limits, and failure modes.

When we use Bedrock: the workload already lives on AWS, or the client needs models hosted in their cloud account.

When we mix models: one model for cheap classification, another for harder generation, with routing so the bill stays predictable as usage grows.

Zheat has shipped a multi-model internal assistant for BPI France (Alfred.ia) using GPT-4o, Claude, and other models behind one product surface.

Python backends

Python is the language Zheat uses for most backend work, machine learning glue, and AWS infrastructure as code.

We have built startup applications, content systems, mobile-app backends, chatbots, and agent backends in Python since 2014. New work typically uses FastAPI for HTTP APIs and AWS CDK in Python for infrastructure. We still deliver Django when it is the right fit for an existing codebase.

Python is where RAG pipelines, LangChain graphs, evaluation harnesses, and cost controls live. The model is a dependency. The product is the Python service around it.

More on this layer: Senior Python developers for AI, data, and AWS.

LangChain and LangGraph

LangChain is a framework for composing LLM calls, tools, memory, and retrieval into an application. LangGraph is the piece we use when the workflow is a graph: branch, retry, wait for a human, call another tool.

Zheat uses LangChain to build agents: software that can take a user goal, call tools, and come back with a result, instead of a single prompt-in, text-out chat.

We do not use LangChain because it is trendy. We use it when the product has to:

Call more than one tool in a sequence
Keep state across steps
Fail in a way we can log, test, and replay

If the job is one retrieval and one answer, a thin Python service is enough. LangChain earns its place when the prototype has to become a workflow that other systems can trust.

Retrieval-augmented generation (RAG)

Retrieval-augmented generation (RAG) is a pattern that fetches relevant pieces of the client's own data and passes them to the model before it answers. The model is not guessing from training data alone. It is answering from the documents, catalog, or knowledge base the business already has.

RAG is the usual fix when a prototype "sounds smart" and then invents product names, prices, or policies.

Zheat builds RAG that has to stay accurate as the corpus grows. That means chunking, retrieval evaluation, and a path to replace a bad source without redeploying folklore. We have written publicly about when RAG is the wrong tool, including messy implant catalogs and wrappers that are not a RAG product. See Is RAG right for a messy implant catalog? and mcp-raganything is not a RAG product.

Model Context Protocol (MCP)

Model Context Protocol (MCP) is an open protocol for connecting a language model to tools and data sources. In production it means the assistant can use the systems the business already runs, instead of living in a chat silo.

Zheat uses MCP to connect LLMs to internal APIs, documentation, and business tools. We have shipped MCP servers, visual MCP builders, and agent-ready integrations. Meet Mila and MCP Factory are examples of productized MCP work, not slideware.

MCP is the right layer when the blocker is "the prototype cannot see our CRM, catalog, or tickets." It is the wrong layer when the blocker is still "the model makes things up" — that is a RAG and evaluation problem first.

React and TypeScript

React is the library Zheat uses for most web product UI. We write it in TypeScript.

The AI backend is useless if the user cannot complete the job in the interface. React is where we put the product: the screens, the auth, the states for slow model calls, and the fallbacks when the model is wrong or down.

Most Zheat frontends are React. We do not pick a new framework per project. Production means a stack the client's team can hire for and keep.

React Native

React Native is how Zheat ships iOS and Android from one codebase. We use it for customer portals, retail apps, and other production mobile work.

If the prototype is a web demo and the real users are on phones, React Native is usually the shortest path to a store-ready app without two native teams.

Shipped examples on this site include MyIsuzu and MECCA, delivered with partners, on the same React Native muscle we use for new AI products.

More on this layer: React Native developers.

AWS, serverless, and infrastructure

Amazon Web Services (AWS) is where Zheat hosts most production workloads. The default shape is serverless: Lambda, API Gateway, CloudFront, S3, plus the data store that fits (DynamoDB or RDS). We write infrastructure as code with AWS CDK in Python.

Serverless is not a slogan. It is how we keep ops load low, scale when users show up, and avoid a long-term body shop sitting on a cluster. We use containers on EC2 when the workload needs them.

Zheat has shipped 20+ startup applications on AWS. We use AWS Bedrock when the model should live next to that infrastructure.

More on this layer: AWS infrastructure for startups.

Headless CMS

A headless CMS is a content system that exposes content over an API instead of rendering the public site itself. Zheat uses Contentful or Storyblok when the product has pages, campaigns, or editorial content that a non-engineer must change.

We do not put the AI prompt library in a CMS by default. Prompts that affect production answers need versioning and tests, not a marketing publish button.

n8n workflow automation

n8n is a workflow tool Zheat uses to connect apps and automate internal processes. It is useful when the product has to talk to Slack, email, CRMs, or back-office tools without writing a custom integration for every hop.

n8n is not the production agent. LangChain and Python are. n8n is the glue around the product when the client's operations already live in a patchwork of SaaS tools.

How the pieces fit together

A typical Zheat production AI product looks like this:

React or React Native is the product the user touches.
Python on AWS is the API. It owns auth, rate limits, traces, and cost caps.
RAG loads the client's documents or catalog before the model answers.
LangChain / LangGraph runs multi-step work and tool calls.
MCP exposes existing business systems as tools the agent can use.
ChatGPT, Claude, Gemini, or Bedrock is the model behind that API.
n8n and a headless CMS show up only when the operations or content team needs them.

The prototype is usually steps 6 and a notebook. Production is steps 1 through 6, with 7 if the business already depends on those tools.

What you own at the end

Zheat does not keep your product on our platform. You get the code, the infrastructure definitions, and a handover. The stack above is open enough that another senior team can run it.

We design, build, and deploy in weeks. 60-day guarantee: bug fixes after launch, money back if we miss the agreed scope. There is no long-term consulting lock-in. Your code, your infra.

If you have a prototype and no engineering team to take it to launch, book a 30-minute scope call.

Questions about the stack

Which model does Zheat use: ChatGPT, Claude, Gemini, or Bedrock?: Zheat ships against the API of ChatGPT, Claude, Gemini, or AWS Bedrock, chosen per project. We prototype on the same API we put in production. Bedrock is the usual pick when the workload already lives on AWS or the model must run in the client's cloud account.
Do I need LangChain to go from prototype to production?: No. Zheat uses LangChain and LangGraph when the product has to call tools in sequence, keep state, and fail in a way we can log and replay. A single retrieval-plus-answer path is often a thin Python service. LangChain is for workflows other systems have to trust.
Can Zheat work with the tools we already use?: Yes. Production work is usually Python and React or React Native on AWS, connected to the client's existing systems with MCP, RAG on their data, and n8n when operations already live in SaaS tools. We do not require you to throw away the stack you have.
Do we own the code and infrastructure at the end?: Yes. Zheat does not keep the product on a Zheat platform. You get the code, the AWS CDK definitions, and a handover. There is no long-term consulting lock-in. 60-day guarantee: bug fixes after launch, money back if we miss the agreed scope.