Skip to content
Taking on new projects. Send us a brief
Solutions · AI Product Development

AI features that hold up with real users

Most AI projects stall between the demo that impressed everyone and the version that has to handle real customers, messy data and a monthly bill. We build for that second version from day one.

The shape of the work

Agreed before we start. You own everything we produce, whether or not you continue with us.

Starts with
Discovery
You get
Running system + runbook
When this applies

You are probably here because of one of these. Each one points to where we’d start.

  1. 01

    What you are seeing

    A prototype that works in the demo but falls apart on real data

    The question it raises

    Will this hold up when a thousand people use it at once?

    Where we’d start

    • Testing it on your real questions before building further
  2. 02

    What you are seeing

    No way to tell whether a change made answers better or worse

    The question it raises

    How do we know a change made answers better?

    Where we’d start

    • A fixed set of test questions, with a starting score
  3. 03

    What you are seeing

    A model bill nobody can predict or cap

    The question it raises

    What does each answer cost, and what stops that running away?

    Where we’d start

    • Spend limits, and cheaper models for simple tasks
  4. 04

    What you are seeing

    An AI feature nobody trusts enough to put in front of customers

    The question it raises

    What happens when the AI is wrong?

    Where we’d start

    • Citations, and a hand-off to a person when it isn’t sure

None of these sound right? Tell us what is actually happening.

Describe the problem
What it covers

What an AI feature needs to survive real use. Not all four land in every engagement.

Answers from your own content

It searches your content, cites what it used, and hands off to a person when nothing is strong enough, instead of making up an answer.

Agents that stay inside limits

An agent can take real actions, but only from a list you approve, under a spend ceiling, and with a person signing off anything that can’t be undone.

Every change tested before release

A fixed set of test questions scores every prompt or model change, so anything that makes answers worse is caught before a customer sees it.

The right model, with a fallback

Simple tasks go to a fast, low-cost model and hard ones to a stronger model. If a provider has trouble, a fallback keeps the work moving.

The work

How the engagement runs. The shape holds; the depth of each phase moves with the problem.

01

Define good

We collect the questions your system has to answer and turn them into a test set. That gives us a starting score before anything is built.

You get

Test questions + a starting score

02

Find the right content

Your content is prepared and indexed, then tuned until the right passage comes back for the questions that matter. Answers cite their sources from day one.

You get

Working search, scored against the test

03

Build the answers

We write the prompts, choose what it may do, and set how sure it must be before answering. Every change is scored against the test set first.

You get

Answers, plus a route to a person

04

Go live

Spend limits, rate limits, monitoring, and a runbook your team can follow when something looks wrong in the middle of the night.

You get

Live system + runbook

Evidence

What we can point at. Including where we cannot.

Proof

An AI assistant live for a client, checked before it replies

Appooppanthaadi’s assistant, Appu, answers from the live catalogue. A second pass checks every figure against the source data before the customer sees a reply.

See it
Stated limit

One published client AI project so far

Most of our production AI experience comes from products we run ourselves. That counts, but it isn’t a shelf of client references. Ask us what we have and haven’t done.

Defaults

What we reach for first. Not the only things we work with, and we change them when there is a reason.

Models

Chosen per task, with more than one wired up, so no single provider can stop you.

  • Claude
  • OpenAI
  • Open-weight models

Search

Searched by meaning and by keyword, so exact terms like a product code are still found.

  • pgvector
  • Pinecone
  • Hybrid search

Application

Answers appear as they are written, on the same stack as the rest of your product.

  • Next.js
  • Node
  • Streaming

Operations

The checks that say whether a change helped, and the limits that stop a runaway bill.

  • Test sets
  • Tracing
  • Spend limits
Get started

Tell us what you’re trying to build. We’ll tell you where we’d start.

Bring an idea, a stalled project, or a system that has outgrown itself.

Send us a brief

The problem, what you have tried, and what success looks like. A few lines is enough to start.

What happens next

  1. 01Reply within one business dayFrom one of our engineers.
  2. 02First call: 30 minutes, no deckA working call about the problem. We ask questions rather than present slides.
  3. 03An honest answerWhere we would start, or, if we are not the right team, who might be.