AI features for SaaS products
We build AI for SaaS companies that want features their customers will pay for: assistants that answer from customer data, search across records and documents, and workflows that finish tasks inside the product. We build in your codebase with evals, tenant isolation and cost controls, so the feature keeps working as usage grows.
Where the work gets stuck.
AI features that falter on real data
A quick model integration answers the team's test questions well and customer questions poorly. Without evals, nobody can tell whether a prompt change made it better or worse.
Multi-tenant data and permissions
Retrieval over customer data must respect tenants, workspaces and roles on every query. Getting it wrong once is a security incident with your largest customer.
Model costs that scale with usage
Token costs rise with every active user and every long context. Gross margin suffers when nobody measures cost per feature or per tenant.
How we improve SaaS.
Each one is scoped around your systems and rules, and each one keeps a person in charge of the decisions that matter.
In-product assistant
An assistant answers questions from the customer's own records, documents and your help content, citing where each answer came from and applying the logged-in user's permissions. It hands over to support when it cannot answer.
Semantic search across customer data
Search that understands meaning across records, documents and comments in each tenant, with hybrid ranking and the filters your users already know. Indexes stay partitioned per tenant.
Agent workflows as a product feature
Multi-step tasks your users do by hand, such as reconciling records or preparing a report, run as an agent inside the product with a review step before changes apply. Every run is traced for support and debugging.
MCP server for your product
An MCP server exposes your product's data and actions to Claude, ChatGPT and other AI clients, scoped by your OAuth and API permissions. Customers use your product from the AI tools they already work in.
Evals and monitoring for AI features
Test sets from real usage, automated checks in CI and production tracing show quality, latency and cost per feature and tenant. Model upgrades become a measured decision.
Document understanding in the product
Uploaded invoices, contracts or forms become structured data your product can use, with confidence scores per field. Users correct low-confidence fields in a review screen, and corrections feed the test set.
Built around the rules.
What we design for from the first week. Your legal and compliance people keep the final word.
GDPR as a processor
Customer data passes through your AI features, so model providers become sub-processors. We help you choose EU-hosted or zero-retention options, update your sub-processor list and keep personal data out of prompts where possible.
EU AI Act roles and transparency
Adding AI to a SaaS product can make you a provider under the EU AI Act, and users must be told when they interact with an AI system. We check whether any feature touches a high-risk use such as recruitment or credit scoring, and document the rest.
EU Data Act switching rules
The Data Act, applying since September 2025, requires cloud and SaaS providers to let customers switch provider and take their data with them. AI features we build keep derived data such as embeddings and settings exportable.
SOC 2 and ISO 27001 expectations
Enterprise buyers review AI features in their security questionnaires. We deliver architecture notes, data flow diagrams and logging that fit your SOC 2 or ISO 27001 controls.
Works with what you run.
If a system has an API, a database, an export or an inbox, we can build on it. These are the ones we meet most.
- GitHub
- Linear
- Jira
- AWS
- Google Cloud
- Azure
- Vercel
- Postgres
- Stripe
- Intercom
Where to start.
One AI feature behind a flag
We pick one feature with clear customer value and measurable output, build its eval set from real data with permission and ship it behind a feature flag to a group of design partners. You get usage, quality and cost figures before deciding on general release.
Talk it throughWhat it includes
- Eval set and quality baseline
- Feature built in your codebase and CI
- Tenant isolation and permission checks
- Tracing with cost per tenant
Related work.
Guides.
Build vs buy software: a decision guide for operations and product teams
A practical guide to choosing between off-the-shelf and custom software, with a cost comparison, a decision matrix and a checklist for your team.
10 min read
AI vendor security questionnaire: what to ask before you buy or build
The questions to ask an AI vendor, or your own team, about data, model providers, access, logging, quality, incidents, GDPR and exit, and how to score the answers.
8 min read
Further reading.
LLM evals: how to test AI features before every release
A practical approach to LLM evals: build a test set from real cases, combine code checks with model grading, and block releases that regress.
5 min read
RAG vs fine-tuning: which does your business actually need?
RAG gives a model your knowledge at answer time; fine-tuning shapes its behaviour. How to choose, when to combine them and what each costs.
4 min read
How to evaluate RAG: retrieval metrics, faithfulness and golden sets
How to measure a RAG system properly: separate retrieval from answers, check faithfulness claim by claim and build a golden set you can trust.
4 min read
Common questions.
Whichever fits the feature: Claude, GPT, Gemini, Mistral or open-weight models in your own cloud. We keep the model behind an interface so you can switch when prices or quality change, and the eval set tells you whether a switch is safe.
Yes. We build in your languages, frameworks and cloud, whether that is TypeScript on Vercel, Python on AWS or .NET on Azure, and follow your code review and deployment process.
We measure cost per request, feature and tenant from the start, then use caching, smaller models for simple steps and shorter contexts where quality allows. Rate limits and budgets per tenant protect your margin.
Retrieval and well-designed prompts usually come first, because they are cheaper to maintain and easier to update. Fine-tuning helps with specific output formats or narrow high-volume tasks, and we test it against the retrieval baseline before recommending it.
You do: code, prompts, eval sets and any fine-tuned weights. Everything lives in your repositories and cloud accounts from the start.