Three ways to work together

There are three ways to work with us, and the difference between them is what you are buying. A dedicated team is a capability. Team extension is capacity. A fixed-scope project is an outcome. Each is priced differently, governed differently and ended differently, and those three mechanics are described below rather than left to the contract.

One thing is the same in all three: code and configuration land in your repositories under your review rules from the first commit, and the documentation and infrastructure definitions are yours throughout. Nothing is built in a private space and handed over later.

Dedicated team

A team that works only on your product, directed by you. Suits organisations that need a capability they do not have internally and expect the work to continue for quarters rather than weeks.

This is the model sold elsewhere as a dedicated development team, a dedicated offshore team or an offshore development centre — ODC, written offshore development center in American English. The names describe the same arrangement; what differs between providers is how much of it is written down before money changes hands, which is what the rest of this page is about.

Best when: the roadmap is longer than the current team can absorb, and you want continuity of context rather than a rotating cast.

How it is priced: per engineer per month, with the role and seniority named. The rate covers employment, equipment, leave cover and replacement — including the overlap where an outgoing engineer transfers context to their replacement, which is our cost rather than yours. There is no bench to fund and no charge for a handover we caused.

How it is governed: you own the backlog, the priorities, the technical direction and the definition of done. We own the people, plus a named escalation point on our side who is accountable for the engagement and is not one of the people doing the work. Team composition changes by agreement, not by our staffing convenience.

How it ends: quarterly is the minimum, because ramp-up cost makes anything shorter poor value for both sides. Notice is agreed at the start rather than negotiated at the end, and the engagement finishes with a documented handover, credentials rotated into your own store, and a period where your team runs the system while ours is still reachable.

Team extension

One or more engineers inside your existing team, working to your process, your standards and your stand-ups. The lowest-friction way to start, and the easiest to judge honestly after a month.

Most of the market calls this staff augmentation, or IT staff augmentation. It is the same arrangement, and we use the plainer name because the usual one describes the supplier's side of it rather than yours. Two things about ours are worth checking against anyone else's: the engineer is allocated to you full time, with no second client quietly on the same calendar, and a replacement overlaps with the person leaving at our cost rather than starting cold at yours.

Best when: you have engineering leadership already and need capacity in a specific stack or module.

How it is priced: per engineer per month, the same basis as a dedicated team. The engineer is yours full time; there is no shared allocation and no second client quietly on the same calendar.

How it is governed: entirely by you. Your sprint, your review rules, your on-call arrangements. We stay out of the delivery conversation and handle only employment, cover and replacement. If an engineer is not working out, that is our problem to fix and the replacement overlaps rather than starting cold.

How it ends: with notice, and quickly. This is deliberately the easiest model to stop, which is exactly why it is the right way to test a supplier you have not worked with before. Because the work sits inside your own repositories and process throughout, ending it removes a pair of hands and leaves nothing to untangle.

Where it has run:

• Opus Technologies — Banking and payments technology
• Optimus — Financial operations software
• TechEdge Services — IT services
• Sagacity Software — Software and data analytics
• PoochPay — Accounts payable software

Fixed-scope project

A defined outcome, delivered and handed over. Suits well-understood problems — a migration, an integration, an MVP with a clear boundary.

Best when: the outcome is describable in advance and you do not want to manage a team to get there.

How it is priced: to the scope, not to a period and not to hours logged. Pricing by hours rewards the wrong behaviour on both sides — it pays for slowness and it makes every efficiency an argument. A fixed price makes the scope the thing that must be written carefully, which is where the attention belongs anyway.

How it is governed: by acceptance criteria agreed before work starts and by demonstrable progress against them. Change is normal and is handled as a change: a re-scoped price, agreed before the work happens rather than invoiced after it. A project where scope moves silently is a time-and-materials engagement with worse paperwork.

How it ends: on acceptance, with a runbook, environment definitions that rebuild without us, and a support window agreed up front. The test of a finished project is whether someone else could take the next change without ringing us.

Forward deployed engineers

The term has moved from Palantir into general use, and it now arrives in enquiries. A forward deployed engineer is an engineer who works inside your environment — your systems, your data, your constraints — rather than building against a specification from a supplier's office and delivering at the end. The distinction is where the work happens and whose reality it meets, not the job title.

By that definition, both team extension and a dedicated team are forward deployed: engineers commit into your repositories from the first week, run against your data, and sit in your stand-ups. That is the whole design of the ODC model here, and it is why the handover section of every engagement is short — there is nothing to hand over that was not already yours.

Where we differ from the Palantir sense of the phrase. There, a forward deployed engineer is deploying the vendor's own product into a customer and bending it to fit. We do that only for the Sarva applications, where the engineer configuring a rate card or an inspection schedule is the same one who can change the product. On everything else, your stack is the product and we are engineers in it. If what you need is somebody to take a vendor's platform you already own and make it work in your organisation, that is a real job and it is not the one described on this page.

Choosing between them

• Buying capacity for a team you already run → team extension, or staff augmentation as it is usually listed
• Buying a capability you do not have → dedicated team
• Buying an outcome with a clear edge → project

If it is genuinely unclear, extension is the cheapest way to find out, because it is the easiest to stop.

Moving between models is common and expected. Several engagements start as one or two engineers inside an existing team and grow into a dedicated team once the working relationship is proven; a project sometimes ends by revealing that the real need was ongoing capacity. The people carry over, which is the point — the expensive part of any of these models is context, not contract.

When is none of these the right answer?

Some situations are better served by not engaging us at all, and it is cheaper for everyone to establish that at the first conversation.

• You need a few days of work. Any of these models carries setup cost that a short task cannot repay.
• Nobody on your side can answer questions. Every model assumes someone who can decide. Without that, the team decides for you, and you will not agree with all of it.
• The requirement is still unknown. A fixed-scope project needs a describable outcome. If nobody can yet write one, what you need next is a discovery conversation rather than a quote.
• Regulation prevents the work leaving the jurisdiction. Establish this before commercial discussion, not after.
• You want a supplier to own the outcome entirely. Somebody on your side has to accept the work in every model. An engagement in which nobody reviews anything fails regardless of how it is priced.

Teams are built for companies in the United States and the Gulf — the UAE, Saudi Arabia, Qatar, Kuwait, Bahrain and Oman. The engineers are in Pune, which matters mostly for the clock. Dubai is ninety minutes behind us and Riyadh two and a half hours, so a Gulf team shares almost the whole working day. New York is nine and a half hours behind, so American engagements run on a written handover and one fixed overlap window rather than on a standing call — a real constraint, and better stated than discovered.