Delivery team
Who will actually work on your project
Small, senior, and named before the work starts. This page sets out how a project team is put together, what each role decides, and why nobody is moved off your build part-way through a phase. The staffing question that matters is not how many people a firm has. It is which ones you get, and for how long.
- A release lands in your repository, with a change log that says what moved and why.
- Your staging environment is updated, loaded with your own records.
- Your delivery lead walks your team through it on the call and takes the next week's priorities.
Who is accountable for all of that is set out on our leadership and accountability page.
- Projects delivered
- 720+Since 2014, for more than 680 clients across 21+ countries.
- To working software
- 30 daysAn end-to-end path on your own data, in a staging environment you can log into.
- Release cadence
- WeeklyThe system is judged on use rather than on a status report.
- People swapped mid-phase
- 0You are told who is on your project, and you keep them.
Roles on a build
Who is on a project team, and what does each role decide?
Four roles, and one of them is yours. A named delivery lead owns the relationship and the schedule, the engineers building the system own the technical decisions, review decides what is fit to ship, and a named owner on your side owns the business decisions we cannot make for you.
| Role | Decides | What you get from them |
|---|---|---|
| Delivery leadScope, sequence, and what ships this week. | Scope, sequence, and what ships this week. | One person on your weekly call who sat through discovery and stays until handover. |
| Engineers on the buildThe stack, the data model, and how it is tested. | The stack, the data model, and how it is tested. | Working software every week, with the reasoning written into your repository. |
| Review and testingWhether a release is fit to reach your staging environment. | Whether a release is fit to reach your staging environment. | Releases exercised against your own records rather than against sample data. |
| Your named ownerPriorities, sign-off, and access to your people. | Priorities, sign-off, and access to your people. | The decisions only your business can make, made in the week they are asked. |
What review and testing actually covers is written up under how we test what we ship.
Sizing
How big is the team, and does it change during the project?
It is sized to the phase and it is small on purpose. Discovery is the delivery lead and the engineers who will build the thing; capacity is added later only where a genuinely parallel track exists. What does not change is the delivery lead, who is the same person from the first discovery session to handover.
- Days 0-10
Discovery
The delivery lead and the engineers who will build it, working from your actual workbooks, forms and job history. There is no separate discovery team to hand over from.
- Days 10-30
First working slice
The same people build one end-to-end path on your own data. The team does not grow before there is something for it to grow around.
- Days 30-60
Build out against real use
Capacity is added only where a genuinely parallel track exists. Adding people to a single track makes it slower, not faster, and we will say so.
- Days 60-90
Cutover and handover
The team narrows again for the parallel run and the data migration. The delivery lead closing it out is the person who opened day one.
The same delivery lead runs day 0 and day 90. Everything else is sized to the phase.
What happens inside each of those windows is described on the about page, and the commercial models that pay for them are compared on our pricing page.
Continuity
What can you check every week, without asking us?
Three things, all of them in accounts held in your company's name. Continuity is a property of where the work lives, not of who happens to be available on a given Tuesday, so if any one person went quiet you would still be able to see the state of your project for yourself.
- That week's release
- In a repository held in your company's name. You can see exactly what changed without asking us for a report.
- The staging environment
- A URL you log into, loaded with your own records. The test is whether your team can do their job in it, not whether a demo runs.
- The written decisions
- Why the data model changed, what an integration really does, which option was rejected and why. Recorded as it happens, in the same repository.
This is the same argument we make about your existing systems, turned on ourselves: nothing important should live only in one person's head, including ours.
Honest limits
What are we not?
We are not a body shop and we do not run a bench. You will not be shown a stack of CVs, handed to a different team after the sales call, or given a junior to protect a margin. The trade is real and worth stating plainly: we cannot absorb unlimited parallel work, and a start date is a constraint we will tell you about rather than work around.
| What a body shop does | What we do |
|---|---|
| Sells you headcount. | Scopes an outcome first, then staffs it. |
| Rotates people between accounts to keep utilisation up. | Keeps the same people through a phase, and tells you who they are. |
| Sends a senior to the pitch and a junior to the project. | The person who scoped your build is the person on your weekly call. |
| Holds the code, the credentials or the hosting. | Opens the repository and the cloud accounts in your name in week one. |
| Quotes any scope, any stack, any start date. | Says no to work outside what we can support, and gives you a real start date. |
Before you sign
Questions about who does the work
These are the staffing questions that come up on a first call, answered here rather than saved for the meeting.
Why is there no photo roster on this page?
Because the roster that used to be here was invented: fifteen names and job titles attached to stock photographs. We would rather show you how a project is actually staffed than a grid of faces. When real profiles are published here they come from our own records, and either way the people on your project are named to you during discovery.
Will the people I meet be the people who build it?
Yes. The delivery lead who runs discovery stays through handover, and the engineers named at the start of a phase finish that phase. If a role genuinely has to change, you are told before it happens and the handover is written down rather than passed on in a conversation.
How do you protect our data while people are working on it?
We work from anonymised or masked extracts wherever the work allows. Production access is requested in writing, granted to named individuals at the least privilege the task needs, logged while it is in use, and revoked at handover. Your data is not used to train third-party AI models.
What if we need more capacity than you have?
We tell you. Work that genuinely needs a large parallel team is a poor fit here, and we would rather say so than staff it thin. Where the constraint is temporary, staff augmentation billed per engineer per month is one of the four commercial models we run.
What happens to the team at handover?
The engagement ends with the system running and the source code, the data, the credentials, a written runbook and a recorded walkthrough in accounts you control. Continuing support is a separate agreement with the cover written into it, not an assumed retainer.
Are you hiring?
Open roles, when we have them, are listed on the careers page. We would rather leave a seat empty than put someone on a client project before they are ready for it, which is part of why the team stays small.
More answers sit on the general FAQ, and open roles, when we have them, are on the careers page.
Next step
Talk to the people who would build it
Thirty minutes with the person who would scope and lead the work, not a salesperson. You will leave the call knowing who would be on your project, when they could start, and whether the thing you want is worth building at all.
If you would rather read first: who is accountable on an engagement covers escalation and continuity, the Construction Quotes case study shows a finished system we handed over, and where to start helps if the scope is still open.
Need a consultation?
Drop us a line - we're here 24/7 to answer your questions and discuss your project ideas.