Are FDEs a Product Advantage or a Services Cost?

Forward deployed engineers create a product advantage when their customer work produces supported capabilities that improve later deployments and sustained customer outcomes. Their delivery and support effort also has a cost. Assess both with comparable deployment cohorts, a complete account of labour, and evidence of what the next customer can use without the original engineer's help.

Turn the FDE investment thesis into a test

An AI startup may need engineers alongside customers to connect data, discover undocumented rules, and get a workflow into production. That can be necessary for a valuable product. The investor's question is whether the company can grow the resulting business without adding the same amount of bespoke engineering for every account.

A forward deployed engineer builds close to the customer's operation and takes responsibility for a defined deployment. The title doesn't establish the economics. Read our guide to what an FDE does if you need the role's boundaries; here, the focus is the evidence behind a vendor's delivery model.

In a June 2025 essay on services-led growth, a16z's Joe Schmidt argues that implementation work can help AI companies secure important workflows and build durable businesses. Treat that as an investment thesis to test in the company you are reviewing. It doesn't prove that any particular startup's delivery costs will fall or that its customer relationships create a defensible product.

The operating model continues to attract investment. AWS announced a US$1 billion investment in forward deployed engineering in June 2026, with a stated aim of leaving customers self-sufficient after deployment. That announcement demonstrates a supplier's commitment and intended model. A startup still needs its own evidence of handoff, cost, and repeatability.

Write a falsifiable claim before analysing the numbers. For example: “For distributors using the supported ERP integration, the next cohort will need fewer implementation hours at the same acceptance standard, and post-launch support per active account won't rise.” Specify the workflow, customer population, and observation period. Then ask what the company has measured against that claim.

A Reddit discussion about the FDE model asks whether early-stage startups can afford engineering-heavy delivery. It reflects a reader's concern, rather than measured economics across startups. Answer the question with the company's realised delivery work and contract terms, rather than another vendor's headcount or reputation.

Count the work across the customer lifecycle

Start with the complete path from prospect to supported operation. Include technical sales work and failed pilots in the broader acquisition analysis. For each signed account, record discovery, integration, data preparation, testing, training, and the work required after launch. Track founder and core-engineer involvement as well as the people with FDE titles.

Separate elapsed time from staff hours. A project can wait three weeks for access while using little engineering effort. Another can reach production in five days because several engineers work in parallel. Both measures matter: elapsed time affects customer value and cash timing, while hours help explain cost and capacity.

Define the production milestone before reporting time to production. A live endpoint, a first completed business case, and a workflow the receiving team operates at its agreed quality level describe different achievements. Track the date of customer acceptance and any limits on volume or case type. Don't count a demonstration as the end of implementation.

Include work outside formal tickets. A founder answering messages each evening, an engineer repairing inputs before a run, and a support team checking outputs manually can sustain apparent automation. Record those activities with a practical time-capture method. Missing logs mean the estimate has a coverage limit, rather than zero labour cost.

Keep time categories stable across periods. If an employee moves from the FDE team to core engineering but keeps repairing the same customer workflow, the work still belongs in the operational analysis. A change in reporting line doesn't establish a reduction in delivery effort.

For an SME or corporate buyer, collect your own contribution too. Staff who gather records, resolve rule conflicts, or review every output consume capacity. A vendor's efficient delivery model can still impose substantial work on the buyer. Agree which team owns that work and compare the whole process with the alternative.

Compare deployments that ask for similar work

Group accounts by when they started and by the complexity that affects delivery. Relevant differences include the source systems, workflow scope, data condition, and approval requirements. Record which product version each account uses. An improvement claim needs to show that later customers received comparable scope and quality.

Report the median and the spread, alongside the account count. A single easy customer can make a small cohort look much better. Show difficult deployments, stopped pilots, and accounts that have not reached acceptance yet. Excluding unfinished work can make recent cohorts appear artificially fast.

Match support exposure as well. Compare the first 90 days after acceptance with the same period for older accounts, or use another clearly stated window. A customer with two weeks of production history hasn't had the same opportunity to generate incidents as a customer with a full quarter. Keep partially observed accounts visible.

If later deployments need fewer hours, ask why. A supported connector may reduce integration work. A narrower sales promise may reduce scope. Better customer data may reduce preparation. All can change cost, but only some demonstrate a stronger product at the same scope.

Use case records to explain the movement. Trace an older deployment's recurring problem to a release and a later customer's use of that release. A cohort chart supports the investigation; it doesn't establish causality by itself. State other changes, including staffing, prices, or the customer mix.

Reconcile delivery effort with gross profit

Request the company's reported revenue and cost definitions, then a bridge to the delivery effort you observed. Separate recurring product revenue from implementation fees and ongoing service charges. Ask finance to explain revenue recognition and cost allocation. Contract value, cash collected, recognised revenue, and annual recurring revenue describe different things.

Use a supplementary operating view that captures the labour required to deliver and support the promised customer outcome. Apply a stated cost per hour that includes the costs finance agrees belong in that estimate. Reconcile it with reported accounts and label any differences. This view supports diligence; it doesn't replace the company's accounting policy.

Consider an illustrative first-year account, with assumed figures in Australian dollars and no claim that they represent a market benchmark. The contract has A$120,000 of product fees and A$20,000 of implementation fees for the period. Assume the company recognises all A$140,000 within that year for this example.

The account needs 300 implementation hours at an assumed loaded cost of A$150 per hour, giving A$45,000. It then needs ten support hours per month for 12 months, giving A$18,000. Model and hosting usage cost A$12,000. The operating view therefore has A$75,000 of identified delivery costs and A$65,000 left before any costs it excludes.

That A$65,000 is about 46% of the assumed recognised revenue. Call it an illustrative delivery contribution under these definitions, rather than reported gross profit. The example excludes sales and general overhead, shared product development, and any other costs finance identifies. Reconcile those before using the result in an investment model.

Now assume a comparable later account needs 150 implementation hours and five support hours per month, while prices and usage costs stay the same. The identified costs become A$22,500 for implementation, A$9,000 for support, and A$12,000 for usage: A$43,500 total. The delivery contribution becomes A$96,500, about 69% of A$140,000.

The difference is A$31,500 per account under the assumptions. It isn't free: the company may have paid core engineers to build the shared capability that reduced those hours. Assess that development spend separately, count it once, and test whether enough accounts will adopt the capability to justify it. Don't omit the product investment or charge its full cost repeatedly to each customer.

Test renewal economics separately from the first year. If the implementation fee doesn't recur, remove it from the renewal revenue model. Use observed support, usage, and maintenance costs over the renewal period. A paid initial project can have attractive economics while the recurring contract needs more support than its price covers.

Verify that field learning reaches the product

Ask for a chain of evidence: a customer problem, a product decision, a supported release, and another customer's deployment that uses it. The next engineer should install and operate the capability without depending on its original author. Documentation and release ownership make that test possible.

A shared library can reduce work without becoming a customer-facing product option. A deployment playbook can prevent recurring mistakes. A supported connector can remove bespoke mapping code for a defined system. Name the asset and the scope it supports, then measure the change in delivery effort and outcomes.

A copied customer script provides weaker evidence if every copy needs separate repair. Count live forks and incompatible versions, and identify who maintains them. A vendor can complete more deployments while accumulating an expanding support obligation. Gross profit growth needs a delivery model that accounts for that obligation.

Roboflow's current FDE role description connects initial production deployment with feedback to Product and Engineering, followed by a handoff to implementation engineers once the customer can operate the result. That illustrates explicit delivery boundaries. It doesn't establish Roboflow's account margins or prove that a startup using the same title has an equivalent process.

Check the commercial rights and access boundaries around reuse. A reusable pattern doesn't require moving confidential customer records into another customer's environment. The company needs permission for the code and data it uses, and an implementation that preserves account isolation. Where rights are unclear, request qualified review rather than assuming that technical reuse is allowed.

Our article on when customer-specific FDE work should enter the product covers the implementation decision. For investor diligence, request the before-and-after evidence and the receiving owner. A backlog of promising ideas provides less evidence than a release another customer uses successfully.

Test support ownership and delivery capacity

New implementations compete with old accounts for engineering time. Show the committed delivery pipeline and the support obligations of the installed base. Include incidents, source-system changes, and expected maintenance. Capacity planning needs the hours available for new work after those obligations.

For an illustrative team with four FDEs, assume each has 120 workable hours per month after leave, meetings, and other duties. That gives 480 hours. If existing accounts consume 180 hours of support, the team has 300 hours for new delivery. At 150 hours per implementation, that supports two implementations per month under the assumptions.

If support rises to 300 hours, capacity for new delivery falls to 180 hours. Selling three new implementations each month then creates a backlog unless the company changes staffing, scope, or support demand. Better code-generation tools don't remove that arithmetic; the team needs evidence that total delivery hours actually fall.

Ask whether another engineer can take over an account. Inspect the runbook, monitoring, access process, and acceptance criteria. Interview the receiving team about recent incidents. A handoff that depends on the original FDE joining every call can leave customer continuity and new sales exposed to the same person.

Separate constraints the product can address from work the customer must own. A shared connector can simplify installation, but a customer may still need to reconcile its records or decide an approval policy. Price and scope that responsibility explicitly. A vendor claiming a standard rollout while absorbing unlimited local process repair needs a revised commercial model.

A PE operating team can apply this analysis to a common vendor across portfolio companies. Check support capacity across the whole installed base before adding another company. For an internal corporate platform, replace vendor revenue with the approved operating budget and compare delivery cost with verified outcomes; don't invent a SaaS margin for internal work.

Request evidence that connects the story

Request a deployment ledger with start dates, acceptance dates, scope, product version, hours by activity, and current status. Ask for a consistent support window, the account count behind each cohort, and the difficult or stopped cases. A spreadsheet with links to controlled records can be enough if the definitions and coverage are clear.

Request the commercial bridge: contract terms, recognised revenue, implementation fees, recurring charges, and allocated delivery costs. Finance should explain discounts and any free engineering bundled into a sale. Keep the operating cost view connected to reported figures so a renamed expense can't create apparent margin improvement.

Request a small set of product-reuse cases. For each, inspect the original field requirement, release record, named maintainer, and later customer's use. Ask for an implementation by an engineer who didn't build the original component. Include quality results and support effort, rather than measuring reuse by the number of shared lines of code.

Request references from a recent launch and a mature account, with the customers' consent. Ask who operates the workflow, how much help they still need, and what changed after the FDE left. Verify the result the customer buys, such as correctly completed orders, rather than only whether staff liked working with the engineer.

Finally, request a capacity plan linked to the sales pipeline and existing support load. Show the assumptions for hiring and onboarding, plus the impact of a large incident or delayed customer access. If the records are incomplete, state which claims you cannot verify and agree a bounded observation period to collect the missing evidence.

State what would change the conclusion

An improving delivery model has comparable later cohorts using less labour at an equivalent quality standard, with supported reuse and manageable ongoing support. Customers can operate the result, and finance can reconcile the cost improvement. That evidence can support the claim that field work strengthens the product.

A services-heavy model can still deliver valuable outcomes and earn a return. Assess it using explicit scope, pricing, utilisation, and support commitments. If every account needs a distinct build and continuous engineering, model that requirement in growth plans. Calling the team forward deployed doesn't change its staffing needs.

An early company may not yet have enough comparable deployments to establish a trend. Fund the next evidence-gathering step against a stated learning budget and customer scope. Set a review point with the required records and acceptance conditions. A forecast that assumes declining hours needs a date when observed results can support or reject it.

Lower support effort, independent handoff, and a shared release adopted by another customer can strengthen the conclusion. Rising manual repair, hidden founder labour, or falling acceptance quality can weaken it. A stronger contract value may improve economics, but show whether it reflects broader scope, a price change, or a better product.

Use the next deployment as a test of the claim you wrote at the start. Ask the receiving engineer to show what they reused, the customer to show the completed outcome, and finance to show the delivery cost. Those accounts of the same deployment give you a concrete basis for deciding what to fund next.