The short answer. At many software companies, very little of it. Gartner forecasts that through 2028, fewer than 20% of forward-deployed engineering engagements will turn recurring customer needs into capabilities in the vendor’s core product.
Custom work becomes product only when two things exist in the engineering organization. The first is a boundary in the code between logic every customer shares and logic one customer needs. The second is a single way to deploy one version to every customer. Without both, each engagement adds another installation the company has to maintain.
Five questions below show where a portfolio company’s custom work is actually going.
Research Grounding
Gartner, September 29, 2026. Gartner predicts that by 2028, 70% of enterprises will abandon agentic AI built by a vendor’s forward-deployed engineers. It cites rising costs and the customer’s inability to evolve the systems on its own. Forward-deployed engineers are vendor engineers placed inside a customer to build a solution in the customer’s environment.
Gartner, same release. Through 2028, fewer than 20% of these engagements will turn recurring customer needs into capabilities in the vendor’s core product. Gartner also warns of FDE washing, where ordinary implementation or consulting work is relabeled as forward-deployed engineering.
California Management Review, September 14, 2026. An essay in the Berkeley Haas journal asks whether forward-deployed engineering is a return to consulting dependency. It notes that these engineers work for the vendor, not the client, and that consulting-style incentives tend to expand scope.
Both Gartner figures are forecasts, not measured outcomes. The direction is still useful. Customers are being told to plan for running vendor-built AI without the vendor’s engineers. Vendors are being told that most of this work will not reach the product.
For a portfolio software company, the second forecast is the one that applies. It describes the vendor’s own engineering, not the customer’s.
The PE Translation
Many portfolio software companies now sell AI through a team that builds agents and workflows inside each customer. The work can win deals and generate implementation revenue.
A board will normally review this revenue by customer count and growth. The more important question is what the engineering organization keeps after each engagement ends.
Each customer-specific build leaves the company with something it can reuse, a separate installation it must support, or some of both. The more a company’s builds leave only separate installations, the more its AI business operates as a services business.
The cost of separate installations grows over time.
WHAT CHANGES | WHAT IT DOES TO A CUSTOMER-SPECIFIC BUILD |
|---|---|
The model provider releases a new model version | Customer-specific agents may need separate compatibility testing, especially where their prompts, tools, and model settings differ |
The product releases a new version | Each customer variation has to be checked for compatibility before the upgrade |
The engineer who built it leaves | The knowledge of that customer’s logic often leaves with them |
The customer asks for a change | The change may need customer-specific development and testing |
AI coding tools make this harder to see. They make custom engineering faster to produce, so a team can create customer variations faster than it can maintain them.
A custom build may generate one-time delivery fees. It also creates support and upgrade obligations that continue for as long as the customer stays.
Cost. Every customer-specific installation adds testing, upgrade, and support work. That work scales with the number of customers rather than with revenue.
Revenue. Gartner expects 70% of enterprises to abandon agentic AI that vendor engineers built for them. An abandoned agent puts the related subscription, consumption, and expansion revenue at risk.
Valuation. Recurring product revenue usually receives more favorable treatment from a buyer because it is more predictable and scalable. Implementation revenue usually receives less because it depends directly on people. A buyer will examine how much of the AI revenue depends on shared product and how much depends on customer-specific delivery when it assesses margins, scalability, and revenue quality.
Operator Experience
Promotion into the product starts with a boundary in the code, before any pricing decision.
I led this change at a K-12 analytics company that began as a services business. Every customer had its own stored procedures for loading and transforming data. The team had best practices, connectors, and code that looked similar from one customer to the next. Some of it was shared, and some wasn’t. None of it was a product.
We made two changes in parallel.
We moved the data transformation logic into one framework. We replaced the per-customer stored procedures with a transformation framework similar to dbt. Inside it, we separated the logic every customer shared from the logic one customer needed. The shared logic became the product.
We made deployment repeatable. We moved deployment from customer premises to the cloud. We first automated it with Ansible and our own scripts, and later standardized on Terraform.
The services team continued to write each customer’s specific logic. The product team built defined places where that logic attached to the framework. Engineering did not write or maintain customer-specific code.
That division is what made the model work. Engineering owned the shared product and the interfaces. Services owned the customer logic and priced it as services. Neither team had to guess who maintained what.
The same two conditions apply to AI agents today. An agent built inside one customer’s environment, with its prompts, tools and data connections written for that customer, has no place to go back into the product. A team that wants promotion must first decide which parts of an agent are shared and where the customer-specific parts attach.
Board Question
Of the custom AI work we delivered last year, how much can we deploy to the next customer without rebuilding it?
Four Places Customer-Specific Work Can Go
Before sending any work to one of the four destinations, management should decide whether to accept the request at all. A request with little reuse potential and a long maintenance tail can cost more than it earns.
DESTINATION | WHEN IT FITS | WHO BUILDS AND MAINTAINS IT | WHAT IT DOES TO THE ECONOMICS |
|---|---|---|---|
Core product | Several customers need it | Product engineering | Built once, maintained once. It does not have to be switched on for every customer |
Configuration | The difference can be expressed in settings the product already has | Services or the customer, using existing settings | Little added delivery or maintenance cost |
Supported extension | A specialized need that fits a documented interface | Services, a partner or the customer writes it. Product engineering owns the interface and its compatibility | Customization without a separate version of the product |
Paid services | A need specific to one customer | Services | Priced and supported as services, with stated limits |
The decision that matters is made at the start of each engagement, not after it ends. Code written without a destination often creates support obligations that nobody priced, and nobody agreed to maintain.
Five Questions to Ask About Customer-Specific Engineering
QUESTION | WHO ANSWERS | WHAT A WEAK ANSWER SOUNDS LIKE |
|---|---|---|
1. Where does the code for each customer-specific engagement live, and how does a fix reach every customer? | CTO | Each customer has its own codebase, and we merge fixes across them by hand. |
2. Which components built for one customer in the last four quarters are now used by another customer? | Head of product | We will productize it once more customers ask. |
3. Does the product have documented places where customer-specific logic attaches, and who keeps them compatible across releases? | Lead architect | The services team knows where to put it. |
4. When the model provider releases a new version, how many customer deployments have to be tested separately? | Platform lead | We find out when a customer reports a problem. |
5. Who decides whether a customer request is accepted, and which destination it goes to? | CEO with the head of product | Sales commits, and engineering finds a way. |
The first weak answer means every customer runs a separate version of the product. The fourth means the company’s maintenance cost rises each time a model provider ships an update.
The fifth question is the one that ends in a decision. A request accepted without a destination creates delivery obligations that were never priced or planned.
Three Decisions
1. Classify last year’s custom work
Ask the CTO and the head of product to place every customer-specific engagement from the last four quarters in one of the four destinations, or mark it as work that should have been declined. Give them two weeks. The result shows how much of the AI revenue is product and how much is services.
2. Build the boundary and the deployment path
Fund a defined place in the product for shared logic, documented interfaces for customer logic, and one way to deploy a version to every customer. In my experience, promotion of custom work stays slow and manual until both are in place.
3. Put a destination on every new engagement
Require a short product review at the start and end of each customer-specific engagement. The start review assigns a destination. The end review confirms where the code actually went. Price paid services as services.
One Number for the Next Operating Review
Core-product conversion rate: the percentage of customer-specific engagements in the last four quarters that produced at least one capability now part of the shared product.
Report it next to the share of engagements that involved configuration, supported extensions, or separately maintained services. One engagement can involve more than one of these, so the shares do not need to add up to 100%. Track the revenue and delivery cost of each category separately. Together, these measures show how much custom engineering creates reusable capability and how much ongoing delivery work the company keeps.
Gartner forecasts that fewer than 20% of forward-deployed engagements will turn recurring customer needs into core-product capabilities through 2028. That figure is a forecast, not an industry benchmark. The number answers whether each engagement adds something the company can deliver to the next customer without rebuilding it.
Board Takeaway
Custom AI engineering can win customers and still leave the company with a growing list of separate installations to support.
Before approving the next forward-deployed hire, ask what share of last year’s custom work is now used by a second customer.
Portco Brief is a weekly briefing for PE operating partners and portfolio company executives focused on technology, AI, and value creation. If this was forwarded to you, subscribe at portcobrief.com.
Sources
Gartner, Gartner Predicts 70% of Enterprises Will Abandon Agentic AI Built by Vendor Forward-Deployed Engineering by 2028, September 29, 2026.
California Management Review, AI Reinvention Series: Rented, September 14, 2026.