- 1. Who exactly is working on my product?
- 2. What does "dedicated" actually mean?
- 3. How does integration actually work?
- 4. What are the exit terms?
- 5. Who owns the code?
- 6. How is performance measured — and what happens when it isn't?
- 7. What does pricing actually cover?
- What a Strong Contract Actually Looks Like
- FAQs
You've shortlisted a provider. The proposal looks solid. Now someone puts a contract in front of you.
This is where most bad outstaffing decisions get locked in — not during the sales call, not during the technical interview, but in the contract, where vague language about "dedicated resources" and "best-effort delivery" quietly shifts all the risk onto you.
Before you sign, ask these seven questions. If the answers aren't in the contract, get them in writing before they are.
1. Who exactly is working on my product?
This sounds basic. It isn't.
Some providers staff engagements with whoever is available at signing — not whoever was presented during the sales process. Others rotate engineers between clients based on internal demand. The contract should either name specific individuals or define a clear process for how engineers are selected and approved by your team before work begins.
Ask whether the contract names the engineers or just describes a role. Ask whether you can interview each person before they join. Ask what happens if someone leaves mid-engagement.
If the answer to that last question is "we'll replace them," find out how fast — and whether you have approval rights over the replacement. Codebase knowledge walks out the door with every rotation.
2. What does “dedicated” actually mean?
"Dedicated engineer" is one of the most overloaded phrases in outstaffing. It can mean full-time on your product. It can also mean 80 percent on your product and 20 percent on someone else's, or full-time in theory but shared in practice when the provider hits capacity pressure.
The contract should define utilization explicitly. Full-time means 40 billable hours per week on your work — not internal meetings, not other clients, not bench time that gets quietly billed.
Ask for a clause that specifies minimum weekly hours allocated to your engagement, and a reporting mechanism that makes utilization visible to you.
3. How does integration actually work?
The difference between an outstaffing arrangement that works and one that doesn't usually comes down to this: do the engineers work inside your team, or alongside it?
Alongside means they receive tickets, complete them, and return output. Inside means they join your standups, use your tools, follow your branching conventions, and communicate in your channels. The second model produces better software and fewer handoff failures.
Ask the provider to describe exactly how their engineers will participate in your workflow. Will they be in your Slack or theirs? Will they join sprint planning? Who do they report to day-to-day?
If the contract says nothing about integration mechanics, that's a signal worth taking seriously. Engagements like Bolder Group and BlueMeg required engineers to operate inside existing product workflows from day one. That's the standard worth holding providers to.
4. What are the exit terms?
Growth-stage companies move fast. A three-engineer engagement you need today might need to scale to six in four months — or drop to one after a product pivot. The contract needs to reflect that reality.
Watch for three specific clauses.
Minimum commitment periods. Some providers require 12-month lock-ins. That's a long time to be stuck with engineers who aren't performing, or to be paying for capacity you no longer need. Aim for rolling monthly or quarterly terms after an initial ramp period.
Notice periods for scaling down. Thirty days is reasonable. Ninety days is a penalty clause dressed as standard terms.
Termination for convenience. You should be able to exit without cause, with reasonable notice. If the contract only allows termination for breach, you have no practical exit until something goes wrong.
5. Who owns the code?
This should be non-negotiable — but it still appears as a negotiation point in some contracts.
Everything written by engineers on your engagement should belong to you. That includes code, documentation, architecture decisions, and any tooling built during the engagement. The contract should state this explicitly and should not carve out exceptions for "proprietary methodologies" or "internal frameworks" that happen to live in your repository.
Also check whether the IP assignment clause covers work done by subcontractors. Some providers use subcontracted engineers without disclosing it. If the contract doesn't address subcontracting, ask directly whether any third parties will touch your codebase.
6. How is performance measured — and what happens when it isn’t?
Vague SLAs are how providers protect themselves from accountability. "Best efforts" is not an SLA. "High-quality code" is not measurable. "Timely delivery" means nothing without a definition of timely.
A well-structured outstaffing contract should define sprint velocity expectations or output benchmarks during ramp-up, a process for raising and escalating performance concerns, what remediation looks like if an engineer isn't meeting expectations, and whether you can request a replacement and on what timeline.
You're not looking for punitive clauses. You're looking for a provider willing to be held accountable — which is itself a signal of confidence in their own engineers.
7. What does pricing actually cover?
Even when a provider gives you a monthly rate, that number rarely tells the whole story.
Ask what's included. Management overhead, HR administration, equipment, and benefits are sometimes bundled — sometimes they appear as line items on the second invoice. Ask about rate escalation: is the rate fixed for the contract term, or can it be adjusted with 30 days' notice?
Ask about billing during ramp-up too. Some providers bill full rates from day one, even when an engineer is still getting onboarded and not yet contributing to sprint output. A fair contract either reduces the rate during a defined ramp period or excludes ramp time from billing entirely.
Transparent pricing is one of the clearest signals of a trustworthy partner. If the commercial terms require three emails to clarify, that's worth noting before you're six months into an engagement.
What a Strong Contract Actually Looks Like
A good outstaffing contract is not long. It's specific. It names people, defines terms, allocates IP clearly, and gives you a practical exit. It describes how integration works — not just that it will. It holds both sides accountable.
The providers worth working with won't push back on these questions. They'll have answers ready.
At We Work Worldwide, engagements are built around embedded integration: engineers who join your standups, work in your tools, and operate at your team's velocity. The contract terms reflect that — no rotation, no opaque billing, no 12-month lock-in for companies that need to move fast.
If you're evaluating providers and want to understand how a structured engagement actually works, that's a good place to start.
FAQs
What is an outstaffing contract?
An outstaffing contract is a formal agreement between a company and an external provider that defines the terms under which dedicated remote engineers will work within the client's team. It covers scope, pricing, IP ownership, exit terms, and performance expectations.
How is outstaffing different from outsourcing?
In outsourcing, a provider takes ownership of a project or deliverable and manages it independently. In outstaffing, the engineers are dedicated to your team and work under your direction — joining your workflows and reporting to your leads. You retain control of the product and the process.
What should an outstaffing contract always include?
At minimum: named or approved engineers, explicit IP assignment to the client, defined utilization hours, exit and notice terms, a performance accountability process, and a clear pricing structure with no hidden escalation clauses.
How long should an outstaffing contract be?
Initial terms of three to six months are common, with rolling monthly extensions after that. Twelve-month lock-ins are standard at some larger providers but are poorly suited to growth-stage companies that need flexibility as their product and team evolve.
Can I replace an engineer mid-contract if they aren't performing?
Yes, if the contract allows it. Negotiate for the right to request a replacement with a defined timeline, and the right to interview and approve that person before they join your team. If the contract doesn't address this, add it before signing.
Who owns the code written by outstaffed engineers?
It should be you, always. The contract should explicitly assign all IP to the client, including work done by subcontractors if any are involved. Never assume this is implied — get it in writing.
What's the biggest mistake CTOs make when signing an outstaffing contract?
Accepting vague language about dedication, integration, and performance. Phrases like "best efforts," "dedicated resources," and "high-quality output" are unenforceable. The contract should define what those terms mean in practice, with specific numbers and processes attached.
