How we work
How we work
A five-stage engagement with a decision at the end of each one, and a first stage designed so that stopping after it still leaves you better off.
The five stages
Each stage ends where you decide.
- 01
Frame
Work out what is actually being built, and whether it should be.
What the system has to do, which existing systems it touches, what data would have to move, and what would make it fail. Scoped and time-boxed.
Continue, change direction, or stop — with something useful either way.
Produces
- A written scope
- An architecture position
- A cost model
- A recommendation
- 02
Shape
Design the system and the seams between it and everything else.
Interfaces, data ownership, failure modes and the evaluation plan, agreed before code that would be expensive to unwind.
Exit criteria are signed off here, not negotiated at the end.
Produces
- Architecture decision records
- Interface contracts
- An evaluation plan
- Agreed exit criteria
- 03
Build
Working software in your environment from the first iteration.
Tested at the levels where tests earn their maintenance cost, and deployed through a pipeline you can see.
Progress is visible continuously, so there is no reveal at the end.
Produces
- Source and infrastructure in your accounts
- A deployment pipeline
- Tests and change history
- 04
Prove
Demonstrate the exit criteria rather than assert them.
Evaluation runs, load behaviour, security review, accessibility, and rehearsed failure — including the rollback.
Launch is a decision made against evidence, not a date.
Produces
- Evaluation results against the agreed set
- Security and accessibility findings
- A rehearsed rollback
- 05
Operate
Hand over a system the receiving team can actually run.
Instrumentation tied to service levels somebody agreed to, alerting that means something, and documentation written for whoever inherits it.
Ongoing support if you want it. No dependency if you do not.
Produces
- Dashboards and alerts
- Handover documentation
Delivery principles
Four rules that shape everything above.
- Scoping is done by the people who deliver
- The engineer who writes your architecture position is on the build team. There is no handover from a conversation you had to a team that was not in it, which is where most of the misunderstanding in this industry originates.
- Exit criteria are agreed before the build
- What "done" means is written down during design, when nobody is under deadline pressure. It is not renegotiated in the last week, which is when definitions of done normally get quietly loosened.
- Progress is visible continuously
- Work sits in your repositories and your tracker from the first iteration. There is no reveal at the end, because a reveal at the end means nobody could see the problems while they were cheap to fix.
- Evidence over assertion
- Launch readiness is demonstrated — evaluation runs, load behaviour, a rehearsed rollback — rather than asserted in a status meeting.
Your side of it
What the engagement needs from you
These are the things that, when missing, are the actual reason projects stall. It is worth knowing up front whether they exist.
- One person who can decide
- Not a committee. Someone who can settle a scope question in a day rather than a fortnight.
- Access to the systems involved
- Environments, data samples, and the people who know why a system behaves the way it does. Estimating around an inaccessible system is guessing.
- An honest account of constraints
- Compliance boundaries, an immovable date, a supplier contract, a political reality. Constraints stated early shape the design; discovered late, they invalidate it.
- A definition of success you believe
- Something specific enough to be measured after launch. If it cannot be measured, it cannot be delivered against.
Entry point
The lowest-risk way to start
The first stage runs on its own as an AI governance pre-audit: a scoped assessment of what AI is already in use across your organisation, where company data is going, and what would have to be true before the next system goes live.
It produces a findings report with severity, evidence and an owner for each item, plus a remediation sequence ordered by exposure. Those findings are yours regardless of what happens next — the engagement is designed to be useful even if it ends there.
Fit
Where Xcelerates is the wrong choice
Being clear about this early is cheaper for both sides than discovering it in month two.
- A large team mobilised at short notice. Xcelerates takes a small number of engagements at a time.
- A requirement led by the lowest available hourly rate. The commercial model is accountability for an outcome, not supply of hours.
- Managed IT, a help desk, or an outsourced CIO function. That is a different business.
- A proof of concept whose purpose is to exist rather than to lead somewhere. Demos are cheap to buy elsewhere.
Next step
Tell us what has to work.
Describe the problem in your own words — the system, the constraint, the thing that keeps not shipping. A senior engineer reads every enquiry and replies with a view rather than a brochure.
What happens next
A reply from an engineer
From someone who could scope the work. Not an automated sequence.
A conversation, not a pitch
Thirty to forty-five minutes on the problem and the constraints.
A written position
What we would do, what it would take, and whether we are right for it.