How We Work
Most outsourcing worry is not about skill, it is about control: who reports to whom, on what schedule, through which tools. This page answers that directly. Three engagement models, one communication cadence, and a governance rhythm sized to the work rather than sold as one fixed package.
Pick the model that matches your risk
A dedicated team extends your own department under your direction. A fixed-scope project hands a defined outcome to one accountable lead against a set price and date. A managed outcome sits between the two, priced against results with delivery detail left to the team. None requires you to change how your own organisation is run.
Dedicated team
Engineers join your sprint ceremonies and report to your product owner, functioning as headcount you did not have to recruit.
Fixed-scope project
One accountable lead carries a defined build to a fixed date and price, with scope changes priced before they are accepted.
Managed outcome
Payment tracks an agreed result rather than hours worked, and the team decides its own delivery detail against that result.
What actually changes between the three models
Four dimensions decide which model fits: who directs the work each day, how scope changes are absorbed, what shape the pricing takes, and how the engagement ends. Everything else — the engineers, the review discipline, the reporting rhythm — stays identical across all three.
| Dimension | Dedicated team | Fixed-scope project | Managed outcome |
|---|---|---|---|
| Who directs day to day | Your product owner | Our accountable lead | The team, against the result |
| Scope changes | Absorbed in your backlog | Priced before acceptance | Renegotiated against the outcome |
| Pricing shape | Per engineer, per month | Fixed price, fixed date | Tied to the agreed result |
| Reporting rhythm | Inside your ceremonies | Milestone reviews | Outcome checkpoints |
| How it ends | Notice period, engineers roll off | Acceptance of the defined scope | Result delivered and verified |
| Best fit | You run delivery well, need capacity | The outcome is definable up front | You want the result, not the process |
A rhythm you can set your watch by
Every engagement opens with a short onboarding that maps your tools, your approval chain and your definition of done before any code is written. After that a sprint or milestone cycle repeats on a fixed calendar, with a demo or review at the end of each one. Nothing about progress is left for you to chase.
01Before work startsOnboarding sets the map
Access, tooling, coding standards and the approval chain are agreed up front, so the first sprint runs on your terms rather than a generic default.
02Every cycleA fixed demo or review
Working software is shown on a set calendar date, not promised for later. What shipped and what slipped are both named in the same meeting.
03Whenever it mattersOne escalation path
A named lead is reachable outside the sprint rhythm for anything that cannot wait for the next scheduled review, with no ticket queue in between.
04On the schedule you setReporting that matches your governance
A weekly note suits a small team; a steering pack with budget and risk suits a programme. The format is agreed once and then held to.
A team that joins your process
Engineers work inside your existing stack: your repository, your ticketing system, your chat channel and your deployment pipeline, rather than a parallel set that gets reconciled later. Access follows your own security policy and least-privilege rules, requested and revoked the same way it would be for an internal hire. The aim is a team you can manage exactly as you manage the rest of engineering.
Your tooling, not a parallel set
The repository, ticketing system, chat channel and deployment pipeline already in use stay in use. Nothing gets stood up twice for a visiting team to reconcile later.
Your approval chain
Code review, release sign-off and change approval route through whoever already holds that authority on your side, not a parallel process invented for the engagement.
Your definition of done
Tests, documentation and handover expectations follow the standard your own team already works to, rather than a lighter one assumed for outside engineers.
Two places this page leaves for others
The operating process above is deliberately silent on two things covered elsewhere: how AI tooling is used inside delivery, and the measured record this practice can point to. Both get a fuller treatment than a paragraph here could manage.
How AI is used inside delivery
Code review assistance, test generation and the human gates that keep both accountable, described as an engineering stance rather than a sales pitch.
The measured delivery record
Cycle time, defect rates and the other numbers a sceptical buyer would ask a delivery partner to defend, published with their evidence standard attached.
A cadence clients can set a clock by.
The proof standard here is a reporting record a client would actually recognise: real cadence, real milestones, real accountability. These previews carry that pattern while written approvals are collected.
Explore case studies
A fixed-scope rebuild that never missed a milestone review.
Aster North needed a rebuild delivered against a fixed date without losing sight of quality. A four-week milestone cycle with a standing demo kept the board briefed throughout.
- Milestone reviews held on the scheduled date
- Every one
- Scope changes priced before acceptance
- All of them
I always knew what shipped and what slipped, in the same weekly note, without asking twice.
Sample · pending client approval
Asked before the first sprint starts.
01Which engagement model should we start with?
Match the model to how much of the decision you want to keep. A dedicated team suits ongoing product work you already direct. A fixed-scope project suits a defined build with a hard date. A managed outcome suits a result you can specify but do not want to manage day to day.
02Can we change engagement model partway through?
Yes, and it happens often. A fixed-scope project frequently becomes a dedicated team once the first build proves out, or a dedicated team narrows into a fixed-scope piece for a specific release. The transition is priced and documented rather than assumed.
03Who do our engineers actually report to day to day?
On a dedicated team, your own product owner or engineering lead. On a fixed-scope or outcome engagement, one named lead on our side who is accountable to you for the result and reachable outside the standing cadence.
04What tools do you expect us to already have?
None specifically. Engineers join whatever repository, ticketing system and communication channel your organisation already runs, rather than asking you to adopt a new toolchain to accommodate the engagement.
05How much of our time does the cadence actually require?
A short onboarding at the start, then attendance at the standing demo or review for each cycle. Day-to-day questions route to the named lead rather than back to your team, so the time cost stays predictable.
06What happens if a milestone is at risk?
The named lead raises it the moment it becomes visible, not at the next scheduled review, with a stated cause and a proposed recovery. Surprises at the review meeting are treated as a process failure on our side.
07Do you work across multiple time zones?
Engineering runs from India with agreed overlap into UK, EU and US hours, set per engagement rather than promised as a blanket policy. The overlap window is agreed before the cadence is finalised.