Software engineers, plus the person who runs them
You get the remote development team and the delivery lead in one engagement, so sprints, standups, code review and reporting belong to us. When a date moves, one named person tells you.
Tell us what needs building
Describe the work, the stack and when you need people. We usually reply within 24 hours, with a shortlist and a call.
Where the week actually goes
Not one of these hours is spent building anything, and all of them are yours.
Writing the work before anyone can start
every ticket has to be specific enough to hand over. Only you know what specific means here.
Chasing the answer
a question asked at four in the afternoon gets answered tomorrow. The work sits still until it does.
Reading the code
you are the person senior enough to review it. The queue waits for the hour you find.
Rebuilding the plan
one item slips and the rest of the order has to be redone, again, by you.
The date you already gave
someone is holding you to it. You picked the people, so there is nobody else to point at.
If that is your week, the thing to buy is not more hands. It is the job itself.
The worry underneath this is reasonable. Software engineers plus somebody to run them reads like two bills where you expected one. So it is worth being exact. The second one is not supervision added to your week. It is a set of jobs moving off it. Here is the split, activity by activity.
What leaves your week, what stays your call
| Activity | Who does it now | Who does it under this engagement |
|---|---|---|
| Turning what you want into sprint-sized work | Who does it nowyou, usually late at night | Who does it under this engagementus, before the sprint opens |
| Running the daily standup | Who does it nowyou, or nobody | Who does it under this engagementus, with a coordinator where a live one is needed |
| Chasing the person who has gone quiet | Who does it nowyou, across time zones | Who does it under this engagementus, inside the working day |
| Reviewing the code before it merges | Who does it nowyou, or whoever is senior enough | Who does it under this engagementa senior software engineer, with CI gating the merge |
| Deciding what gets built and in what order | Who does it nowyou | Who does it under this engagementstill you |
| Pricing a change and writing it up | Who does it nowyou, from memory | Who does it under this engagementus, as a change note |
| Approving that change | Who does it nowyou | Who does it under this engagementstill you, in writing, before it enters the plan |
| Telling you the date has moved | Who does it nownobody, until it already has | Who does it under this engagementone named person, in the week the risk appears |
| Deciding what gets cut to protect the date | Who does it nowyou | Who does it under this engagementstill you, with our recommendation |
| Judging whether the result is right for your market | Who does it nowyou | Who does it under this engagementstill you, always |
The pattern is simple. Everything that is production goes to us. Everything that is a decision stays with you. We bring you what you need to make it. We do not make it for you.
The Project Management Institute publishes an annual survey called Pulse of the Profession. Its 2021 edition asked 3,950 project professionals about projects completed inside their own organisations. It tracks three outcomes side by side. Did the project meet the goal it was set. Did it hold the budget. Did it land on the date it was promised. Across 2019, 2020 and 2021 all three improved. Landing on time stayed the hardest in every one of those years.
Show data table
| Dimension | 2019 | 2020 | 2021 |
|---|---|---|---|
| Met the original goal | 68% | 69% | 73% |
| Held the original budget | 57% | 59% | 62% |
| Landed on time | 51% | 53% | 55% |
Landing on time sits below both other outcomes in every year measured.
That is the yardstick worth carrying into whatever you have already promised. The date is the outcome under most pressure. That holds on ordinary projects run by professionals, not only on troubled ones.
The same Project Management Institute survey asked what actually went wrong. In the 2021 edition of Pulse of the Profession, roughly one project in three had its scope move during the work. About one project in eight was called an outright failure. So the likeliest thing to happen to the work you commission is not a collapse. It is a series of small movements. Each one is defensible on the day. Together they add up to a date you can no longer hold.
Show data table
| Item | Value |
|---|---|
| Scope moved during the project | 34% |
| Budget lost on a failed project | 35% |
| Called an outright failure | 12% |
Scope moved on about one project in three. Being called an outright failure was rarer, at about one in eight.
That changes what is worth insuring against. A team that promises heroics is answering the rare case. What you want is something that notices a small movement in the week it happens. And puts it in front of you while there is still room to choose.
Handing over the management of the work sounds like handing over the steering wheel. It is not, and the reason is a single document. Every change to what was agreed becomes a change note, and a change note has a fixed path.
Nothing enters the plan until you sign it off
The path every change to the agreed work takes, in this order, every time.
- Raised
someone spots that the work has to change, which may be us, your team or a customer. It is written down the day it comes up.
- Costed
you get a change note carrying the time, the effort and the cost. Nobody is asked to approve anything before that.
- Yours to decide
you read the note and say yes, no, or not now. No answer costs you anything.
- Signed off
if you agree, we record it in a meeting and in writing. There is one version of what was agreed.
- In the plan
only then does the schedule move. Until then the build carries on against what you already approved.
The point of writing it down this way is that it constrains us and not you. Nothing in the build moves on a change you have not accepted. So the estimate you were given cannot drift underneath you.
We will not promise you a project without surprises. Nobody who has run this work can. What we will put in writing is when you find out.
When it slips
We find out the date moved too late to act
Most engagements get this wrong, and it is not usually dishonesty. Nobody has been made responsible for saying it early.
What we commit to
When something changes, you hear about it three weeks early, not three days late. When a timeline comes under risk, you hear it in the week the risk emerges. Not the week before delivery
The team is asleep when we need an answer
The overlap is real and it is limited. We agree it at scoping rather than letting you find it in week two.
What we commit to
The team works IST 10:00 to 19:00, which is 04:30 to 13:30 UTC. Every developer is currently in India. European teams get substantial afternoon overlap. North American teams sit outside it for most of their day. A coordinator can host a live standup
We send a brief and hear nothing back for a week
A slow first reply predicts a slow engagement. Hold us to this one from the first message.
What we commit to
We usually reply within 24 hours. A shortlist typically follows within a few days of your brief. Everything you share stays private
Get the overlap in writing
Send the work and the hours you need covered. We typically come back within 24 hours with a shortlist and a time to talk.
How the work gets checked
Gate the merge
Every change is reviewed before it lands
Every change goes through code review by a senior software engineer, with GitFlow, unit and integration tests, and a CI/CD pipeline that gates every merge. None of that depends on anyone on your side being awake to catch it, which is the point.
Write it down
Architecture decisions outlive the person who made them
Architecture decisions are documented in the technical requirements document as they are taken. That is what makes a handover survivable later. Ask why something was built that way and there is an answer, not a guess.
Agree first
Requirements read back before code
We translate before we build. Every requirement document is reviewed with you in plain English first. What gets built is what you meant, not what a document could be read to say.
Be wrong early
You can falsify us inside three weeks
The first two to three weeks is a pilot. The evaluation criteria are written into the engagement before the software engineer starts. If they are not met we replace the software engineer and run the pilot again against the same criteria.
More on how we build and review software.
Two things usually get asked at this point. Whether we have done this at any size, and whether we will still be here in a year.
What we have run so far
Counted from the client register, across 7 countries.
Measured from intake to first production deploy.
Ongoing, from the client register.
The middle number is worth pressing on when we talk. Three and a half weeks to a first production deploy is an average across MVP work. What it buys you is something running early, not a plan for it.
Which of these you should buy
Does someone on your side already have the room in their week to direct people and own the plan?
Managed team
Choose this when
Nobody on your side has real capacity to run the work. You want one person accountable for the date
It costs you
You give up day-to-day control of how the work is sequenced. You still decide what gets built and approve every change. You are not the one deciding who picks up what on a Tuesday.
Team under your manager
Choose this when
You already have a delivery lead with real room in their week. What is missing is capacity, not direction
It costs you
The delivery risk stays with you. If the plan is wrong or someone goes quiet, your lead has to notice it. And spend their week on it.
One software engineer
Choose this when
The work is one product or one stream that an experienced person can carry. More people would cost more in coordination than they buy
It costs you
You get no redundancy. Leave, illness or a competing priority stops the work. No second person is already holding the context.
The condition that decides it is capacity on your side. If you have a lead with room to direct people and own the plan, do not buy a second manager. Buy software engineers who join your team under your own manager instead. If your real question is who sits on a full unit, read how a full delivery team is composed, software engineers, testers and designers. If one person is enough, retain a single software engineer on your product alone.
Three more cases where a managed team is the wrong buy. Work that finishes in under a month, where onboarding eats most of the gain. Work where product decisions are still moving hourly, so there is no settled plan to hold. And work that has to sit inside your own ceremonies and report to your own board. The mirror case is worth naming too. Taking people on under your own manager and then not supplying that manager leaves you paying for control you are not using.
What an engagement looks like
Pilot
2 to 3 weeks
What it includes
- Evaluation criteria written into the engagement before anyone starts
- A working software engineer on your codebase, not a bench profile
- A replacement and a second pilot if the criteria are missed
Widens when the stack is unusual, or the criteria depend on a system we need access to first.
Managed engagement
3 months or longer
What it includes
- The software engineers and the person who runs them
- Daily standups, sprint reviews and biweekly demos of working software
- Change notes with time, effort and cost before any approval
- Code review by a senior software engineer with CI gating every merge
Widens when you need more people, a wider overlap window, or a coordinator hosting a live standup in your hours.
Three months is not a minimum we impose. It is roughly where a new software engineer's productivity curve flattens. Anything shorter gets you the ramp and not the run. Length follows the work rather than the contract. When the work ends, the engagement ends.
The work lives in your Git hosting and your cloud accounts. If you already have them we work inside them. If you do not, we provision them and hand you the keys, so nothing is ever held on our side. Everything below is yours from day one, not on exit. So far, no client has needed to use any of it.
What is yours the day you leave
- Every line of code, your IP from day one
- Your repositories and your cloud accounts
- Architecture and deployment documentation
- Working CI/CD pipelines
- A BRD, an SRS and every change note
- An operational runbook
Before you send the work
The questions that usually come up on the first call, answered before it.
Who do I call when the project is running late?
What happens when the estimate turns out to be wrong?
What do we actually get if we part ways?
Can we work with you if we have no technical person of our own?
What are the real overlap hours?
Can we meet the people first, and what if we say no?
- Start dates are often immediate once you choose.
- The first two to three weeks is then a pilot, against criteria written before anyone starts.
- If someone does not meet them we replace them and run the pilot again against the same criteria.
Tell us what is slipping
Send the work, the stack and the date you are working to. We usually come back within 24 hours with a shortlist and a time to talk.
You do not need a written spec to start. A paragraph is enough: what has to exist, who is waiting on it, what has already moved. If a managed team is the wrong shape for you, we will say so on the call.
- Usually a reply within 24 hours
- Everything you share stays private
- A shortlist, not a sales sequence