AI feature build
Add the AI part of your product properly, end to end: the UI, the API, the prompts and the evals, on your existing TypeScript or Python backend.
For: Products that need chat, search, an assistant or an agent that actually works for users.
Free, 30 minutes, no preparation needed.
What’s included
- Streaming UI with real loading, error and empty states
- Model integration with Anthropic, OpenAI or AWS Bedrock, through the Vercel AI SDK or the official Python SDKs
- Typed tool calls and structured output with Zod or Pydantic
- RAG over your own data with embeddings and pgvector, with cited sources
- Tool calling and agent pipelines with step limits and human sign-off before writes
- PII redaction before prompts, EU-region model endpoints where the provider offers them, and no training on your users' data
- Clear AI disclosure for users, in line with the EU AI Act's transparency rules
- Tracing and evals in Langfuse, Braintrust or LangSmith before anything ships
Built end to end
The AI part of a product is more than a prompt. It needs a streaming interface with real loading and error states, an API that controls cost and access, retrieval that only sees what the user is allowed to see, and prompts versioned like code. I build all of it on your existing backend, so the feature fits the product instead of sitting beside it.
Evals before launch
Before any prompt gets tuned, we agree on a set of real questions and what a good answer looks like. That eval set runs on every change, so "it works" has a number behind it and a prompt tweak can't quietly break last week's fix. Every call is traced, so when a user gets a bad answer you can see why.
Safe by design
Retrieved text and model output are treated as untrusted. Data is scoped on the server, tools that write need human sign-off, personal data is redacted before it reaches the model, and users are told clearly when they're talking to an AI. I don't train or fine-tune models: the work is product features on top of model APIs, which is where most teams need the help.
If the codebase hasn't been reviewed, I'll suggest a short readiness review first, so the feature doesn't land on top of an open database.
How it works
- 01
Talk
A call about what you have, what is breaking and what has to ship.
- 02
Scope
An audit or a short spec with acceptance criteria, so we agree on done before any code.
- 03
Build
Small, reviewed pull requests against the spec, deployed to previews you can click through.
- 04
Hand over
Docs, tests and a walkthrough, so the codebase is yours, not mine.
Got a demo that needs to survive real users?
Tell me what you have and what has to ship, on a call or by email with a link to the repo or the live app. I'll tell you honestly whether I can help, and what I'd look at first.