Built AI-native, not AI-retrofitted.
There's a real architectural difference between a product with an AI feature and a product designed around models from the start. We build the second kind, and we've shipped several of our own.
Adding a chat box to existing software is not an AI product.
The most common way AI enters a product is as a feature request: add a chat interface, wire it to the docs, ship it. The result is usually a box nobody opens twice, because it wasn't designed into how the product works, it was appended to it.
Designing AI-native changes four things simultaneously. The data model changes, because retrieval quality depends on how information is structured and chunked. The interface changes, because the interaction is conversational or generative rather than form-based. The failure modes change, because the system is probabilistic. And the unit economics change, because every interaction now has a variable cost.
That last one catches teams badly. A feature that's cheap at a thousand users can be ruinous at fifty thousand if every request routes to a frontier model. Cost architecture isn't an optimisation you do later, it's a design constraint from the start.
The other thing teams skip is evaluation. Without a harness measuring output quality, every prompt change ships on intuition, and nobody can tell whether last week's tweak made things better or quietly worse.
How it works, step by step.
Find where AI actually changes the product
Usually two or three places, not twelve. The rest is decoration that adds cost and surface area without changing what the product is worth.
Design the data for retrieval
How information is structured, chunked and indexed determines retrieval quality more than the model choice does. This is the highest-leverage decision and the one most often skipped.
Build the evaluation harness early
A test set with expected outputs, so prompt and model changes are measured rather than guessed at. Without this you're flying blind on every change.
Route models by task
Cheap models for classification and extraction, frontier models only where reasoning genuinely earns the cost. This is usually the single largest lever on operating margin.
Design the failure behaviour
What the product does when a provider is down, rate-limits you, or returns something unusable. Graceful degradation, not a spinner.
Instrument cost from day one
Per-feature, per-user token accounting, so the economics are visible before they become a problem rather than after.
Four things people assume this is.
A chat box on your existing product
That's the retrofit pattern, and it's why most 'AI features' see almost no repeat usage.
Model-maximalism
Routing everything to the most capable model is the easiest architecture and the fastest way to destroy your margin.
Prompt engineering as a strategy
Prompts matter, but retrieval architecture, evaluation and routing matter more and are far more durable.
Locked to one provider
We design for portability where it's practical, because the model landscape moves faster than product roadmaps.
Concretely, what's delivered.
- Retrieval architecture designed around your actual data, not a generic vector-store tutorial
- Evaluation harness with a real test set, so changes are measured
- Model routing, cheap models for cheap work, expensive ones only where they earn it
- Per-feature cost instrumentation from day one
- Graceful degradation when a provider is down or rate-limiting
- Provider portability where practical, with the trade-offs stated where it isn't
- Caching strategy for repeated and near-repeated requests
- Honest scoping on which parts of the product genuinely benefit
Why we can say this.
Usetta, Outlia, Ranqr and our clipping engine are all AI-native rather than AI-decorated, designed around models from the first commit. We've made the routing, retrieval and cost decisions on our own products with our own margin at stake.
The cost point in particular is one we learned by paying it. Our own products route AI operations through a provider-agnostic layer specifically so cheap operations don't run on expensive models.
What this won't do.
- Probabilistic systems don't give identical answers to identical inputs. If your product genuinely requires determinism, some of it shouldn't be a model at all.
- Evaluation is real work. Building a decent test set takes time that feels like it isn't shipping, and skipping it costs more later.
- Costs scale with usage, unlike traditional software. Success can hurt if the economics weren't designed.
- Frontier model capability changes underneath you. Architecture that assumes today's limits will age badly in both directions.
Straight answers.
Which models do you build on?
Primarily Claude, with routing to cheaper or specialist models where the task doesn't need frontier capability. We design for portability where it's practical, because the model landscape moves faster than most product roadmaps.
How do you keep inference costs sane?
Routing and caching, mostly. Most production workloads have a long tail of simple requests that don't need an expensive model, separating those out is typically the single biggest cost lever, often by an order of magnitude.
Can you work on an existing codebase?
Yes, and it's more common than greenfield. The work is usually finding the two or three places where AI genuinely changes the product rather than sprinkling it everywhere.
What's a realistic timeline?
Two to three weeks for a working first feature with evaluation in place. Full products depend entirely on scope, and we'd rather ship one thing that works than six that half-work.
Do we own the model outputs and the code?
The code, yes, on handover, in writing. Model output ownership depends on the provider's terms, and we'll walk you through what your chosen provider actually permits.
What if the model isn't good enough for our use case?
Then we say so before building. Some problems aren't solvable at current capability, and finding that out in week one is much cheaper than in month six.
Anqor is a small studio, so you deal with the person who builds it. If this isn't the right fit for your business, I'd rather say so on the first call than sell you something you don't need.
LinkedIn →Bring the use case. We'll tell you if the models are there yet.
Some problems aren't solvable at current capability. Finding that out in week one costs a call. Finding out in month six costs a quarter.