Consulting that starts with the work, not the technology
You do not need a finished AI strategy before talking to us. You need a problem worth solving. Everything else — the model, the hardware, the deployment shape — is downstream of that, and choosing any of it first is how projects end up expensive and unused.
The discovery conversation
Almost every engagement starts the same way, with a handful of questions that have nothing to do with AI:
- What work are people doing manually?
- What information do you already have, and where does it sit?
- What data cannot leave your network?
- What data can be processed elsewhere?
- How quickly does the result actually need to be available?
- What systems need to receive the result?
- How much human review is appropriate given the consequences?
- What happens when a better model becomes available?
The answers determine the architecture. Frequently they also determine that one of the three things you were considering is worth doing and the other two are not, which is a useful outcome by itself.
What we actually deliver
Engagements are shaped around what you need rather than sold as tiers, but the work tends to fall into these:
Discovery and architecture
- Workload evaluation
- Privacy boundary definition
- AI architecture
- Pipeline design
- Model evaluation
- Infrastructure planning
- GPU and hardware sizing
- Cost modelling
Implementation
- Local model deployment
- Processing pipelines
- Worker development
- Search and index build
- Integration with existing systems
- Data migration
- Custom automation
- Infrastructure setup
Ongoing
- Software and model updates
- Security patching
- Monitoring
- Job and queue management
- Storage and backup
- Performance tuning
- Workflow improvements
- Integration support
Second opinions
A specific and useful thing we get asked for: you have a vendor proposal, or an internal plan, and you would like somebody with no stake in it to look at whether the numbers make sense.
Common findings, in roughly descending order of frequency:
- Hardware sized for real-time when the work is overnight batch
- A per-seat SaaS price for a job that runs four times a month
- An architecture that depends permanently on one vendor's API
- No answer to "where does the data go" beyond "our cloud"
- A chatbot proposed for a problem that is really a search problem
- Nothing about what happens when the model is deprecated
Rescuing a pilot
The other common starting point: something works on one person's machine, everyone is impressed, and it has been stuck there for eight months.
Turning that into production is mostly unglamorous engineering — job queues, failure handling, storage, monitoring, access control, updates, and a normalized output format so the next model change is not another eight months.
It is also usually less work than rebuilding, because the hard question — is this useful? — has already been answered by the pilot.
Start with the planner
Four questions and a first answer on placement and hardware, with no contact details.
Try itCompare deployment models
On-premises, managed private, hybrid and cloud, with the trade-offs stated.
Read moreRead the FAQ first
Most of the early questions about hardware, cost and data location are answered there.
Read moreWhat would you use AI for if your data stayed under your control?
Tell us what you are trying to accomplish. We will help work out what should run locally, what can run elsewhere, and what technology actually makes sense.