AI features your users would miss if you removed them
You get AI doing real work inside your product: reading documents, grounding answers in your data, ranking what matters. Built to be measured, and kept working afterwards.
The demo is the cheap part now. Any competent team can wire a model to a prompt and show something impressive on a Tuesday. What separates a feature from a science project is whether you can prove, in month four, that it is still right. That needs graded test cases you own, a record of every decision you can replay, and a named person whose phone rings when the numbers slip. We build the second part first, because the demo is worthless without it.
AI fails politely, which is the expensive way
Ordinary software fails loudly. Something throws, the run stops, someone gets paged and fixes it. AI does the opposite. It returns a confident, well-formatted answer that happens to be wrong, and the log records a success.
Your customer meets the failure before your team does. By the time somebody complains, the same mistake has been made a few thousand times and nobody can say when it started.
That is why the first thing we build is not the feature. It is the way you will find out the feature broke.
What is running now
Counted, not estimated
9
production systems with AI doing real work
50+
ESG topics Greenlight scores per company
10-15
independent sources behind each Greenlight topic
60
days' minimum notice Anthropic gives before retiring a public model
What we actually build
Named systems, running for named clients. Not capability nouns.
AI that reads documents nobody wants to read
PremiumAudit.io runs the insurance premium audit lifecycle on Claude, with field mapping, validation and exception handling. A human auditor stays in the loop on every policy.
AI that gives tools to a model, safely
Go4Gr8 uses MCP in production so a leadership platform can track commitments through real tools. Each agent reaches only what it is scoped to touch, and nothing more.
AI that ranks high-stakes matches
TrialTriage ranks eligible oncology trials from de-identified patient data. Nurses review and finalise every result, with PHI masking and an audit trail across 23 tracked actions.
AI that answers the phone
ZhoopZhoop's voice agents take live customer calls over Twilio and book work while every tech is under a car. Deepgram handles speech and turn-taking, and staff see every transcript.
- ScopeFree call. Which decision, how often?
- GradeReal cases, answered by your experts.
- BuildRetrieval, tools, and the human gate.
- ScoreAgainst those cases, before release.
- RunTraces, drift checks, model migration.
Grade comes second, before any model work. Cases graded by your own experts are the only thing that can later prove a prompt change made the system worse.
Making the answer traceable to a source
A model that invents an answer is a support ticket. A model that invents an answer inside a regulated workflow is something worse. The fix is not a better prompt.
The fix is grounding: the system retrieves from your own documents, cites what it used, and says it does not know when the documents do not cover the question. Greenlight scores a company's sustainability by reading laws, certifications and controversies rather than the company's own reporting, with 10 to 15 independent sources behind each topic. An expert verifies the assessment before it counts.
- Answers cite the passage they came from, so a reviewer can check in seconds.
- The system is allowed to say it does not know, which most demos are not.
- Anything irreversible waits for a person to approve it.
- The model name lives in configuration, so a retirement is a config change and a re-run of the test set.
What we build on
Models and protocols
Build
Run
Shipped integrations
AI running for real clients now
“I am extremely happy with the results and would highly recommend Hashlogics to anyone.”
Daniel Khin · CEO, PremiumAudit.io
The usual AI project against ours
Both demo well. They separate at the point where somebody has to trust the output.
| Criterion | The usual approach | How we build |
|---|---|---|
| Proof it works | A demo, run by the person who built it. | Cases your experts graded, re-scored on every change. |
| When it is wrong | Nobody knows until a customer says so. | Replay the run: input, retrieval, tool calls, output. |
| Where answers come from | The model's memory, which cannot be checked. | Your documents, cited, with an option to say it does not know. |
| Model retirement | Found out when the API starts erroring. | Planned. Model id in config, test set ready to prove the replacement. |
| After launch | The contract ends at go-live. | An agreed service level, or a documented handover to your team. |
01How do we prove an AI feature is accurate enough to ship?
You score it against cases your own experts answered first, and you set the passing bar before you see the results. That set becomes the thing you re-run on every prompt, model or data change. Without it, accuracy is an opinion held by whoever built the feature.
02Can you add AI to a product we already have?
Yes, and most of our AI work is exactly that rather than a new product. Cruise Search AI is an AI search module embedded in the client's existing WordPress site, backed by FastAPI and LangGraph. Going into an existing codebase is where the paid two-week diagnostic applies, and it ends with a fixed price.
03Where does our data go when we use a model API?
Your data goes wherever the provider's current terms say it goes, which is why we put that in writing before anything is built. We check the vendor's current terms rather than repeating what was true last year, then design around what they actually commit to. Where the data is sensitive, we keep the model away from the parts it does not need. TrialTriage de-identifies patient data before anything reaches a model.
04Which model should we build on?
Pick by the job, then keep the choice reversible. We have shipped on Claude, OpenAI models, Fireworks AI and Perplexity Sonar-Pro depending on what the workflow needed. The model name stays in configuration. Anthropic gives at least 60 days' notice before retiring a public model, and 60 days is short if that name is hardcoded in twelve places.
05Do we need to fine-tune a model?
Usually not. Most business problems are retrieval problems, where the answer exists in your documents and the system needs to find and cite it. Fine-tuning teaches a model a style or a format, not a fact, and it makes every future model upgrade more expensive.
06What does it cost to run an AI feature every month?
Running cost is driven by request volume, how much text each one carries, and how often you need the most expensive model. Those are the levers, and we design so the cheap model handles the easy cases. The scoping call is free, and the drivers get named before you commit.
07What happens if the AI gets something wrong in front of a customer?
Every build we ship has a defined path to a person, and anything irreversible sits behind that gate by design. When something does slip through, the trace shows the input, what was retrieved and what the model chose, so the fix targets the actual cause. A system you cannot replay can only be guessed at.
08We are a small team. Is this only worth it at enterprise scale?
Both work, and the shape differs. A small team usually wants one AI feature live and evidence users rely on it, so we ship narrow and score it. An enterprise wants permissions, audit trails and a migration plan from the start, which is what Go4Gr8 needed to run enterprise pilots on AWS.
Related
- AI agent development →When the AI has to act on your systems, not only answer.
- RAG development →Grounding answers in your own documents.
- AI consulting →Deciding what to build first.
- RAG vs fine-tuning →Which one your problem actually needs.
- Hire AI developers →Engineers who have shipped this to production.
