Three Ways to Hire, and a Fourth Option That Is Not Hiring at All
Project-based, part-time augmentation, full-time augmentation, or team training for developers you already employ. Here is the honest shape of each, including the hours we can actually commit.
Pick the Shape That Matches the Work
Three of these are ways to hire. The fourth is not a hiring model at all — it is what you do instead of hiring, when the developers you need are already on your payroll.
Project-based hiring
A defined piece of work with an agreed scope, priced and staged before anything starts. The developer owns delivery of that scope rather than being handed a stream of tickets.
Fits work with a real edge around it: a feature build, a migration, an integration. It is the wrong shape once requirements are still moving, because a fixed scope against a moving target produces change requests neither side enjoys.
Part-time augmentation
Around twenty hours a week, billed against logged time, as an addition to your existing team rather than an owner of a separate deliverable.
Works well for steady maintenance, a specialist alongside people who cover the rest of the stack, or senior review capacity. Works badly when a full-time amount of work is squeezed into half the hours — covered further down this page.
Full-time augmentation
One developer, dedicated to your product for the agreed hours, invoiced at a flat monthly rate. They keep your working rhythm and hold context the way an embedded team member does.
The default for continuous roadmap work. Context is expensive to build and cheap to keep, and a developer inside your codebase every day stops re-asking the same questions after the first couple of weeks.
Team training — not a hiring model
Workshops or ongoing coaching for developers you already employ, on using AI coding tools well and reviewing what those tools produce with the same scepticism this whole marketplace is built on.
Nobody is added to your headcount and nobody joins your team. It is the right answer when the gap is skills, not capacity — and the wrong one to confuse with augmentation, which is why it is priced and sold entirely separately.
The Same Four Models in One Table
Rate detail lives on the pricing page; this is the commercial shape of each.
| Project-based | Part-time augmentation | Full-time augmentation | Team training | |
|---|---|---|---|---|
| What it is | We deliver a defined scope | A developer joins your team, part-time | A developer joins your team, full-time | We teach your own developers |
| Minimum engagement | None — priced per deliverable | About 40 hours | About one month | One workshop |
| Notice to end | Not applicable — ends on delivery | Two weeks | About 30 days | Not applicable — scheduled per session |
| Billing | Fixed price, staged | Monthly in arrears, against a log | Flat monthly rate | Per workshop or per engagement |
| Who directs the work | Agreed scope document | You | You | Your training lead, on curriculum |
| Scaling up | A second piece of scope | More hours, or move to full-time | Add developers to the same arrangement | A follow-up session or a longer series |
| Replacement guarantee | Not applicable — we own delivery | First two weeks | First two weeks | Not applicable — nobody is placed |
| Best when | A clear definition of done | Steady work or a specialist gap | Continuous roadmap work | The gap is skill, not headcount |
When Half a Developer Is False Economy
Part-time augmentation is a good answer to some situations and an expensive mistake in others. The difference is whether the work is genuinely part-time, or the budget is.
When the work itself is intermittent
- A stable product with a predictable trickle of bugs and small features.
- A specialist for one part of the stack, alongside people who cover the rest.
- Senior review capacity — someone reading pull requests, including AI-assisted ones, critically.
- A first engagement while you work out how much capacity you actually need.
When full-time work is squeezed into half the hours
- Onboarding takes the same number of weeks but is paid for over twice the calendar.
- A blocker raised on Tuesday can sit until Thursday, and a half-built branch sits with it.
- Context is rebuilt at the start of every session, so half the hours buys rather less than half the output.
- Nobody owns anything end to end, so the hard work drifts to whoever is present — your own team.
The rough rule: if the backlog needs more than about twenty-five hours a week, full-time is cheaper per unit of progress even though the invoice is larger. If you are close to the line, start part-time and move up — that direction is easy and covered below.
What Monday to Friday, 10:00–19:00 IST Actually Overlaps With
Time zones are where remote augmentation quietly fails, so here is the arithmetic rather than a reassuring sentence about flexibility.
Europe and the UK
The best fit by a distance. On standard hours the day runs from roughly 05:30 to 14:30 in central Europe and an hour earlier in the UK, giving a comfortable overlap through your whole morning and into early afternoon — four to five hours of genuinely live time without anybody shifting their schedule.
North America
On standard hours there is effectively no overlap with a nine-to-five in the eastern United States, and none at all on the west coast — 19:00 IST is about 09:30 Eastern and 06:30 Pacific. The fix is a shifted day, agreed before the start date: developers working with US teams commonly move their window later so that a few hours land inside your morning.
Asia-Pacific
Singapore, Hong Kong and the Gulf work well on standard hours, with several hours of overlap through your afternoon. Australia and New Zealand are tighter — the Indian morning is your afternoon, so plan on two to three hours of live overlap toward the end of your day.
What "overlap" should mean in your engagement
Decide how many hours a day you actually need the developer live and say so in the brief. Two or three hours is usually enough for a stand-up, a review turnaround and a real conversation when something is stuck. Outside that window, asynchronous habits carry the engagement — a written stand-up note, pull request descriptions that explain the reasoning behind AI-assisted and hand-written code alike, and questions posted with enough context to be answered while the asker is asleep. We assess exactly this during vetting, because it is the difference between a distributed team and a delayed one.
Engagements Change Shape — That Is Normal, Not a Renegotiation
Few engagements stay in the box they started in. The moves below are the common ones, and none of them require starting over.
Project that becomes ongoing augmentation
The most common shift. A fixed-scope build finishes well, the client wants the same developer for the next phase, and the next phase does not have a clean edge around it the way the first one did. At that point continuing as project-based work stops making sense and part-time or full-time augmentation takes over — usually with the same developer, if their calendar allows it.
Part-time scaling to full-time
Moving up usually needs nothing more than a start date, provided the developer has not taken on other commitments in the meantime, which is why it helps to flag the possibility early rather than the week you need it.
Full-time scaling down without ending
Dropping from full-time to part-time takes the same notice as ending, and is often the smarter move when a release lands and the next phase is not yet funded. Keeping someone at a couple of days a week preserves context you have already paid to build.
Augmentation alongside training
Some clients run both at once — an augmented developer covering capacity while their own team goes through a training series. The two are billed and scheduled entirely separately, because they answer different questions: one is about hours, the other is about skill.
Questions About Engaging Us
What is the minimum engagement?
About a month for full-time augmentation, and roughly forty hours for part-time. Below that, most of the engagement is spent on the developer learning your codebase rather than working in it, which is a poor trade for both sides. Project-based work has no minimum at all, because it is priced against a defined piece of work rather than a block of time. Team training has its own minimum, which is a single workshop rather than an hour count.
How many hours are actually committed on a part-time engagement?
Around twenty hours a week is typical, spread across most of the working week rather than compressed into two days. The commitment is to hours delivered against your priorities, not to being reachable at every moment — a part-time developer who is heads-down for a stretch and then responsive is normal and expected. If the backlog genuinely needs more than about twenty-five hours a week, full-time is the better fit and usually the cheaper one per unit of progress.
What are your actual working hours, and what do they overlap with?
Monday to Friday, 10:00 to 19:00 IST, and we will not dress that up as more flexible than it is. That window gives clients in Europe a comfortable few hours of live overlap through their afternoon, gives Asia-Pacific clients a workable morning-to-afternoon overlap, and gives US clients on standard hours almost none — 19:00 IST is roughly 09:30 Eastern and 06:30 Pacific. Developers working with US teams commonly shift their day later by agreement, confirmed before the engagement starts, not improvised once someone is already blocked.
Can an engagement move from one model to another?
Yes, and it is one of the more common changes we see. A project-based engagement that keeps generating more work becomes ongoing part-time or full-time augmentation once that pattern is obvious to both sides, usually with the same developer if they are available. Augmentation can scale up, scale down, or convert into a fixed-scope piece of work when the next phase has a clear edge around it. None of these moves require starting the relationship over.
Is team training a hiring model?
No, and it is worth being explicit about that because the name invites confusion. Team training is us teaching your existing developers to use AI coding tools well and to review AI-assisted output critically — nobody joins your team, nobody is added to your headcount, and nothing about your roster changes. It sits alongside the three hiring models as a fourth, separate way to work with us, not a version of any of them.
What notice do we need to give to scale down or end an engagement?
Two weeks on an hourly part-time arrangement, roughly thirty days on a full-time monthly engagement, agreed in writing before the engagement starts. Project-based work has no notice period because it ends when the deliverable is accepted, not on a calendar date. Scaling down from full-time to part-time is treated the same as ending the full-time portion — the same notice applies, because the developer’s calendar has been planned around your commitment either way.
Not Sure Which Model Fits?
Describe the work and the hours you can realistically cover. We will tell you which shape fits — including when the answer is training your own team rather than hiring at all.