How FDE Outcomes Are Measured and Contracted | Engineering Hours as Investment, Not Billing

Hello, this is Ryuta Hamamoto from TIMEWELL.

This is the ninth article in our FDE practice series. So far I have covered the skills used on site, how a week is run, and the market numbers. This time I want to write about the premise that holds all of it up: how outcomes are measured, and how the work is contracted.

We keep saying that an FDE's engineering hours are investment, not revenue. It sounds good, but unless outcomes are measured and contracts are structured differently from contract development, it is only a turn of phrase. If hours are sold by time, the work ends at acceptance, and nothing is taken back into the product, it is contract development under another name. This article states plainly what we measure, what we write into the contract, what we treat as the customer's, and what we return to the product. If you first want to check which model your own contracts are closer to, take the AI literacy check.

What to measure: the person's day, not technical metrics

First, what gets measured. We do not measure outcomes by technical metrics. Accuracy of 95 percent, response time of two seconds, uptime of 99.9 percent: these are product-quality metrics, not outcome metrics. Outcome metrics live in the person's day. Did approval waiting go from 47 minutes to 12? How many fewer send-backs per week? How many fewer overtime hours at month-end close?

The method is the one in the video-analysis article. Count the same task before the working artifact goes in. Count again the following week. The difference is the outcome. Without filming consent, count from the five-column observation record. As long as the counting method stays the same, the differences are comparable.

Why not technical metrics? Two reasons. First, measuring by technical metrics ends the evaluation before anything reaches production. Ninety-five percent accuracy can be achieved in a meeting-room demo. A twelve-minute approval wait can only be achieved once the person uses the artifact every day. Second, as the person who led Palantir's commercial business wrote, the FDE is a CEO with zero authority over the customer's business, accountable for business outcomes rather than deliverables.¹ Business outcomes cannot be written in technical metrics.

Metrics are split across three layers: industry metrics for executives, this year's numbers for division heads, daily time for the shop floor. As the interview article explains, the three layers want different things from the same project. So we set three metrics and look, in the first week, for the one point where all three move in the same direction. If a line can be drawn from "shortening the shop floor's approval wait" to "shortening the division's shipping lead time" to "the delivery competitiveness the executives talk about," we measure all three along that line. If no line can be drawn, we do not take the engagement.

Hours as investment, not revenue: three ratios we watch

Next, how hours are viewed. In June 2025, a16z's Joe Schmidt wrote about trading short-term gross margin for depth: thickening the implementation, accepting lower margins for a time, to buy the moat of owning the entry point to the customer's operations.² In January 2026, a16z's Marc Andrusko described the real model as having explicit time-boxed deployments and engineering-to-ARR ratios, with engineering effort declining on mature accounts.³

We watch three ratios. First, the trend of on-site hours per customer. From week one to week eight, is the time our engineer spends on site falling? If not, either the person has not yet started editing the dictionary, or things are stuck at the write stage. Second, the count of patterns returned. How many patterns from the engagement became standard product features? Zero means the engagement was all branches and will not help the next customer. Third, the reuse rate. At the next customer, how many patterns returned from the previous one got used? The higher that ratio, the faster code goes out on day one at the next customer.

These three run in the opposite direction from contract-development metrics. In contract work, on-site hours are revenue, so more is better, and learning is the customer's asset, so it does not flow back. For an FDE, fewer on-site hours are better and more learning returned to the product is better. That is why hours are investment. And because they are investment, we cannot take an engagement where recovery is not in sight. An engagement from which no pattern is likely to emerge, one made only of branches unique to that company, is better served by contract development than by us. We say so plainly.

Palantir's numbers show where these ratios go over the long run. A former FDE recalls that the company was seen as a services firm around 2016, but by continuing to return learning to the product it reached an 80 percent gross margin in 2023.⁴ When hours are recovered as investment, margins approach software levels.

The contract: neither fixed scope nor billable hours, but a time box, outcome metrics, and exit conditions

Now the contract. System-development contracts in Japan fall broadly into two types. In the Civil Code, a contract-for-work is one in which a party promises to complete a piece of work in return for payment, and a quasi-mandate is one in which the handling of affairs other than legal acts is entrusted; they are placed as distinct types.⁵ Which applies is determined by the substance, not the title on the document.

The FDE fits poorly into either. A contract-for-work promises completion, but an FDE updates a working artifact every week and the definition of "complete" changes weekly. A quasi-mandate sells hours by time, but a structure in which staying longer means more revenue is the opposite of the FDE's purpose of leaving sooner. So we write the following six clauses into the contract and then confirm the legal classification with counsel.

Clause	What it says
Period	The time on site is boxed at 45 to 90 days. Extensions require a rewritten purpose and a separate contract
Outcome metrics	The three-layer metrics and how they are counted before and after. Technical metrics are placed separately as quality conditions
Where learning belongs	Patterns to our product, branches to the customer's extensions, dictionary contents to the customer
Four conditions for writes	Permissions, prior simulation, human involvement on significant decisions, audit record. No writes to production until all four are in place
Additional requests	A pattern goes onto the product roadmap at no extra charge; a branch is absorbed by configuration or declined with reasons
Exit conditions	The person can update the dictionary themselves, the outcome metrics are visible to the person, and patterns have returned to the product

The fee structure is also split in two: a product usage fee and a time-boxed deployment fee. The deployment fee is tied to the period and the outcome metrics, not to an accumulation of hours. Pricing by hours writes the incentive to stay into the contract. Pricing by period writes the incentive to leave into it.

This is not our invention. The FDE organization AWS launched in June 2026 puts the customer's ability to run things themselves at the end, meaning working systems, documentation, and trained in-house staff, at the center of its design.⁶ The Anthropic and FIS partnership states that the point of embedding FDEs is not to stay indefinitely but to transfer knowledge so that FIS can run on its own.⁷ OpenAI's deployment company publishes a typical engagement that begins with a diagnostic of value and selects a small number of priority workflows.⁸ Decide the end at the start, measure outcomes in the work, hand over the learning. We have translated the pattern common to those three announcements into contract clauses.

Where the learning belongs: patterns to the product, branches to the customer, dictionary contents to the customer

The clause most likely to cause friction, and the most important, is where the learning belongs. An FDE learns the customer's operations on site. Say that what is learned returns to the product, and the customer hears "you're taking our business knowledge with you." Naturally. So we split it three ways in the contract.

Patterns return to our product and are ours. "Approval can have multiple stages." "Exceptions branch on a category." "Urgent cases need a separate route." These are the structures a16z's Andrusko called reusable primitives, the data models and workflow components.³ They belong to no particular company; they are the structure of operations in general.

Branches are held as customer-side extensions and belong to the customer. "Tanaka in accounting holds that paper." "This form is only used at month-end." Procedures unique to that company. They stay out of the product and live in the customer's environment as configuration or extensions.

Dictionary contents belong to the customer. These are the company's nouns, verbs, relationships, states, and exceptions from the ontology article. What returns to the product is the structure "an order has states," not the content "this company's order states are received, awaiting approval, approved, shipped." The content is the customer's, and we do not carry it to the next customer.

Writing this three-way split into the contract lets the customer show us their workplace with confidence. Without it, an FDE looks like someone carrying off business knowledge, and the people on the floor show only the process as it should be. Spelling out ownership is, before it is a legal matter, the condition for being shown the real work.

How it differs from contract development

Here is the difference in contractual terms.

Aspect	Contract development	FDE
Nature of hours	Revenue; longer is better	Investment; fewer per customer is better
How outcomes are measured	Acceptance (does it match the spec?)	The person's daily metrics (before-and-after difference)
Handling changes	Extra cost and a new quote	Pattern: no extra cost; branch: configuration or decline
Where learning belongs	The customer's asset	Patterns to the product, branches and dictionary contents to the customer
How it ends	Acceptance and withdrawal	The person runs it themselves and we are no longer needed
Incentive to extend	Built into the contract	Kept out of the contract

The biggest difference is keeping the incentive to extend out of the contract. In contract development, hours are revenue, so extension is a natural incentive. For an FDE, the fee is set by period and the exit is written in outcomes, so an extension is a separate contract with a rewritten purpose. That design is the line that separates FDEs from contract development.

The other difference is the handling of changes. In contract development, a change in requirements means extra cost and a new quote. For an FDE, a change that is a pattern goes onto the product roadmap at no extra charge, and a change that is a branch is absorbed by configuration or declined with reasons. Saying no to customization, one of a16z's pressure tests,³ is only possible with that clause in the contract.

What we do and where it stops

Let me be honest. This structure cannot be set up at every site.

Some sites have no outcome metric. Work where the person's day cannot be counted, where judgment itself is the work and time does not measure it. There we look for substitute metrics, the number of send-backs or the number of pieces of information used in a judgment, and if none can be found, we do not take the engagement under this structure.

Some sites cannot hold the period: long security reviews, no decision on who owns the data, no time from the person. Where the conditions for speed described in the one-week article are missing, the 45-to-90-day box does not hold. We confirm those conditions at the first meeting, and if they are missing we delay the start until they are met rather than lengthening the period.

Some sites produce no patterns: operations made entirely of branches unique to that company, from which no pattern useful to the next customer is likely to emerge. There the hours cannot be recovered as investment, and contract development suits the customer better than we do. We say so in the sales conversation.

And our capacity. As a small company, we can be at only so many sites at once. The person who asks, builds, and returns learning to the product being the same person is the reason for our speed and, at the same time, the ceiling on our capacity. We do not hide that ceiling.

Summary

An FDE's hours can be called investment because outcomes are measured by the person's day, on-site hours per customer fall, patterns return to the product, and they are reused at the next customer. The contract is neither fixed-scope nor billable hours but six clauses: a 45-to-90-day period, three-layer outcome metrics, the three-way ownership of learning (patterns to the product, branches to the customer, dictionary contents to the customer), four conditions for writes, the handling of additional requests, and self-sufficiency as the exit condition. The fee is split into product usage and a time-boxed deployment fee, never an accumulation of hours.

The line between this and contract development is keeping the incentive to extend out of the contract. A contract that earns more the longer you stay is contract development; a contract that creates more value the sooner you leave is an FDE.

If you want to restructure your AI deployment contracts this way, or want to tell which model a vendor's contract belongs to, take a look at the WARP program or talk to us. The next article closes the series with how to develop FDEs: the training and evaluation through which engineers acquire field skills.

Footnotes

1. Sorry, that isn't an FDE (Ted Mabrey, September 21, 2024). The "CEO with zero authority" framing and accountability for business outcomes rather than deliverables are from this essay ↩

2. Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups (Joe Schmidt, a16z, June 2025) ↩

3. The Palantirization of everything (Marc Andrusko, a16z, January 16, 2026). Time-boxed deployment, engineering-to-ARR ratios, reusable primitives, and the pressure tests are from this essay ↩ ↩² ↩³

4. Reflections on Palantir (Nabeel S. Qureshi, October 15, 2024) ↩

5. Civil Code (Act No. 89 of 1896), Article 632 (contract for work) and Article 656 (quasi-mandate). e-Gov statute database, in Japanese ↩

6. AWS invests $1 billion to embed AI forward deployed engineers with customers (Amazon, June 30, 2026) ↩

7. FIS Brings Agentic AI to Banking with Anthropic, Starting with Financial Crimes (FIS, May 4, 2026) ↩

8. OpenAI launches the OpenAI Deployment Company (OpenAI, May 11, 2026) ↩