What happens when your FDE discovers that the customer needs something different from what you agreed to build? That discovery is part of the value of working directly with users. But if the agreement commits your team to a fixed feature list, acting on it can mean renegotiating the project. The engagement needs to allow for learning without leaving the customer unsure what they are paying for.
Suppose a software company provides an FDE as part of an implementation to help its customer resolve service requests faster. The first release puts the relevant information in front of the person handling the request. Once people use it, the team discovers that a large part of the delay happens while waiting for another department to make a decision. The customer could get more value from a faster handoff than from the remaining features in the proposal.
I'd want the agreement to let the team act on that discovery within an agreed spending limit. Both sides need to know who can approve a change and when further work requires another commitment. Otherwise, every useful discovery risks becoming either a scope dispute or work nobody has agreed to fund.
Initial scope and commitment
The first commitment can be small enough to investigate whether your product can help with a particular customer problem. The FDE needs access to people doing the work and enough of the customer's systems to test the assumptions behind the proposed implementation. That investigation should leave both sides able to judge whether delivery is worth funding and what still needs to be resolved.
OpenAI sets out a similar sequence in its Deployment Company announcement. A focused diagnostic precedes jointly selected workflows and embedded engineering. That gives the customer a chance to understand the proposed work before making a larger commitment. It also gives the provider a chance to discover that its product is a poor fit. It may not address the underlying problem, or adapting it to the customer's workflow may cost more than the expected improvement is worth.
Who pays for this work depends on the business model. Palantir reports that it generally funds its own pilots and bootcamps. It incurs those costs without assurance of future revenue. A consultancy may charge for discovery as a separate engagement. In either case, the initial agreement should say what the investigation covers and what would require additional funding. A successful demo can still leave production costs and responsibilities to be agreed.
Customer and provider responsibilities
An FDE can have production access and excellent engineering tools while spending most of the engagement waiting for answers. The customer needs someone who understands the workflow and can make decisions about how it should change. That person also needs access to users and colleagues who control the relevant systems. A sponsor has to help when the work crosses departmental boundaries or competes with other priorities.
The provider also needs to decide what authority its FDE will have. An FDE may understand the customer's problem and recommend a change while depending on another engineering team to deliver it. I'd want a named engineering lead responsible for that work and its quality. The account owner needs authority to resolve commercial questions. Those responsibilities can sit with the same person when that person has the authority and capacity.
Product management also needs to connect the customer's request to the wider product roadmap. Product management for agentic engineering explains how that work relates to engineering's responsibility for reliable delivery.
Agree who on each side can approve a revised priority within the budget. When a proposed change needs more money or time, those people should be able to authorize a new commitment or pause the affected work. If customer participation or system access is delayed, explain what can still proceed and how the delay affects fees before the allocation is spent waiting.
Where an implementation partner is involved, establish which company the customer contacts when a problem crosses the boundary between the product and its implementation. The customer should have a named person responsible for coordinating the answer.
Production acceptance and follow-through
A demo can show how the proposed solution would work for the customer. Before people depend on it, the team needs to test whether the information is current, access permissions work and failures can be detected and handled. Agree who accepts the release and who takes responsibility once it is in use.
The engagement also needs time after release to find out what happens. A process that runs once a month cannot be assessed properly if the team ships in the final week of its contract. Allow enough time to observe a complete cycle and act on the findings.
KPN's work with McKinsey continued through a daily review cycle after its customer-service agents went live. According to McKinsey's account, the team reviewed real customer calls and used what it learned to change prompts and release improvements. The budget needs to accommodate that work at a frequency suited to the customer's workflow and the consequences of failure.
I'd agree on that observation period while planning the first release. Otherwise, the customer can reach the end of the engagement with working software and little evidence about whether it improves the job.
Fees, capacity and ongoing support
A customer can reasonably assume that a recurring invoice includes help with the system they are using. If the fee covers only platform access and support, a request to improve a workflow can become another pricing discussion. I'd spell out the implementation work and ongoing engineering capacity in the proposal even if the charges are bundled.
The investment can have a ceiling while the solution changes. Atomic Object uses a capped time-and-materials approach with flexible scope and regular budget reviews. An FDE engagement could use that approach to let the team revise its implementation while keeping the customer informed about the work remaining and the money available.
A longer commitment can make sense when the customer has continuing implementation needs. The team can apply what it has already learned about the customer's business to each new problem. For a retainer, I'd identify who will choose the next problem and assess the result before agreeing how much engineering time to reserve.
Agree how much capacity is reserved for improving the customer's workflow and how support requests affect that commitment. If support consumes that capacity, make the tradeoff explicit so the customer knows which improvements will be delayed. The agreement also needs to distinguish defect correction from additional work so the customer understands when a repair is already covered.
Sometimes the FDE discovers a gap in the vendor's shared product. The engagement owner needs to confirm the product team's commitment before proposing a plan that depends on a future release. Until the change is available, the customer may need a temporary implementation or may choose to pause the affected work. Be explicit about who pays and who will maintain any workaround.
Customer capability and handoff
The customer may want its own team to operate and extend the implementation. In that case, training needs to happen while the FDE is still available to help with real work. Documentation can explain a system without showing whether the receiving team can diagnose a failed integration or judge the effect of a change.
In Palantir's guidance for mature Foundry programs, customers take on daily operation and new development while Palantir provides targeted help. As the customer's team takes on more of the work, the vendor can reduce its FDE allocation while continuing to supply the platform.
I'd make the handoff depend on the receiving team's ability to do the work it is taking over. Have that team handle routine changes and investigate failures while help is available. Where the customer prefers the provider to keep operating the implementation, agree what that service includes and how issues will be escalated. Either arrangement needs an operating owner and funding beyond the initial delivery.
Results and the next commitment
In the service-request example, the customer should be able to see whether requests are resolved sooner and whether more cases are being reopened. Collect those measures before and after each change so a faster response does not conceal an unresolved problem. Reviews with users and the sponsor should draw from the same measurements and definitions.
Those results can justify further investment without determining the provider's fee. If payment does depend on the outcome, both sides need a credible way to assess the provider's contribution. A faster system may have little effect if another department continues to take a week to approve a decision. The FDE can identify that dependency, but the customer controls the approval policy and the people applying it.
I'd be cautious about putting most of the fee at risk while dependencies like that remain unresolved. If part of the fee depends on results, agree how those results will be measured and how changes elsewhere in the customer's business will be taken into account. Both parties need to be able to question the findings even when that affects the payment.
I'd use each review to ask what the customer would gain from funding the next piece of work. If the result is still uncertain, explain what the team needs to investigate and what that will cost. The customer can then choose whether to fund another iteration, change the ongoing allocation or finish the engagement.
Use Scoping an FDE project to define the delivery boundaries. Building an FDE practice covers the organizational capabilities needed to sustain this way of working.