Artificial intelligence development
AI Development
The useful kind of AI.
There are two kinds of AI project. One removes work somebody is doing by hand every week. The other exists so the company can say it has AI.
We only take the first kind. That usually means finding the single repetitive task inside a business that a model can genuinely do, wiring it into the system properly, and leaving a human in control of the result.
What we do
AI features inside products
Assistants, suggestions and automation built into software people already use, rather than a separate chatbot nobody opens.
Document and speech processing
Turning recordings, forms and PDFs into structured data a system can act on.
Search and retrieval
Letting people ask a question of their own data and get an answer with its source attached.
Workflow automation
The handoffs between systems that currently depend on somebody remembering to do them.
Model integration
Connecting to the right provider for the job, with cost, latency and failure handled rather than hoped about.
How we work
01
Scope
Find the task worth automating. If we cannot name it precisely, it is not ready to build.
02
Design
Decide what the human sees, what they can override, and what happens when the model is wrong.
03
Build
A narrow version that does one thing well, measured against real examples.
04
Test
Against your actual data and edge cases, not a demo set.
05
Launch
Monitoring, cost controls and a clear fallback path when the model or the provider fails.
The same five stages run through everything we make, including our own products.
Technology we use
- Claude
- OpenAI
- Speech recognition
- Vector search
- Python
- TypeScript
Questions we get asked
- Can you add AI to a product we already have?
- Usually yes, and that is often the better project. Adding a well-chosen feature to software people already use beats building a separate AI product they have to be persuaded to open.
- What happens when the model gets it wrong?
- It will, so the design has to assume it. We keep a person in control of anything consequential, show where an answer came from, and build an obvious path to override it. A feature that cannot be corrected is a liability.
- Is our data used to train someone else’s model?
- Not without your explicit decision. Provider choice and data handling are part of the scope conversation, and we set it up so you know exactly what leaves your systems.
- What does it cost to run?
- Model usage is an ongoing cost, not a one-off, and it scales with how much you use it. We measure it during the build and tell you what the monthly figure looks like before you commit.