When a small Dynamics 365 or Odoo implementation partner wins a project bigger than their bench, the standard options are all bad: hire and carry payroll risk after the project ends, subcontract to a freelancer and hope the code holds up, or turn down work you fought to win.
The practical alternative used by consultancies that win repeat business is to buy delivery capacity incrementally, starting with one embedded engineer funded by the project in hand, then adding seats as the pipeline confirms. Done correctly, this is a contract and process decision, not a hiring decision, and it should never expose the consultancy's end client to the fact that extra hands are involved unless the consultancy wants it to.
TL;DR
The first seat has to be funded by a real, signed project. Speculative capacity is how consultancies end up carrying cost with no offsetting revenue.
Ramp-up timelines for offshore capacity typically run two to four weeks for onboarding, with three to six months before an engineer hits full independent productivity. Leading providers advertise faster add-on timelines of 48 hours to two weeks for known workflows.
The end client relationship, the delivery process, and the tooling stay owned by the consultancy. The offshore engineer works inside that structure, not around it.
What you standardise before seat one (environments, code review, definition of done, security onboarding) determines whether seat five costs less than seat one or the same.
Notice periods, ramp-down terms, and documentation ownership belong in the contract before the project starts, not after it slows down.
About the Author: 724SOFTWARE is a Vietnam-based engineering firm and a top 5 Odoo service partner in the country, delivering as a subcontract and white-label capacity partner to Microsoft Dynamics 365, Power Platform, and Odoo implementation partners across Singapore, the UK, and the US. This piece reflects patterns seen across those engagements, where the buyer is a consultancy staffing a client project, not an end client buying software directly.
Why Is the First Seat the Hardest One to Add?
The first seat is hard because it is the only one that has to justify itself against a real, funded scope of work before it exists. A consultancy that adds a developer speculatively, before the client contract is signed or before the statement of work defines hours, is taking on the same payroll-style risk it was trying to avoid by not hiring. The discipline here is simple: don't buy seat one until you can point to the specific line item in the client's signed scope that pays for it.
The second reason seat one is hard is integration, not headcount. A new engineer, whether hired or brought in through a delivery partner, has to work inside the consultancy's existing environment: its Azure DevOps or Git workflow, its Odoo module conventions, its client's Business Central sandbox, its own definition of "done." The average onboarding period for a dedicated offshore engineer runs two to four weeks, but reaching full independent productivity, meaning the engineer can pick up a ticket and close it without senior review on every step, typically takes three to six months. That gap matters for planning: seat one should be assigned to the highest-certainty, longest-duration piece of the project, not the riskiest or most time-boxed one, because it needs runway to become productive.
Practical filter before signing anything: does the funded scope behind seat one run at least three months? If it is shorter than that, the ramp cost may exceed what the seat delivers before the project ends.
Who Owns the Client Relationship When You Bring in Outside Capacity?
The consultancy does, in every case, and this has to be explicit in the delivery contract, not assumed. The offshore engineer or team reports into the consultancy's project manager or technical lead, not into the end client. Tickets, standups, and code review happen inside the consultancy's tools, using the consultancy's client-facing identity where that matters (email domain, Slack workspace, Teams channel). Whether the end client knows an offshore team exists at all is the consultancy's call, and both models are common:
White-label / invisible: the added engineers work under the consultancy's brand, in the consultancy's systems, with no client-facing indication of where they sit. Common for fixed-scope Dynamics 365 or Odoo modules where the client only cares about outcomes.
Disclosed subcontract: the client is told delivery capacity is being supplemented, usually because the client wants visibility into who is touching their system for compliance reasons.
Either way, the delivery partner should never be negotiating scope, timeline, or price changes directly with the end client. That stays with the consultancy. This is also where certifications matter more than most consultancies expect going in: if the end client is in a regulated sector, they will eventually ask what security standard the extended team operates under, and "ISO 27001:2022 certified" is a concrete answer, "we trust our subcontractor" is not.
How Do Ramp-Up and Ramp-Down Actually Work in the Contract?
Building on the ownership structure above, the mechanics that make ramping safe live entirely in the contract terms, not in goodwill. Three clauses do the real work:
Ramp trigger: the contract should specify what confirms the second, third, fourth, and fifth seat, ideally tied to a milestone (contract signature on phase two, a specific sprint velocity, a go-live date) rather than a calendar date. This stops the consultancy from paying for capacity ahead of confirmed revenue.
Ramp timeline: known, standardised workflows can add a seat in 48 hours to two weeks once the trigger fires, since the process, environment, and security onboarding are already templated from seat one. A seat added to an unfamiliar codebase without that template will take longer, closer to the two-to-four-week onboarding window.
Ramp-down notice: this is the clause consultancies negotiate poorly most often. A short notice period (two to four weeks) protects the consultancy if the client project slows down or ends early, but too short a notice period on the delivery partner's side can mean losing an engineer mid-sprint. Two to four weeks' notice on both sides is a reasonable anchor point to negotiate from.
A 30-person Odoo implementation partner adding a Power Platform automation stream might start with one automation-focused engineer for month one, confirm a second and third seat once the client signs phase two, and write a ramp-down clause tied to the client's own contract renewal date rather than an arbitrary quarter-end.
How Do You Keep Quality Consistent When Seat Five Arrives Months After Seat One?
A related but distinct problem from ramp timing is drift: seat five, arriving four months after seat one, inherits whatever undocumented decisions seat one made along the way. If those decisions (naming conventions, module structure, API patterns) are only kept in seat one's documentation and design records, every new engineer costs more to onboard than the last one, which defeats the point of buying capacity incrementally.
The fix is a living technical baseline, not a one-time handover document:
A short architecture decision log, updated whenever seat one or two make a non-obvious choice (why a custom Odoo module was built instead of using a standard one, why a Power Automate flow was structured a particular way).
A shared definition of done that applies to every seat identically: code review requirement, test coverage expectation, deployment checklist.
One senior engineer, ideally the first seat, given explicit responsibility for reviewing new arrivals' first two weeks of output against that baseline.
ISO 9001's quality management requirements are built around exactly this kind of consistency, documented processes that hold up as headcount changes, which is one practical reason a delivery partner's certification status is worth checking before the first seat, not after seat three underperforms.
What Should Be Standardised Before Seat One Even Starts?
This is the checklist that decides whether ramping from one to five seats is cheap or expensive, and it should be settled before the first engineer opens a laptop:
Item | Standardise before seat 1 | Cost if skipped
|
|---|---|---|
Dev/staging environments | Documented setup script, not manual config | Each seat loses days recreating environment by trial and error |
Code review process | Fixed reviewer, fixed checklist | Inconsistent quality, rework on client-facing bugs |
Definition of done | Written, shared with all seats | Disputes over whether a ticket is actually finished |
Security onboarding | Standard access-provisioning checklist tied to ISO 27001 controls | Delays adding seat 2+ while access is re-negotiated per person |
Client communication rules | Who talks to the end client, and how | Confusion over ownership, risk to the relationship |
None of this requires new tooling. It requires writing down what seat one already does informally, so seat two inherits it instead of reinventing it.
Is Buying Capacity Through Vietnam Different From Hiring or Subcontracting Locally?
Vietnam is a specific answer to a specific problem. According to research cited in the 2025 software engineering talent market analysis, the global software engineer shortage is projected to reach roughly 4 million unfilled positions by 2026. At the same time, average time-to-hire for software engineers already runs 41 to 67 days in North American and Western European markets, extending to as long as 95 days for senior roles. A consultancy that has just won a project cannot wait three months to hire, and subcontracting to an unknown local freelancer carries its own quality and continuity risk.
Vietnam-based delivery from an established IT company with process documentation, ISO 27001:2022 and ISO 9001 certification, and a track record on Microsoft Dynamics 365, Power Platform, and Odoo platforms, offers a cost structure advantage compared to onshore hiring in the US, UK, or Australia. The key is that cost is paired with dedicated teams, pre-vetted engineers, and ownership of your delivery process and client relationship, not positioned as the cheapest option or a budget alternative. This model scales from one to fifty pre-vetted engineers within two to four weeks and integrates into your existing delivery cadence and tooling.
Frequently Asked Questions
Do I need to disclose to my end client that I'm using an offshore delivery partner?
No, unless your contract with the client requires it or the client operates in a regulated sector that asks directly. Most white-label engagements keep this invisible by design.
How fast can I actually add a second or third seat once the client confirms phase two?
With a standardised onboarding template already in place from seat one, 48 hours to two weeks is realistic for known workflows. Without that template, expect closer to two to four weeks.
What happens if my client project ends early and I need to ramp down fast?
This depends entirely on the notice period negotiated in your delivery contract. Two to four weeks' notice on both sides is a workable anchor to negotiate from.
Should seat one be a generalist or a specialist matched to the exact module or workload?
Matched to the funded scope specifically. A generalist costs you the three-to-six-month ramp-to-productivity window twice: once on the platform, once on the specific client workflow.
Can a consultancy this size (2-30 people) realistically manage an offshore team without a dedicated PM?
Yes, if the delivery partner's process is standardised enough that the consultancy's existing lead reviews output rather than manages day-to-day tasks. That is the point of buying a pre-vetted team rather than individual freelancers.
What certifications should I actually check before signing with a delivery partner?
ISO 27001:2022 for information security continuity and disaster recovery, ISO 9001 for quality management and resourcing consistency, and SOC 2 Type II or GDPR compliance if your end client operates in finance, healthcare, or the EU.
Is an offshore development center setup different from adding one or two seats to an existing team?
An ODC is a dedicated offshore hub built for a client's own long-term use, usually justified once headcount needs exceed roughly ten to fifteen people. Below that, embedding one to five pre-vetted engineers into your existing process is faster to set up and carries less overhead.
About 724SOFTWARE
724SOFTWARE is a Vietnam-based engineering firm and a top 5 Odoo service partner in Vietnam, working as a subcontract and white-label delivery partner for Microsoft Dynamics 365, Power Platform, and Odoo implementation partners across Singapore, the UK, and the US. The company operates under ISO 9001, ISO 27001:2022, SOC 2 Type II, and GDPR compliance, with dedicated teams that scale from one to fifty pre-vetted engineers within two to four weeks and a follow-the-sun support model with sub-10-minute incident response. All delivery is from Vietnam, with 200+ engineers, 58% at senior level, and a 95% client retention rate across consultancies and enterprises in 10+ countries.
If you have just won a project you cannot staff, the next step is a short scoping conversation, not a hiring process. Get in touch with 724SOFTWARE at https://724software.com.vn to work out what seat one should look like and how it fits your existing delivery process.
