Add AI to the product you already have.
For product teams and operators who need one capability and not a new platform: search over documents, data extraction, summaries, classification or drafted replies.
- 10
- Products built in-house
- 12
- Web projects in the portfolio
- 04
- Site languages: EN, TR, ES, DE
- UTC+3
- Overlaps US mornings and the full EU workday
Most companies asking for AI already have software that works. What they lack is one specific capability inside it: finding the right clause in ten thousand contracts, turning an inbound PDF into structured fields, summarizing a call into the CRM, suggesting a reply. These features are small in scope and large in effect, and they are easy to get wrong. We build them as narrow, testable pieces behind an interface your own code calls.
Features that tend to work
Search over your own documents with answers that cite their source. Extraction of fields from invoices, forms and emails that do not follow a fixed layout. Classification and routing of inbound requests. Summaries of long threads and calls. Drafted replies that a person reviews before sending.
All five share a property: a person can tell quickly whether the output is right, and a wrong output is cheap to catch.
Features that tend to disappoint
Exact arithmetic without a calculator tool behind it. Open-ended “insights” with no defined question. Decisions with legal effect and no reviewer. We tell you when a request falls in this group and suggest the nearest version that works, which is often a retrieval feature or a narrower question.
Search over your documents
Retrieval has more moving parts than the demo suggests: how documents are split, which ones a given user may see, how fresh the index stays and what the system does when nothing relevant exists. A good answer cites the passage it came from and says “I did not find this” when that is true.
Permissions come first. A search feature that surfaces a document its user could not open elsewhere is a data leak with a friendly interface, so access rules are applied at retrieval, not afterwards.
Keeping the model behind a seam
Your code calls a small function. Behind it sit the provider, the prompt, caching, a cost cap and a fallback for the day the provider is down. Prompts are versioned and reviewed like code. Logs record what was asked and answered, with a rule for personal data so the log itself does not become a liability.
Proving it works
We gather real examples with the answers your team would accept, run the feature against them and keep the results. Every change to the prompt, the model or the retrieval setup reruns the set. In production, a thumbs-up and thumbs-down control and a sample of reviewed outputs show whether real usage matches the test.
How the cost behaves
Running cost scales with usage, because each request costs a small amount. We estimate tokens per request on your real samples, show how cost grows with volume and set caps and alerts so a loop or a spike cannot produce a surprise invoice.
Why teams work with us
One feature at a time, each one tested.
We ship AI in our own products
Rehabilty verifies repairs before proposing them, CostAnswer works on cost data and AI Accounting reads business numbers. The patterns come from products we operate.
A seam you control
The model sits behind a small interface in your codebase. Changing provider or version is a configuration change and a test run, not a rewrite.
Proof before rollout
Each feature ships with an evaluation set of real examples and the thresholds we agreed on, so quality is measured instead of felt.
Scope
What an AI integration includes
Feature definition
The one job, the input, the accepted output and who reviews it.
Retrieval or extraction pipeline
Built for your documents and permission rules.
Model interface
A small seam in your code, with provider, prompt versions and fallbacks.
Evaluation set
Real examples with accepted answers, rerun on every change.
Cost controls
Estimates on real samples, caps and alerts.
Documentation and handoff
How it works, how to retune it and how to turn it off.
Choosing a route
Built-in feature, bought tool, custom feature or no AI
| Route | Good for | Watch for | When we suggest it |
|---|---|---|---|
| Your vendor's built-in AI feature | The workflow already lives in that vendor's product | Little control over prompts, data handling and cost | Try it first. It is the cheapest test. |
| A separate hosted AI product | A self-contained job such as meeting notes or transcription | Another login, another data location, weak integration | When the job is generic and the data is not sensitive. |
| A custom feature in your product | The feature depends on your data, your rules or your interface | Needs an evaluation set and someone who owns quality | When the first two fall short. |
| No AI | A rule, a filter or a better form solves the job | Looks less exciting in a roadmap | More often than people expect. We say so. |
How a project runs
From first conversation to launch
Discovery
We document the business goal, audience, available material, and technical constraints.
Scope
Pages, features, priorities, responsibilities, and review criteria are written down.
Design
We establish the interface, component rules, and a CSS design system when the project needs one.
Development
We implement the approved interface and connect the required panels, CRM functions, or messaging tools.
Quality review
We review mobile behavior, performance, core accessibility requirements, and technical SEO.
Launch
The approved release goes live with the agreed support period and content handoff.
Technology used in this work
- TypeScript and Node.js execution runtime
- Containerized sandbox isolation
- Playwright integration and browser regression suites
- Modern AST parsers and static analyzer tooling
- Structured US public datasets
- Versioned data snapshots
- Tested calculation engines
Questions we are asked
Do we need to fine-tune a model?
Rarely. Retrieval, careful prompts and an evaluation set solve most business cases. Fine-tuning comes up only when those fall short and you have enough labeled examples to justify it.
Will our data be used to train someone else's model?
That depends on the provider's terms, which we read for the plan you choose and settle in writing before build. Where options exist, such as zero retention or a region for data, we configure them.
How do you keep it from making things up?
The feature answers from retrieved passages, cites them and says when it found nothing. The evaluation set includes questions that have no answer, so a confident wrong reply shows up in testing.
Can you add it to an app another team built?
Yes, if we get repository access and the app has a place to call a service. We start by reading the code and tell you what the feature will touch.
What does it cost to run?
It depends on volume and the size of each request. We measure on your real samples, show the curve and set caps before launch.
Describe the feature you wish your product had.
Tell us what the input looks like and what a correct output is. We will say whether it is a good fit and what a first version would take.