Direct answer
The decision in brief
Buy forward-deployed engineering around a named production outcome, not a number of developers. A credible engagement defines the accountable workflow, client and vendor decision rights, approved access, delivery sequence, acceptance evidence, intellectual-property ownership, operating transfer, and an explicit end condition. Pricing should correspond to a bounded phase and risk, while material scope changes require a new decision. If a vendor cannot explain how the client becomes self-sufficient, the engagement is not yet safe to buy.
Who this is for: Executive sponsors, engineering leaders, security reviewers, legal teams, and procurement owners preparing to evaluate or contract an FDE partner.
Decision framework
Score the engagement before comparing vendors
A strong proposal makes accountability inspectable. Score each dimension before negotiating rate cards or team size.
| Dimension | Strong evidence | Warning sign |
|---|---|---|
| Outcome | Named workflow and acceptance condition | Generic transformation or capacity |
| Authority | Client release and risk owners named | Vendor assumed to decide implicitly |
| Access | Scoped identities, environments, and data | Shared credentials or unrestricted access |
| Delivery | Working increments against highest risk | Long discovery followed by a final reveal |
| Ownership | Client-owned code, artifacts, and accounts | Core assets remain vendor controlled |
| Exit | Transfer, revocation, limitations, and completion | Open-ended dependency |
Deployment sequence
A controlled path from decision to evidence
- 01
Prepare the problem brief
State the workflow, consequence, current constraint, executive owner, affected systems, and why action is timely.
- 02
Run a fit conversation
Test whether the partner asks about operators, exceptions, access, evidence, authority, and the conditions that make FDE inappropriate.
- 03
Select a bounded first phase
Begin with a deployment sprint, constraint assessment, or production foundation tied to a decision—not an indefinite team lease.
- 04
Contract the boundaries
Resolve intellectual property, confidentiality, data, providers, security, access, environments, approvals, change control, and closeout.
- 05
Review working evidence
Use frequent technical and operator reviews to accept learning, expose risk, and decide whether the next increment remains justified.
- 06
Accept and close
Verify the outcome, limitations, repositories, documentation, runbooks, knowledge transfer, account ownership, and access removal.
Authority and ownership
Responsibilities must remain explicit
The client owns
- — Provide executive, workflow, technical, security, and release owners
- — Approve contract, access, data, risk, and scope changes
- — Accept the outcome and ongoing operating responsibility
Ten Mile Zone owns
- — Propose a bounded outcome, delivery model, evidence, and exclusions
- — Report progress, decisions, risks, dependencies, and limitations
- — Transfer contracted artifacts and complete closeout
Common failure modes
Where otherwise credible programs break down
Rate-card procurement
Comparing hourly roles before defining the outcome rewards apparent capacity rather than accountability or fit.
Undefined acceptance
The parties can debate whether work is complete because neither observable behavior nor decision authority was agreed.
Security deferred to kickoff
The proposed architecture and schedule depend on access or data use that reviewers may never approve.
Change without re-contracting
Materially different workflows or risks enter the engagement without a new outcome, boundary, or commercial decision.
Fit boundary
When forward-deployed engineering is the wrong choice
- The vendor avoids naming exclusions or failure conditions
- The proposal sells anonymous capacity as forward deployment
- The buyer cannot provide workflow access or accountable owners
- Ownership, model providers, data use, or closeout remain unresolved
- Success depends on unsupported guarantees or an unverifiable speed multiplier
Client participation
Who must participate
- Executive sponsor
- Workflow or product owner
- Engineering and architecture owner
- Security, identity, and data owners
- Legal and procurement representatives
- Production release and ongoing service owner
Acceptance evidence
What proves the engagement worked
- Signed outcome, scope, exclusions, and decision rights
- Approved security, data, provider, and access boundary
- Working increments and recorded technical decisions
- Acceptance results and known limitations
- Client-controlled repositories, accounts, runbooks, and documentation
- Knowledge transfer and access-removal confirmation
Buyer checklist
Questions to resolve before proceeding
- What exact production outcome is included?
- Which assumptions could change scope or price?
- Who owns code, configurations, prompts, evaluations, and derived artifacts?
- Which model and service providers may be used?
- Who approves production release and risk?
- How are defects, changes, and third-party costs handled?
- What evidence triggers acceptance?
- What precisely happens at closeout?