AI features inside software you sell: multi-tenant, cost-controlled per account, and tested in CI alongside everything else you ship.
AI product engineering is the building of AI features inside software you sell to your own customers, as opposed to AI used internally. AMT builds these as product engineering work: tenant isolation enforced at the retrieval layer, token budgets per account, graceful degradation when a model is slow, and an evaluation suite that runs in your existing pipeline. We have shipped AI inside a commercial SaaS product in production.
// the_problem
Building AI for your own team and building it into a product customers pay for are different jobs, and the difference is not the model. An internal assistant that is right most of the time is useful. A feature in your product has to hold up across every tenant, at every data shape, at a cost per user that still leaves a margin, while your support team fields tickets about behaviour that is probabilistic by design.
Here is what that actually changes.
// the_seven
| Issue | What changes |
|---|---|
| 1. Tenant isolation | Isolation has to be enforced at the retrieval layer, not filtered after the fact. A vector index shared across tenants is a data leak with a delay on it, and it is the failure that ends contracts. |
| 2. Cost per account | Token spend stops being one line in your cloud bill and becomes a per-customer margin question. Your heaviest tenant can quietly cost more than they pay you. |
| 3. Budget enforcement | Somebody will automate against your AI feature. Per-account rate limits and token budgets have to exist before that happens, not after the invoice arrives. |
| 4. Graceful degradation | When the model is slow or unavailable, the feature has to fail back to something usable rather than breaking the product around it. This is a product decision as much as an engineering one. |
| 5. Evaluation in CI | The AI feature has to be tested on every release like everything else you ship, with a scored set that fails the build. Manual spot-checking does not survive a release cadence. |
| 6. Support burden | Your support team now fields tickets about a probabilistic feature. They need visibility into what the system did and why, or every ticket escalates to engineering. |
| 7. Pricing | Seat pricing and usage-based AI cost pull in opposite directions. Decide how the feature is priced before you build it, because it changes the architecture. |
Most teams have handled two or three of these and believe they have handled more. The ones that bite later are almost always cost per account and evaluation in CI.
Check your AI feature against the seven
The full list with the questions to ask your own team about each, on one page. Built to be taken into a product review where engineering and finance disagree about the cost line.
// what_we_build
// proof
Embedded in the product UI. It ingests live conversation logs, identifies drop-off nodes and ambiguous intents, and recommends specific flow changes with the reasoning attached, so the customer can act on it rather than just read it. 35% higher flow completion.
// cost
Two numbers matter here and most vendors only discuss the first. The build cost is a product engineering project. The unit cost is what you pay per customer per month once it ships, and it is the one that decides whether the feature is a business or a liability. We model both before the build starts.
// the_honest_section
If the AI feature is for your own team rather than your customers, most of this page does not apply and enterprise AI development is the better starting point.
If you have not decided how the feature will be priced, that decision changes the architecture, so it comes first. We will push on it in the first call.
If your product has no evaluation or CI discipline today, adding a probabilistic feature to it will expose that rather than solve it. That is fixable, but it is the first project rather than the second.
// faqs
Building AI features inside software you sell to customers, engineered for multi-tenancy, cost control per account, graceful degradation and continuous evaluation. It is product engineering work, not an AI experiment attached to a product.
Audience and constraints. Internal AI has one tenant, forgiving users and a cost line nobody itemises per person. A feature you sell has many tenants, paying customers and a margin to protect.
At the retrieval layer, so a query can only reach the requesting tenant's content, rather than retrieving broadly and filtering afterwards. Filtering after retrieval is where leaks come from, and it is worth asking any vendor which of the two they do.
It depends on context size, calls per session and output length far more than on model choice. The number has to be modelled at your expected usage before you build, because it determines whether the feature can be priced profitably.
Seat pricing is simpler and exposes you to heavy users. Usage pricing protects margin and complicates the sale. Hybrid models with an included allowance are common. The decision changes the architecture, so make it early.
The feature degrades to something usable rather than breaking the product. Defining that fallback is a product decision and it should be made deliberately rather than discovered during an outage.
A scored evaluation set of real inputs with expected outputs, run on every build, failing the pipeline on regression beyond a threshold. It is the only way a team can keep changing a probabilistic feature safely.
Thirty minutes with an engineer. Bring your product and your pricing model and we will tell you what the AI feature does to your unit economics before you build it.
Not ready to talk? Read how we deliver, or see what software development costs. No form.