Four Ways to Engage, and the Honest Trade-Offs in Each
Part-time, full-time dedicated, fixed-scope project, or a trial that extends. The differences that matter are commitment, notice and how much of the developer’s attention you actually get.
Pick the One That Matches the Work, Not the Budget
Choosing a model to fit a budget rather than the work is the most reliable way to spend less and get less than you needed.
Part-time, billed hourly
Typically twenty hours a week, spread over four or five shorter days rather than compressed into two. You are billed against logged hours and you get the log, not a single line on an invoice.
This works when the work genuinely is part-time: a maintained product with a steady trickle of changes, a specialist needed alongside your own team, or a second pair of eyes on reviews and architecture. It also works well as a first step when you are not yet sure how much capacity you need.
It works badly when a full-time amount of work is being squeezed into half the hours, which is covered in detail further down this page.
Full-time dedicated
One developer, your product and nothing else, invoiced at a flat monthly rate. They keep your working hours, sit in your standup, and hold context in their head the way an employee does.
This is the default and the majority of what we do. The reason is unglamorous: context is expensive to build and cheap to keep, and a developer who is in your codebase every day stops asking the same questions after a fortnight.
A full-time developer is not shared with another client. If somebody is genuinely better suited to a half allocation we will say so, and price it as such, rather than invoicing two clients for the same person.
Project-based, fixed scope
A defined piece of work with a written deliverable and a price agreed before anything starts: a code audit, a TypeScript migration, an API build or a round of performance work.
This is the one model where we own an outcome rather than supplying capacity. It suits work that has a clear edge around it and a definition of done that two people would recognise identically.
It is the wrong shape for anything where the requirements are still moving. Fixed scope plus changing scope produces change requests, and change requests produce arguments neither of us enjoys.
Trial, then extend
A short engagement of two to four weeks on a real piece of work, after which either side can walk away or it rolls into a monthly arrangement. The trial is paid at the normal rate; a discounted trial would only mean the discount is priced in somewhere else.
Worth doing when the codebase is unusual, when the role is hard to describe, or when somebody internal needs convincing that remote contractors can work. The developer gets a fair look at your situation too, which matters more than it sounds.
Pick a real ticket for the trial, not a sandbox exercise. A trial on invented work tells you how somebody handles invented work.
The Same Four Models in One Table
Billing detail sits on the pricing page; this is the commercial shape.
| Part-time hourly | Full-time dedicated | Fixed scope | Trial to extended | |
|---|---|---|---|---|
| Typical commitment | About 20 hours a week | Full working week, one client | Whatever the deliverable needs | 2 to 4 weeks, then monthly |
| Minimum | About 40 hours | One month | None — priced per piece of work | Two weeks |
| Notice to end | Two weeks | 30 days | Not applicable | None during the trial window |
| Billing | Monthly in arrears, against a log | Flat monthly rate | Fixed price, staged | Hourly or pro-rated monthly |
| Who sets priorities | You | You | Agreed scope document | You |
| Scaling up | More hours, or move to full-time | Add developers to the same agreement | A second piece of scope | Extend into monthly |
| Replacement guarantee | First two weeks | First two weeks | Not applicable — we own delivery | Covered by the trial itself |
| Best when | Steady maintenance or a specialist | Continuous roadmap work | A clear definition of done | The role is hard to describe |
When Half a Developer Is False Economy
Part-time is a genuinely good answer to some situations and an expensive mistake in others. The difference is whether the work is 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 you need for one part of the stack, alongside people who cover the rest.
- Senior review capacity: someone who reads pull requests and argues about architecture.
- 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, so the slow period lasts a month instead of a fortnight.
- Every question waits. A blocker raised on Tuesday afternoon can sit until Thursday, and the half-built branch sits with it.
- Context is rebuilt at the start of every session. Half the hours does not buy half the output, it buys rather less.
- Nobody owns anything end to end, so the difficult work drifts to whoever is present, which is your existing 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.
What Monday to Friday, 10:00–19:00 IST Overlaps With
Time zones are where remote engagements quietly fail, 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, which gives a comfortable overlap for the whole of your morning and into the early afternoon.
Expect four to five hours of genuinely live time without anybody shifting their schedule. A slightly later start on our side pushes that further into your afternoon when you want it.
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. This is the part most suppliers phrase vaguely, so plainly: 19:00 IST is about 08:30 Eastern.
The fix is a shifted day. Developers working with US teams commonly move to a later window so that three to four hours land inside your morning, with the west coast needing a later shift again. The shifted hours are agreed before the start date and written into the engagement, not left to goodwill.
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 the practical live window is the back end of your day.
For Sydney or Auckland, plan on two to three hours of live overlap and put standup at the start of our day rather than yours.
What “overlap” should actually mean in your engagement
Decide how many hours a day you need the developer live and say so in the brief. Two or three hours is enough for a standup, a review turnaround and a real conversation when something is stuck. Demanding eight hours of overlap narrows the pool of people willing to do it, and the ones who agree are frequently the ones with the fewest other options.
Outside the overlap, asynchronous habits carry the engagement: a written standup note, pull request descriptions that explain the reasoning, and questions posted with enough context to be answered while the asker is asleep. We assess exactly this in the vetting process, because it is the difference between a distributed team and a delayed one.
Minimums, Notice, Leave, Equipment and Access
The details that decide whether an engagement feels smooth or irritating, stated in advance.
Minimum engagement lengths
One month full-time, around forty hours part-time, two weeks for a trial. Fixed-scope work has no minimum because it is priced per deliverable. The minimums exist because onboarding takes a real number of days and nobody benefits from an engagement that ends before it starts paying back.
Notice periods
Thirty days on a monthly engagement, two weeks on an hourly one, binding in both directions. We will not pull somebody off your work at short notice for a better-paying engagement, and if a developer resigns from us we carry the handover rather than passing it to you as a surprise.
Scaling up
Adding a second or third developer to a running engagement usually needs only a start date and the three-day profile cycle, not a new agreement. If the answer keeps being “one more person”, a pod is often the better structure than a sequence of individual hires.
Scaling down without ending
Dropping from full-time to part-time takes the same notice as ending, and is usually the smarter move when a release lands and the next phase is not funded. Keeping somebody at two days a week preserves context you have already paid to build, and restarting later costs a fraction of hiring from scratch.
Holidays, leave and cover
Indian public holidays and a normal allowance of annual leave, both flagged in advance. On a single-developer engagement a short absence has no like-for-like cover, because somebody parachuted into your codebase for three days is a cost rather than a help. On a team engagement the others absorb it, which is one of the quiet arguments for a pod.
Equipment and access
Developers use their own machines and connectivity, which we cover along with standard tooling. You supply access to your systems and any licences that are specific to your stack. If your policy requires a managed or company-issued device, that is workable but adds about a week and some shipping, so raise it early.
Questions About Engaging Us
What is the minimum engagement?
One month for a full-time developer, and about forty hours for an hourly part-time arrangement. Anything shorter and most of the engagement is spent on onboarding, which is a poor use of your money and unsatisfying for the developer. Fixed-scope work has no minimum at all, because it is priced as a piece of work rather than as a block of time.
How many hours does a part-time developer actually work?
Twenty hours a week is the usual arrangement, spread across four or five shorter days rather than two long ones. Two full days a week sounds efficient and works badly, because somebody who is absent for three days loses the thread of everything the team decided while they were gone. If the work needs more than about twenty-five hours a week, full-time is cheaper per unit of progress.
Will the developer work in our time zone?
The standard working window is Monday to Friday, 10:00 to 19:00 IST. For clients in Europe that produces a substantial live overlap, for Asia-Pacific a workable one, and for North America almost none at standard hours. That is why developers working with US teams shift their day later by agreement. The shifted window is confirmed before the engagement starts rather than improvised in week two.
What happens during holidays and illness?
Developers take Indian public holidays and a normal amount of annual leave, and both are flagged in advance rather than announced on the morning. On a single-developer engagement there is no like-for-like cover for a short absence, because dropping somebody unfamiliar into your codebase for three days helps nobody. On a team engagement the others absorb it. A long or open-ended absence is handled as a replacement rather than a pretence.
Who provides equipment, and how does access work?
Developers work on their own machines, and we cover hardware, connectivity and the usual tooling. You provide access to your systems: repository, ticket board, chat, staging and whatever credentials the role needs. If your security policy requires a company-issued or centrally managed laptop, tell us early. It is workable, but it adds roughly a week and some shipping to the start date.
Can we switch from part-time to full-time later?
Yes, and it happens often. Moving up usually needs nothing more than a start date, provided the developer has not taken other commitments in the meantime, which is why it helps to flag the possibility early. Moving down is treated like notice: thirty days from a full-time month, or two weeks from an hourly arrangement.
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 fewer hours than you expected.