How we work
Four steps. You can stop after any of them.
Deliberately lighter than a system integrator’s method. The work is the same; the ceremony around it is not.
01
Assess
Two weeks
- What happens
- We sit with the people who do the work and watch them do it. We look at your systems, your data and the licences you already hold — often the answer changes once we know what you are already paying for.
- What we need from you
- Two or three hours of your team’s time, spread across the fortnight. Read-only access to the systems in scope.
- What you end up with
- A shortlist of candidate tasks, each with an estimated cost, an estimated benefit and a recommended stack. Plus the ones we think you should not automate, and why.
02
Prove
Three to four weeks
- What happens
- One task from the shortlist, built for real. Your data, your environment, your users. Success criteria are written down and agreed before the first line of it exists.
- What we need from you
- A named person who can answer questions and a small group willing to try it.
- What you end up with
- Something working, and a number against the criteria. If it misses them, we say so and it ends here.
03
Build
Six to twelve weeks
- What happens
- Iterations of one to two weeks, each ending in something you can use. Permissions and data boundaries are settled first. Error handling, monitoring and alerting go in before scale, not after it breaks.
- What we need from you
- A half-hour review at the end of each iteration. Someone from your side alongside us, so the knowledge does not all leave when we do.
- What you end up with
- A running system, documentation, and a handover to whoever owns it next.
04
Run
Monthly, cancellable
- What happens
- Monitoring, incident response, and keeping up with the platform and model changes vendors ship underneath you. A fixed capacity each month for changes.
- What we need from you
- Nothing, most months.
- What you end up with
- It still works in a year. A quarterly note on what it has actually saved.
Two things that run through all four
Security is decided first, not retrofitted
What the agent may read, what it may write, and which systems it may touch are settled before anything is built. Retrofitting permissions onto a working agent means rebuilding it.
Your people are in it from the first iteration
Adoption that starts at go-live does not happen. The people who will use the thing see it while it is still ugly and still changeable.
Why a small company can deliver this
Every build runs through the same documented pipeline: intake, architecture, estimate, build, package validation, deployment and transfer. It was written over a series of enterprise agent programmes and it is the reason the same work does not get re-invented on each engagement.
The practical effect is an environment-variable seam through everything. Moving from a demo to your production tenant is a configuration change, not a second build. That is where most of the cost difference against a large integrator comes from.