AI strategy · engineering · managed services
Most AI projects die between the slide and the system.
predictes takes AI work the whole distance: the assessment that decides what is worth building, the engineering that builds it, and the operations that keep it running once your people depend on it. On the cloud you already use or on an open-source stack you own.
- Strategy through to operations
- Multi-vendor and open source
- Fixed scope, short increments
We build on the platforms you already run, and on open-source stacks you can own outright.
- Amazon Web Services
- Open Source
Which one is right depends on what you already have, what your data may not leave, and what you would need to do if you wanted to move. We will tell you when the answer is the platform you are already paying for.
The model was never the difficult part
Three places where AI programmes stall, none of which is about the quality of the model.
A strategy nobody can act on
A maturity assessment, a list of use cases and a roadmap. All correct, none of it buildable, and six months later the organisation is exactly where it started with a better vocabulary.
A pilot that never becomes a system
The demonstration works. Then it meets real data, real permissions, real volumes and a real process with exceptions, and the distance from there to production turns out to be most of the project.
Nobody owns it after go-live
It ships, the team disbands, and nine months later it is quietly wrong and nobody has noticed. AI systems degrade differently from software: no crash, no error, just answers that stopped being right.
Frame, build, run
Three stages, bought separately. Most engagements start with the first and some correctly stop there.
- 01
Frame
Which decision or process is worth changing, what it would take, and what would measurably be different. Short, fixed-price, and yours to keep — including the version that says the answer is not AI.
- 02
Build
Working software against your real data, in short fixed-scope increments with something usable at the end of each. Your repositories, your infrastructure, your people in the room while it happens.
- 03
Run
Monitoring that catches a model drifting rather than a server falling over, defined response times, and a decreasing amount of us. If the engagement does not get smaller, one of us is not doing the job.
Twelve services along one path
From the first assessment to a system somebody operates. Each one can be bought on its own; most clients start with one and add the next.
Strategy and transformation
AI strategy, and the change work that decides whether any of it survives contact with the organisation. Where a programme is won or lost.
Agents and applications
AI agents engineering, spec-driven agent development, and the design and engineering of applications built AI-native rather than retrofitted.
Ontology and data
The unglamorous foundations: a model of your business that a machine can reason over, and pipelines that make the data trustworthy enough to reason from.
Workshops and training
Deliberate knowledge transfer, so your team ends up able to do this without us. Sessions built around your processes rather than a generic curriculum.
Managed services
Running what has been built, with monitoring designed for systems that fail quietly and response times written into the contract.
Field and factory
Deployment engineering where the work actually happens, and the context engineering a lights-out operation needs before it can run unattended.
Multi-vendor, because your situation is not a preference
Most companies are not starting from nothing. There is a cloud commitment, a licence estate, a data residency rule and a team that knows one platform better than the others. The right architecture follows from those constraints, not from what a supplier happens to resell — and we resell nothing, so there is no margin behind the recommendation.
- Commercial clouds. Azure, Google Cloud, AWS and IBM Cloud, used where they are already in place or genuinely the best answer.
- Open-source stacks. Where owning the system matters more than the shortest path, and increasingly where procurement requires it.
- Mixed is normal. A commercial platform for one workload and an open stack for another is the usual honest answer, and it satisfies nobody selling a single one.
- No reselling. No licences, no referral fees, no partner quotas shaping the design.
How an engagement is shaped
The structure of the contract predicts the outcome more reliably than the technology does. Long open-ended engagements accumulate momentum that outlives their usefulness, and fixed-price work on a vague scope produces a supplier defending a boundary instead of solving a problem.
- Short increments, fixed scope. Small enough to price honestly, short enough to stop, specific enough to evaluate.
- Something usable at each end point. Not a phase gate document — software somebody can try and complain about.
- Knowledge transfer written in. Documentation during the work, configuration in your repositories, your engineers pairing rather than reading summaries.
- An exit agreed at the start. What is handed over, in what format and within what window, decided while you still have leverage.
Frequently asked questions
What does predictes actually do?
Strategy, engineering and operations for AI systems. In practice: we work out what is worth building, build it against your real data, and then run it or hand it to your team to run. Twelve services covering that path, each available on its own.
What size of company do you work with?
From small and mid-sized businesses to enterprise. The work differs less than people expect — the constraints change but the failure modes are the same. What does change is the sequence, and a twenty-person company should almost never start where a two-thousand-person one does.
Do you resell cloud or licences?
No. Fees come from the work. That is a smaller business model than the usual one and it is the only structure in which our recommendation and your interest point the same way.
Can you work with the platform we are already on?
Usually that is the right answer. Existing commitments, skills and data rules are real constraints, and a proposal that ignores them to arrive at a cleaner architecture is a proposal that will not be adopted.
How quickly can something be running?
The framing is typically days rather than weeks. First working software against your data is usually weeks rather than months, because increments are kept small enough that being wrong is cheap. Anything longer than six weeks without something usable is a warning sign, including from us.
What happens when the model starts being wrong?
That is the part most projects have no answer for, so it is designed in from the start: monitoring built for quiet failure rather than crashes, a decision log that makes an incident reconstructable, and an agreed path to reduce the system's autonomy while it is investigated.
Who owns the code and the data?
You do. Code in your repositories, data in your infrastructure, models and prompts documented as deliverables. The exit terms are agreed at the start, because on a system that touches your operations that clause matters more than the day rate.
How do we start?
One conversation about a decision or a process that is currently slow, expensive or unreliable. If there is something worth doing, the framing engagement scopes it. If there is not, we will say so — that answer costs an hour and saves a programme.
Tell us which process is costing you the most
One conversation, no deck. If AI is the wrong tool for it, that is a useful answer and you will get it in the first hour rather than the third invoice.
We reply from info@predictes.com, usually within one working day.