Scope the use case
Discovery
We agree what the feature should do, what good looks like and which data it may use.
Technologies
AI & data engineering
AI-powered features and data foundations, from LLM-based search and assistants to recommendations, analytics and workflow automation, built on top of PostgreSQL, Redis and Elasticsearch.
- OpenAI / Azure OpenAI, Azure AI Services
- PostgreSQL, Redis, Elasticsearch
- LLM search, recommendations, automation, analytics
What we build
What we build with AI & data engineering
The AI and data work we actually ship, grounded in your own data instead of a generic model.
Retrieval over your own data
RAG search and assistants grounded in your documents, with answers that cite the source they came from.
Structured outputs and tool-use
The model fills forms, calls your APIs and returns typed data, instead of free text someone has to parse.
Recommendations and automation
Personalisation, ranking and in-product assistants that take repetitive work off your team.
Data foundations underneath
Pipelines, indexing and audit trails on PostgreSQL, Redis and Elasticsearch, so the AI has something good to retrieve.
What's modern now
What matters in AI right now, honestly
AI features are easy to demo and hard to ship. Here is where we put the effort, and what we refuse to do.
Retrieval, not a chatbot bolt-on
Most useful AI is grounded in your own data, retrieved at query time and cited. We reach for retrieval before anyone mentions fine-tuning.
Evals and guardrails before launch
A probabilistic feature needs a way to measure answer quality and catch failure modes. We do not ship an LLM feature we cannot test.
Data governance is part of the build
Pseudonymisation, no production secrets in tools, per-client carve-outs. Where a model should not see something, it does not.
The stack
The stack we use here
The tools we reach for in this pillar. Honest, not exhaustive.
PostgreSQLPostgreSQLRedisRedisElasticsearchElasticsearchOpenAI APIOpenAI APIAzure OpenAIAzure OpenAIAzure AIAzure AIPrismaPrismaMySQLMySQLMongoDBMongoDB
Tools & integrations
AI and data services we build on
The AI, data and automation services we build features on.
- AI providers & models
- OpenAI
- Anthropic
- Google Gemini
- Azure OpenAI
- AWS Bedrock
- Vector & retrieval
- pgvector
- Elasticsearch
- Workflow & automation
- n8n
- Zapier
- Analytics & BI
- Google Analytics 4
- Hotjar
- Pendo
- Power BI
Third-party services we wire in, picked per project. Our core stack is the section above.
How we choose
Retrieval first, then the rest
Three common ways to add intelligence to a product. We default to retrieval and add the others only when the problem calls for them.
Criteria
Retrieval (RAG)
Fine-tuning
Prompt only
Uses your latest data
Strong. Reads live sources
Limited. Frozen at training
Partial. No private data
Answers cite sources
Strong.
Limited.
Limited.
Cheap to update
Strong. Change the data
Limited. Retrain to change
Strong.
Keeps sensitive data contained
Strong. Stays in your store
Limited. Baked into weights
Partial. Sent at query time
A starting point, not a rule. We pick per use case in discovery.
Grounded in your data
Retrieval over your own sources with citations, so answers are traceable instead of confidently wrong.
Tested on real cases
Evals on real cases with acceptance thresholds, so we know quality before launch and catch regressions after.
Guardrails and a human fallback
Input and output checks and a path back to a person when the model is unsure.
Run under our AI Use Policy
Vetted enterprise tools that contractually don't train on your data, no production secrets in prompts, pseudonymised test data and an audit trail, all written down in our AI Use Policy.
How we adopt it
How we add AI to a product
A small, testable first slice, not a six-month research project.
Ground it in your data
Build
Retrieval over your sources, structured outputs and the data foundations to support them.
Eval, guardrail, ship
Release
We measure answer quality, add guardrails and release behind a flag with a human-owned fallback.
Proof
Real work in this stack
Products where AI features shipped past the demo: grounded in real data, evaluated before launch and running in front of users.
FAQ
Common questions
We default to retrieval over your own data, so answers are grounded in your sources and cite where they came from instead of being generated from the model's memory. Before launch we build evals on real cases with acceptance thresholds, so we measure answer quality rather than hoping it's good, and we add input and output guardrails plus a human-owned fallback for when the model is unsure. Where we can't reach a quality bar we can stand behind, we'll tell you the feature isn't ready rather than ship a confident guess.
No lock-in by design. We treat the model as a swappable component behind your own retrieval layer and structured-output contracts, and we work across providers like OpenAI, Anthropic, Google Gemini, Azure OpenAI and AWS Bedrock so you can move if pricing, latency or policy changes. You own the same things you own everywhere else with us: the code, the prompts, the eval suite and the retrieval index over your data, handed over with documentation, so the feature isn't dependent on us or on a single vendor to keep running.
By default, no. We pseudonymise or abstract where needed and follow per-client rules about what may or may not leave your environment. For clients with stricter requirements, we can use self-hosted or tenant-isolated AI options, defined together during onboarding.
We use AI to accelerate research, UX exploration, coding, testing and documentation, under clear human-owned standards. Seniors still make the calls on architecture, security, trade-offs and what actually ships; AI reduces busywork and iteration time instead of replacing judgment.
Work with us
Building with AI & data engineering?
Tell us about your product and constraints, and we'll help you choose the right stack and a sensible first step.
Build faster with AI
Our playbook for integrating AI into product design and development workflows.
Download the playbook