Which feature to add first
You do not need a new product to get value from AI. You need the right two or three features in the one you already have. These are the candidates we see most, scored the way we score them in week one.
| Feature | Value | Effort | Cost to run | Usually first? |
|---|---|---|---|---|
| Search that understands meaning | High | Low | Low | Yes |
| Summaries where people read a lot | High | Low | Medium, unless cached | Often |
| Extracting fields from documents or photos | High | Medium | Low, runs once per document | If you have the paperwork |
| Recommendations from your own data | Medium | Medium | Low | After search |
| An in-app assistant | High and visible | High | Medium | Rarely first |
| Generated marketing copy inside the product | Low | Low | Low | No |
Search wins the first slot most of the time for an unglamorous reason: it is cheap, it is easy to measure, and it fails safely. A search result that is merely unhelpful costs nothing. An assistant that confidently tells a customer the wrong refund policy costs a great deal, which is why the most visible feature is rarely the right one to start with.
What it costs, before and after launch
There are two numbers here and buyers usually ask about only one. The build is 3 to 6 weeks at a fixed price. The second number is the one that surprises people: an AI feature turns software with no marginal cost into software with a meter on it.
| Feature and volume | Rough monthly usage cost |
|---|---|
| AI search, 50,000 searches | about $20 |
| Summary generated on every record open, 200,000 opens | about $115 |
| The same summaries, cached per record instead of per view | about $11 |
Those three rows contain the whole lesson. The expensive version and the cheap version of the same feature differ by a caching decision, not by a model. A summary of a record that has not changed should be computed once and stored, not regenerated every time someone opens it. We work these numbers out on your real volumes before quoting the build, because a feature that is wonderful and unaffordable is not a feature. The full method is in what an AI agent costs to run.
How we add it without touching what works
The AI runs as a separate service beside your existing backend, called from the screens that matter. Your codebase gains an API call, not a dependency on a model provider threaded through it. That matters more than it sounds: providers deprecate models on a few months' notice, and when that happens you want one service to update rather than forty call sites.
Everything ships behind a feature flag with a control group. With the flag off, your product behaves exactly as it does today, so the rollback plan is a toggle rather than a deployment.
Where your data goes
This is the question that decides enterprise deals, and it deserves a straight answer rather than reassurance.
We map it in discovery, per feature: what leaves your systems, what the model provider receives, what is stored and for how long. Major providers do not train on data sent through their APIs by default, which is enough for most businesses. Where it is not enough, because of a regulator, a customer contract or the nature of the data, we run open models inside your own environment and accept the higher engineering cost for the control it buys.
The test we apply: if the honest answer would embarrass you in a customer security review, the design is wrong, not the explanation.
Working with the stack you already have
We integrate with Node, Python, PHP and Laravel, .NET, Flutter, React Native, and native iOS and Android. If your app has an API or a database, it can be integrated with.
Older codebases are usually easier than their owners expect, precisely because the AI service sits beside the application rather than inside it. A ten-year-old Laravel monolith with a working API is a more straightforward integration than a modern app with no clean boundary, which is the opposite of what most people assume when they call us apologising for their stack.
How an integration project runs
- Discovery, week 1. We read your codebase and data model, score the candidate features on value against effort, model the running cost of each, and agree the metric that will decide the rollout.
- Prototype, week 2. The chosen feature on your real data in a staging build, scored for quality and timed for latency.
- Build, weeks 3 to 6. Integration, the feature flag, the control group, monitoring, the evaluation set, and a rollout plan your team owns rather than depends on us for.
If the prototype shows the feature does not move the metric, we say so and you have spent two weeks instead of two months. That has happened, and it is a better outcome than the alternative.
For a feature that is really its own product rather than an addition, see LLM and generative AI apps. If you are not yet sure which of your processes is the candidate, the AI readiness audit answers that in two weeks.