A fixed-scope implementation sprint against agreed acceptance criteria. You receive working code, tests, measured results and a handover your team can maintain.
A sprint is the right shape when the problem is understood well enough to write acceptance tests: a recovery and permissions layer that must exist before launch, an integration that is blocking a customer contract, a workflow step that needs automating, or a measured bottleneck that needs removing.
The scope is written down before work begins, including what is excluded. Delivery happens in your repository and environments wherever possible, with short demonstrations against the acceptance scenarios rather than status reports. When the sprint ends, the code, tests, runbook and design decisions are handed over to the team that will own them.
Sprints often follow a readiness review, but well-defined work does not need one. A connector with a clear contract, or an optimisation with an agreed benchmark, can be quoted directly.
The agreed change, merged or ready to merge in your repository, following your conventions and review process.
Automated tests for the acceptance scenarios, including the failure and recovery cases, runnable in your CI.
Before-and-after figures for the measures named in the scope, with the method used to obtain them.
Runbook, configuration notes, known limitations and a walkthrough with the engineers who will own it.
Confirm the acceptance criteria, exclusions, environments and owners. The scope and fee are fixed in a written statement of work.
Implement the narrowest working path first, then extend it, demonstrating against acceptance scenarios as each one passes.
Run the agreed tests and measurements, including failure injection and rollback where the scope requires them.
Transfer ownership with documentation, a walkthrough and an agreed period for questions.
The demo works. Now it has to launch.
Common follow-on →Stabilise an AI project that is losing confidence
Common follow-on →Make a demanding workflow shorter and dependable
Common follow-on →AI tools are bought. Now make them useful.
Usual first step →Give security something it can approve
Usual first step →Yes, and that is the default. A sprint changes the components that limit the outcome. Replacing a framework is only recommended when the evidence shows it is the constraint.
Neul Labs is accountable for the whole scope. The founder leads architecture and acceptance; where a specialist is needed, they are named in the statement of work and work under the same scope and standards.
We stop and agree a change in writing rather than quietly expanding the work. If the sprint reveals that the original assumption was false, that finding is itself documented and handed over.
No. Public components are options to assess on their merits, under their own licences. Many sprints use none of them.
Other engagements: readiness or feasibility review · embedded senior ai engineering · ongoing engineering support. Compare them all on the engagements overview.
£15,000–£35,000, fixed in writing · 2–6 weeks
Ask about this engagement