How we work
From unclear requirement to production release.
We start in the environment the software has to run in, agree the result and its owner, ship weekly against real constraints, and hand over the code and the runbooks.
Start here
Every department mapped. One problem already built.
Most companies know they need AI and cannot say where. The first week tells you where it pays, ranked by value against difficulty. The second week builds the top one, so you finish holding working software rather than a recommendation.
If there is no working prototype at the end of day ten, there is no invoice.
Start a Deployment Brief- Days 1–2MapStructured conversations across every department. Where work stalls, what is still done by hand, and what people have quietly built to work around it.
- Days 3–4RankWe turn that into a ranked list, scored on value against difficulty. It includes the problems we would leave alone, and why.
- Day 5ChooseYou and your sponsor pick the first target. We tell you which one we would pick, and where the map disagrees with what we were told at the start.
- Days 6–9BuildReal access to your systems, time with the people who run the chosen workflow, and a first working slice against your real data.
- Day 10Hand overA working prototype, the ranked backlog of everything we did not build, a fixed-price sprint quote, named owners and acceptance criteria.
From AI idea to daily use
AI becomes useful inside the workflow.
We connect models to company data, business rules, existing systems and the people responsible for the result.
The deployment loop
Diagnose. Embed. Build. Deploy. Transfer.
A clear path from an unresolved requirement to software running in production.
- 01
Diagnose
Document the workflow, system access, decision owners and success metric before code begins.
Deployment brief and acceptance criteria - 02
Embed
Join your standup, your tools and your delivery cadence. We are reachable during your working hours, not batched over email.
Named owners, system access and delivery cadence - 03
Build
Release working increments against your real data and actual constraints every week.
Working software in the target environment - 04
Deploy
Integrations, permissions, monitoring, testing and operator training completed before release.
Production release and monitoring - 05
Transfer
Hand over the repository, runbooks, system knowledge and prioritised backlog to the team that will own it.
Runbooks, training and clear ownership
How we work
Forward deployment is a behaviour, not a job title.
Five things that are either happening on your engagement or they are not. If any of them stops being true, you are no longer getting what you paid for, and you should tell us.
Customer-owned from day one- We work in your systems
- Your repository, your cloud, your accounts. Nothing is built in a private environment of ours and handed over at the end.
- We are in your working day
- Your standup, your Slack or Teams, your cadence. Reachable during your hours, not batched into a weekly status email.
- We own an outcome, not a ticket queue
- Every engagement has one production release, one named owner and written acceptance criteria agreed before work starts.
- We ship weekly against real data
- Working software every week on your own data and constraints, never a demo environment or a spec review.
- We hand it over and leave
- Code, IP, runbooks and system knowledge transfer to your team. The engagement is designed to end.
What we need to begin
You don’t need to know where AI goes yet.
That is what the first week finds. What we do need is someone who can open doors across departments, and a business willing to act on what the map says.
- An executive sponsor who can open doors across departments
- Access to department heads and the people doing the work
- A result the business cares about: revenue, cost, speed or risk
- Willingness to act on what the map says, including where it disagrees with you
Straight answers
The questions buyers actually ask.
No. That is the normal starting position, and it is what the first week of the brief is for. You do not need to arrive with a named project. You need a sponsor who can open doors across departments, and the willingness to act on what we find. If you already knew where AI paid in your business, you would not need the map.
Consultants interview a handful of leaders and hand you a deck. We talk to every department, rank what we find by value against difficulty, and then build the top one before you have signed anything else. You end the two weeks holding working software rather than a slide about it.
An outsourced team takes a specification and returns code. We take a business outcome and own it to production. In practice: we work inside your repository and cloud rather than ours, we join your standup rather than sending status reports, we agree written acceptance criteria before any code is written, and we ship working software against your real data every week. If any of those is not happening, you are not getting forward deployment and you should say so.
Forward deployment is defined by where the work happens, not where the chair is. The engineer operates inside your systems, your data and your team's working day, on a weekly production cadence. We travel on site when a workflow can only be understood by watching it in person, and for engagements where that is essential we say so before we start.
The first week goes wide. Days one and two we hold structured conversations across every department about where work stalls and what is still done by hand. Days three and four we rank what we found by value against difficulty. Day five you and your sponsor choose the first target, and we tell you which one we would pick. The second week goes deep: days six to nine we get real access and build a first working slice against your real data, and on day ten you get the prototype, the ranked backlog of everything we did not build, a fixed-price sprint quote and acceptance criteria. If there is no working prototype at the end of day ten, there is no invoice.
You do, from the first commit. Work happens in your repository under your accounts. At handover you receive the code, the runbooks, the evaluation suite and the operating knowledge required to run and change the system without us.
A single workflow typically reaches a production release in four to six weeks after the brief. The constraint is almost never the model. It is system access, permissions and the approval path, which is what the brief exists to find before anyone commits to a delivery date.
The engagement is deliberately staged so that the cheapest step comes first. The brief is ten days and credited in full if you continue. The sprint has written acceptance criteria agreed in advance, so 'working' is not a matter of opinion. If a workflow turns out not to be worth deploying, the brief is where we tell you that.
Every department. Ten days. Fixed price.
Find out where AI actually pays.
Tell us roughly where the business hurts, or that you are not sure yet. That is the usual answer. If it is a fit, we start with a ten-day brief and you keep everything we build in it.