SaaS’s Last Mile & The Rise of the FDE
For years, SaaS companies have been able to build valuable businesses around software that solves only part of a customer's problem. The product handles the repeatable work, while the customer supplies the judgment, spreadsheets, other tools/software/data sources, and coordination required to finish. I use the 80% solution as shorthand for that arrangement, where recurring revenue can coexist with substantial work the customer still has to do.
Before AI, that arrangement often made economic sense because standardizing common requirements allowed vendors to serve thousands of customers without rebuilding their products for each one. Customers accepted the remaining work because the software still represented a substantial improvement over what came before. My concern is that we will continue defending those product boundaries even as customers gain better alternatives and expect more of the work to be completed for them.
In McKinsey's 2026 AI survey, 32% of respondents said their organizations had decided against buying at least one software product or feature because they could build the functionality internally with agentic coding tools. For those of us leading SaaS businesses, that should prompt an examination of how much of our company's value depends on capabilities customers increasingly believe they can reproduce.
I believe more of the differentiation will come from understanding the work that remains unfinished and taking responsibility for a complete customer outcome. An accounts-payable product might read an invoice and match it to a purchase order, yet leave the customer to resolve a quantity discrepancy when the buyer is unavailable and the supplier is threatening to hold another shipment. The customer's responsibility extends through resolving that dispute, paying accurately, and preserving a record of the decision.
Our software needs to reflect that broader mental model, including the decision trees people follow when information is missing or the normal process breaks down. Building a complete vertical workflow means understanding what starts the work, what determines the next action, and what must be true before the customer considers it finished. Where a person needs to exercise judgment, the product should preserve the context, route the decision appropriately, and continue once that decision has been made.
Google's speech-recognition research illustrates how much can remain unresolved after a strong technical result. In 2017, Google reported an end-to-end research model with a 5.6% word error rate, improving on a conventional system's 6.7%. Yet the new models could not process speech in real time, performed worse on live production data, and struggled to spell rare proper nouns. For SaaS leaders, the relevant lesson is that performance under selected conditions can conceal requirements that determine whether customers can depend on the product throughout their working day.
Meeting those requirements can consume disproportionate resources because each new type of exception brings questions about data, authority, and recovery that the initial build may never have addressed. Anthropic described this work in its account of developing a multi-agent research system, where production deployment required resumable execution, retry logic, checkpoints, and tracing to diagnose failures.
As you evaluate the business case, stress-test a scenario in which integration and reliability work cost five or ten times the initial build, treating those multiples as planning assumptions rather than established industry benchmarks. Include continuing operating costs and the human work that remains, so your team can judge whether the value of completing the workflow justifies the investment. A lower cost of writing code does not settle that question.
Palantir demonstrated how forward-deployed engineering (FDE) could deliver highly complex solutions by embedding engineers alongside customers. As that model spreads across SaaS, I believe its primary strategic purpose will be long-term stickiness: keeping the product aligned with the customer's business as that business changes. I see complete workflows as SaaS's eventual evolution, and for companies moving in that direction, hiring FDEs should become a core investment for customer retention.
An engineer working alongside an accounts-payable team can see why an approval keeps stalling, which spreadsheet contains the missing context, and whose judgment allows the work to proceed. With the authority to build and test changes, that engineer can turn the discovery into a process users can depend on. A competitor offering similar features would then have to demonstrate that it can deliver the same operational value, including the exceptions and integrations that make the process function.
As C-suite leaders, we need to connect this work to the company's product decisions through a regular forum where engineers can bring recurring customer problems to product leadership. OpenAI describes its FDE engagements as a way to improve products and reduce the custom work required for subsequent customers, providing a useful model for how that feedback should translate into reusable capabilities. Use those findings to guide shared integrations, operating tests, and explicit decisions about what belongs in the core platform.
The investment also needs a commercial test, because technical progress alone cannot establish whether an FDE program is earning its cost. Assess completed workflows and reductions in avoidable intervention alongside retention, expansion, and the engineering effort required to support each account. Those measures can help distinguish deployments that create lasting value from those that remain dependent on expensive manual support.
An individual engagement may still justify substantial customization through the customer's economics or through learning that applies across a valuable segment. Be explicit about that judgment, including when to decline a request whose value is too narrow to recover its development and maintenance costs. Without that discipline, the company can accumulate obligations that consume its engineering capacity without improving the underlying business.
Acquisitions can contribute expertise or missing capabilities, although their value depends on whether the combined products actually complete more of the customer's work. Bain's 2024 technology M&A report, drawing on its 2022 practitioner survey, identified failed product-portfolio integration as the most commonly cited reason for missing revenue synergies. If an acquisition is part of your last-mile strategy, require a funded integration plan that specifies how records, decisions, and responsibilities will move between products, with someone accountable for the resulting customer experience.
Our responsibility as C-suite leaders is to decide where to commit this effort while the company still has the time and resources to learn. Start with a defined customer segment and the unfinished work worth owning (given a rigorous ROI analysis), then give the people closest to it (the details) enough authority to change the product. Tie further investment to evidence that customers are willing to pay for the completed workflow.