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
You are probably here because of one of these. Each one points to where we’d start.
- 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
- 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
- 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
- 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 problemWhat 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.
How the engagement runs. The shape holds; the depth of each phase moves with the problem.
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
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
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
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
What we can point at. Including where we cannot.
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 itOne 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.
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
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.
Prefer email? contact@galenry.com
What happens next
- 01Reply within one business dayFrom one of our engineers.
- 02First call: 30 minutes, no deckA working call about the problem. We ask questions rather than present slides.
- 03An honest answerWhere we would start, or, if we are not the right team, who might be.