AI & automation
Adding an AI feature to a product is mostly engineering around a model call: what you send, what you retrieve, who may see it, what it costs, how fast it responds and what happens when the answer is wrong. We integrate model APIs from providers such as OpenAI, Anthropic and Google into SaaS products and apps, build retrieval over your own data (RAG), keep it separated per tenant, and set up evaluation and monitoring. We build the product too, so this is one team, not a handoff.
A prompt that works on ten examples can fail on the eleventh, run up an unexpected bill when usage grows, time out in front of a customer, or in a multi-tenant product show one customer a passage from another's documents. None of these show up in a demo.
So we treat the model call as one component in a system. Retrieval is filtered by tenant before anything reaches the model. Answers are checked against a test set that grows from real failures. Costs and latency are budgeted per request, there is a fallback when a provider is down, and the feature can be switched off without redeploying.
Server-side calls to a model provider with structured outputs, retries, timeouts, streaming where it helps and a provider layer so you can switch models without rewriting the feature.
Your documents or records chunked, embedded and searched, so answers are grounded in your content and can cite it.
Retrieval and tool calls filtered by tenant and user permission before the model sees anything, using the same rules as the rest of your product.
A test set, scoring on every change, and production logging of quality, latency, cost and failures.
For products where each customer has their own data. We choose how to store and search the content (a vector extension in PostgreSQL, or a dedicated vector store, depending on size and how you already host), make the tenant filter part of every query, and add citations plus a rule to decline when nothing relevant is found. Isolation is tested directly: one tenant tries to retrieve another's content.
How we handle tenancy in SaaS buildsPer-request token budgets, caching of repeated work, a smaller model for simple steps and a larger one for hard ones, plus timeouts and a fallback (a cached answer, a simpler path or a plain message) when a provider is slow or down. You see usage per feature and per tenant, so a new plan limit or a surprise bill is a dashboard question, not a guess.
Every AI features for your product project runs through our delivery process. These are the steps that are specific to this work. Teal steps are thinking, graphite steps are building, and orange ones keep it running.
Choose the feature and its test
One feature, a written description of a good answer, and a set of real examples we can score against.
Map data and risk
What data the feature touches, who may see it, what the provider receives and what happens if the output is wrong.
Build the pipeline
Provider layer, retrieval, prompts, structured outputs and the permission filters, in your codebase, behind a flag.
Evaluate and harden
Score the test set, read the failures, add guardrails and fallbacks, and check tenant isolation and latency.
Release to a few accounts
Switch it on for a limited group, with usage, cost and quality logging running from the first request.
Monitor and tune
Review logged failures, update the test set, adjust prompts and models, and watch the cost per request as usage grows.
| Scope | Range |
|---|---|
| Feature definition, data review and evaluation set | 1–3 weeks |
| One AI feature in production behind a flag | 4–10 weeks |
| Retrieval across tenants, several features and monitoring | 3–5 months |
Planning ranges, not quotes. Your scope sets the real timeline, which we confirm in writing after discovery. See how engagements are priced.
The tenancy, roles and plans an AI feature has to respect.
When the feature belongs in an internal system rather than a public product.
Hosting, monitoring and releases for the services behind the feature.
The API structure we use, which the AI layer plugs into.
In most products the feature changes what a user does, not who is needed. We design it as an assistant inside a workflow, with the user able to edit, reject or override the output. Decisions about staffing sit with you.
We send the provider the minimum a request needs, filter by tenant before anything is sent, and review the provider's retention and training settings with you. You may also need to update your own terms and privacy policy. Your legal review decides what is acceptable, and we don't claim compliance certification for any provider or for the finished feature.
Accuracy is specific to the task and your data, so we measure it with a test set built from real examples instead of promising it. Answers carry citations where possible and risky outputs need user confirmation. If a provider fails, the feature falls back to a cached result, a simpler path or a plain message, and the rest of your product keeps working.
Access to the codebase and a staging environment, a product owner who can say what good looks like, examples of real user inputs, and a decision on which model providers and data may be used. For retrieval, we also need the content in a form we can read and a view of who is allowed to see what.
Running costs come from model usage (which scales with requests and the amount of text per request), embedding and storage for retrieval, hosting and monitoring time. We estimate per-request cost during design and add budgets and per-tenant usage tracking, so the cost is visible and can be tied to your plans.
A plugin is fine for a generic feature. A freelancer may build a good prototype. We bring the product engineering around it: tenancy, permissions, testing, deployment, monitoring and someone to keep it running as models and your data change. We also tell you when a smaller approach is enough.
Multi-tenant subscription products: tenancy, roles, plans, admin tools, and the running of them afterwards.
Learn moreCRMs, internal tools, portals and multi-tenant SaaS with roles, permissions and integrations.
Learn moreDeploy pipelines, managed hosting, secrets, backups and monitoring in your own accounts.
Learn moreA few lines is enough. We'll ask the right questions on the call.
We reply within one working day
By email or WhatsApp, whichever you prefer.
A short call
To understand the goal, the people who'll use it and any deadline.
A written scope and estimate
Before any work starts, so you know what you're agreeing to.
Prefer to talk first?