Discovery and scoping
What the paid discovery sprint contains, what it costs relative to the build, and what you keep.
Read about discovery and scopingHow we work
How we work
Enterprise software fails on process more often than on code. The common causes are an estimate given before anyone understood the integrations, a scope that moved without anyone pricing it, and a delivery structure nobody could see into.
This section sets out how we avoid each of those, in enough detail that your procurement and security teams can assess it without a call.
Engagement lifecycle
From first conversation to steady state
01
Qualification
A one-hour technical conversation, not a sales call. We establish what the problem actually is, which systems are involved, what has already been tried, and whether the budget and the ambition are within range of each other. If we are the wrong supplier we say so at this point, and we will usually say what kind of supplier is right.
02
Discovery and scoping
A fixed-scope, fixed-fee sprint producing an architecture document, an integration map, a phased estimate and a risk register. It is deliberately small, it is credited against the build if you proceed, and its output is yours to take to another supplier if you do not.
03
Contracting
Your contract is with the UK entity under English law. You choose the engagement model: fixed-scope phases, a dedicated team, or augmentation of an existing team. Data processing terms, IP assignment, security schedules and, where relevant, escrow are agreed before mobilisation rather than after.
04
Mobilisation
Pod assembled and named, environments created, repositories set up in your tenancy where you want them, access reviewed, and the first sprint planned. Mobilisation typically takes two to three weeks from signature and is visible to you throughout.
05
Delivery
Two-week iterations against the agreed architecture. Working functionality in a staging environment every fortnight, a written sprint report, and a change log that shows what moved and why. Scope changes are priced and approved individually, not absorbed silently and recovered later.
06
Release and run
Production release with monitoring, alerting, rehearsed restore and runbooks in place. After go-live, support runs to defined response times with a standing change budget, so the system continues to change with the operation instead of freezing on the day it launched.
In detail
Four pages your procurement team will want
Engagement models
Fixed-scope phases, dedicated team and staff augmentation compared on contract shape, minimum term, change handling and rate bands.
Read about engagement modelsDelivery model
The UK, Germany and Pakistan structure: contracting entity, leadership location, pod composition, overlap hours, escalation and data transfers.
Read about delivery modelSecurity and compliance
Insurance, certification and regulatory position, stated as verified or unconfirmed rather than implied.
Read about security and complianceGovernance
What you see while work is in progress
You get direct access to the repository, the board, the staging environment and the pod. There is no account manager filtering technical questions: your architect talks to our architect. Weekly, you receive a written status covering completed work, work in progress, blockers with owners and dates, and any change to the phase forecast.
Escalation has two defined steps and named people at each, with response times agreed in the contract. We would rather report a slipping date in week three than explain it in week nine, and the reporting cadence is designed to make that the path of least resistance.
Tell us what your systems are doing wrong.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us