AI feature development for existing products
You have a product, paying users and a roadmap that needs AI on it. ComplxAI adds AI features to existing products without a rebuild where the architecture allows it: find the user job worth solving, prototype on real data, evaluate before launch, ship behind a flag in your codebase.
- Prototype on real data, not a demo set
- Working software every couple of weeks
- Your repositories, your conventions, your IP
For product teams with users to protect
The hardest AI feature to ship goes into a product people already rely on, beside screens they trust, data they consider private and a margin you have already set.
This page is about adding a model-backed feature inside a live product. Starting from nothing? See AI product development. Need a whole application designed around a model? See custom AI development. No platform yet? Start with custom SaaS development.
A good fit if…
- You run a product with active users and a codebase you intend to keep
- Customers ask when the AI feature arrives; finance asks what it costs per user
- The feature must respect tenants, roles and permissions that already exist
The AI features most often worth adding
Seven shapes cover what product teams ask for; the work is in making each hold up in production.
| Feature | The user job | What makes it work in production |
|---|---|---|
| Semantic search | Find what I mean, not the words I typed. | Hybrid search over embeddings and keywords, permission filters before ranking, plain search as fallback. |
| Summarisation | Catch up on a long record in seconds. | Scoped to the reader's role, source passages one click away, sized for the screen. |
| Drafting and rewriting | Start from something, not a blank field. | Context from the record, house tone, an editable result, edits captured as a signal. |
| Extraction and classification | Turn documents and messages into fields. | Structured outputs against a schema, confidence per field, review below a threshold. |
| Recommendations | Show me what to do next. | Signals from your own event data, explanations the user can inspect, a plan for new accounts. |
| Natural-language querying | Ask a question of my own data. | Schema-aware query generation, read-only and tenant-scoped, the query shown beside the result. |
| Copilots | Do the multi-step task with me. | Tool calls into your existing services, user approval before anything is sent, an audit trail per step. |
Which job, what good looks like, how it is measured
Which user job is answered in Discovery, two to four weeks from a fixed fee, ending in a use-case map scored by impact, effort and risk. Each candidate is written as a job, not a capability: not “add summarisation” but “catch up on a long thread before a call”.
The other two are settled at the start of each feature's slice inside an implementation block; the graded examples seed the evaluation suite.
What comes out of it
- User job
- The task in the user's words, and where it happens.
- Definition of good
- Graded examples, agreed with the people who will judge them.
- Success metric
- Adoption, acceptance rate, edits per output or time to complete.
From idea to shipped feature in six steps
Inside an implementation block of the five-stage engagement in how we work, each feature moves through six steps.
- DefineOne user job, graded examples and a metric, agreed before code.
- PrototypeA working slice on real data, behind your auth, early in the block.
- EvaluateScored against the graded examples; every change gets a number.
- Ship behind a flagMerged into your codebase, switched on for a named cohort.
- MeasureAdoption, acceptance, edits, latency and cost per request, weekly.
- ExpandWiden the cohort, add the next job, or switch it off and learn why.
How an AI feature slots into an existing app
Not a parallel system: the existing app keeps identity, permissions, data and the switch.
- Existing appwhere the feature livesWeb appMobile appExisting auth and rolesFeature flag clientKill switch
- Feature APIthe contractTyped endpointsStreaming responsesPer-tenant context
- AI serviceprompt, tooling, routingVersioned promptsStructured outputsTool callingModel routerResponse cacheGuardrails and fallbacks
- Retrievalthe user's own dataPermission-scoped queriesPostgres + pgvectorHybrid searchTenant filters
- ModelsinferenceOpenAIAnthropicGoogleAWS BedrockOpen-weight models
- ObservabilityevidenceTrace per requestTokens and cost per tenantEval score per releaseFeedback eventsAlarms
On AWS: Lambda or Fargate behind API Gateway, Step Functions for multi-step work. The layer underneath is our AI engineering practice; wiring it to a CRM or accounting package is AI integration.
Evaluated before launch, and on every change after
The graded examples become a suite; a release that scores below the last one does not merge.
Exact checks
Schema validity, citation coverage, refusal on out-of-scope or injected requests, latency and cost against budget. Pass or fail.
Judged outputs
Faithfulness to the retrieved records, tone and usefulness, scored by an LLM judge against the rubric and calibrated on the human grades first.
Gate in CI
Runs in your pipeline on every pull request that touches a prompt, model setting or retrieval code, with the score stored against the release.
UX patterns that make AI features trusted
Users judge the feature by how it behaves when it is wrong. These patterns are how it earns trust inside a product that already has it; each also feeds a signal to the evaluation suite.
Five patterns
- Streaming
- Output appears as it is generated, with cancel and retry handled.
- Citations
- Every claim drawn from the user's data links to the record it came from.
- Editable outputs
- Drafts land in a field the user can change, not a dialog they can only accept.
- Confidence and fallbacks
- Low-confidence results are labelled or routed to review; on failure, the existing path takes over.
- Feedback capture
- Accept, edit, reject and a reason, stored with the output.
Cost per request, and what it means for pricing
Before a feature is switched on for every customer we model what one request and one active user cost per month. Four inputs set that number, and each one is a lever the build can move.
That model shapes packaging: some features belong in every plan because they drive retention, some are metered, some justify their own tier. Per-tenant budgets and cost telemetry per feature keep the answer honest once usage diverges from the forecast.
The four cost inputs
- Tokens per step, prompt and completion, for every model call in the action
- The model, retrieval and tool calls sitting behind one user action
- Cache hit rate on the context that repeats between requests
- Which steps a small model passes in evaluation, so the large model runs only where it earns its cost
Shipped behind a flag, measured before it is widened
The feature goes live the way any risky change should: gradually, reversibly, with the old path still available.
Feature flags and cohorts
Ships dark, merged into main, switched on per tenant, plan or user, starting with the customers who asked for the feature and will give direct feedback.
A/B against the old path
Where the feature replaces an existing flow, both run side by side and the agreed metric decides.
Kill switch
One flag turns the feature off for everyone; the product keeps working. Rollback is configuration, not a deploy.
Monitoring and iteration
A trace per request, cost per tenant, latency by stage, acceptance and edit rates, read weekly. Accepts, edits and rejects flow back into the evaluation set, so the next change ships on a score.
What goes wrong with AI features, and the fix for each
Four failure modes we design against from the first slice.
Hallucination
The model states something the data does not support. Mitigated by grounding on retrieved records, citations the user can check and a faithfulness score per release.
Latency
Slow responses read as broken. Mitigated by streaming, caching, parallel calls, smaller models for simple steps and a latency budget per stage.
Cost creep
Usage grows, prompts grow, the bill grows faster than both. Mitigated by model routing, context trimming, per-tenant budgets and cost per request shown beside adoption.
Privacy and tenant leakage
Retrieval that ignores permissions, or one customer's data in another's prompt. Mitigated by permission-scoped queries in the data layer, covered by the regression suite, redaction where data must leave your account, and injection defences.
An AI feature built into the product, not beside it
For Modedu, an EdTech company, the AI that produces personalised academic papers sits inside the platform learners work in, not beside it as a bolt-on integration, and shipped in the same platform and admin panel as the rest of the build. The outcomes are Modedu's own reported figures.
Modedu
- Custom SaaS platform and admin panel
- AI that produces personalised academic papers inside the platform learners work in
- Agentic workflows across operations
- Agentic-first custom whiteboard
- 2× revenue within six months, client-reported
- ARR of $400k to $1M, client-reported
Feature engineers, not a vendor behind an API key
We work in your codebase
Your repositories, your CI, your review process. A small senior team, remote-first across Australia, ships pull requests your team can read and extend.
Priced per stage, IP yours
Each stage priced in writing before it starts; exit at any boundary. Code and prompts are your IP from day one of any paid stage; documentation and handover included. No retainers.
Shipped for real products
Personalised papers for Modedu, invoice processing for DisabilityAssessments, agentic internal operations for Luxpip: client-reported outcomes on what we've built.
Where feature work connects
AI product development
New AI products, built from the first user story.
AI product developmentSaaS development
Custom SaaS platforms and admin panels.
Custom SaaS platformsAI development
Custom AI applications and LLM systems.
AI development servicesAI engineering
The retrieval, routing and evaluation layer a feature relies on.
Production AI engineeringAI integration
AI connected to CRMs, accounting packages and internal systems.
Integrating AI with existing systemsCustom software development
When the product needs more than a feature.
Custom software developmentDo we need to rebuild our product to add AI features?
Not necessarily. The feature is an API, an AI service and a retrieval layer over data you already hold. A rebuild only comes up when the architecture cannot expose the data or permissions it needs, and Discovery says so.
Which model will you use?
Whichever passes the evaluation for that step at the lowest cost and latency: small models for classification and routing, a larger model from OpenAI, Anthropic, Google or AWS Bedrock where reasoning matters, behind a router so the choice can change.
How do we keep customer data isolated?
In the data layer, not the prompt. Retrieval carries the tenant and the user's permissions, so a prompt only contains records that user could already open; the regression suite checks that boundary each release. Where a model is only served offshore we say so and design what may leave your account.
How long does it take?
Implementation runs in 12-week blocks with working software every couple of weeks; the first slice on real data arrives early in the block if data access is ready on day one. Discovery sets out in writing how many features fit a block before it is priced.
What does AI feature development cost?
Every stage is priced in writing before it begins: two free conversations, Discovery from a fixed fee, Strategy priced upfront, Implementation per 12-week block with an exit at each boundary. The AI project cost calculator gives an early range.
Show us the product and the job users are stuck on
Bring the product, the user job and any prototype you have. The first two conversations cost nothing; every stage after is priced in writing.