Pay for the weeks you need the people
Roadmaps are lumpy. Hire for the peak and you pay for idle capacity; hire for the average and every deadline slips. We hold the bench so you do not have to.
The bench is ours, not yours
A release needs six people for a month and two for the quarter after. Carrying that peak permanently is expensive; hiring into it takes longer than the peak lasts.
Because our people move between engagements rather than sitting idle between them, the ones who leave your project are the same ones who come back to it. Continuity survives the ramp down, which is the part most staffing arrangements lose.
Three commercial shapes
Clients move between them as the work changes. Several have used all three.
Embedded team
We own a product, or a slice of one
A named lead is accountable for delivery. Team size moves with the roadmap, agreed a sprint or a month ahead. This is most of our long-running work, including every multi-year engagement on this site.
- Right when
- You want an outcome and do not want to manage individuals.
- Billed
- Monthly, against an agreed team shape.
Time and materials
Named people, your process, your board
People work to your standups, your definition of done and your release process. You direct the work; we handle employment, cover and continuity when somebody is ill or leaves.
- Right when
- You already know what you want built and need throughput.
- Billed
- On time spent, at agreed rates.
Support retainer
Cover for something already live
An agreed response time on the hours your business runs. Usually staffed by people who worked on the build, which is what makes the response useful rather than procedural.
- Right when
- The system is live and downtime has a cost you can name.
- Billed
- Monthly, on hours covered and response time.
How an engagement starts
Small first. Every long engagement on this site began as a piece of work someone could cancel after a month.
A call with an engineer. We work out whether this is work we are good at, and say so if it is not.
A short shaping exercise: what exists, what is constraining it, and what the first shippable slice is. Paid if it needs code reading; free if it is a conversation.
A named team starts. Small — usually two or three people — so the first delivery proves the working relationship before anyone scales it.
Team size is reviewed against the roadmap, not the contract. Ramping up takes about a fortnight; ramping down takes a conversation.
Things worth knowing before you ask
Where is the team based?
India, in Bengaluru. We work substantial overlap with UK and European hours — most of our clients are in those timezones and have been for years.
Who owns the code?
You do, from the first commit. We work in your repository wherever possible. There is no licensing arrangement and nothing to buy out at the end.
What happens when someone leaves?
Cover is our problem, not yours. On engagements running seven years we have replaced people without a gap in delivery — that is the difference between a team and a contractor.
How quickly can you start?
A small team, usually within two to three weeks. Scaling an existing engagement up is faster because the people already know the system.
Want to talk about the shape rather than the price?
Tell us what the next six months look like and where the lumps are. The commercial model usually follows from that.