When a portfolio company executive asks for budget to build software, the operating partner is rarely being asked a technical question. The request usually arrives wrapped in commercial language: a competitor ships faster, the sales team cannot quote without three spreadsheets, the billing system loses revenue at renewal. Custom software development for portfolio companies is where a large chunk of the value-creation plan either gets funded or gets deferred, and the decision sits with the operator who has to defend the spend at the next board meeting.
The problem is that most build requests reach the operating partner already shaped as a foregone conclusion. Someone has decided what to build. The work is to interrogate whether that build maps to the deal thesis, what it costs to run after launch, and who owns it when the developer who wrote it leaves. This guide sets out the decisions an operating partner actually holds and how to judge the work against them.
1. Start with the enterprise-value question, not the feature list
A build proposal that leads with features has skipped the only step that matters to the deal. Before a line of code is scoped, the operating partner should be able to state which lever the software moves: revenue growth, EBITDA expansion, cash-flow timing, faster integration of an add-on, or reduced operating risk. If nobody can name the lever in one sentence, the project answers a personal preference rather than a value-creation requirement.
Bain’s annual Global Private Equity Report has documented for years how firms increasingly rely on operational improvement rather than multiple expansion to generate returns, which puts software that lifts margin or accelerates growth squarely inside the value-creation plan. You can read Bain’s ongoing work at the Bain Global Private Equity Report. The test is simple: a build that cannot be tied to one of those levers does not belong in the plan this year.
2. Decide build, buy, or configure before scoping anything
The default answer for most portfolio companies is buy, then configure. Custom software earns its cost only where the process is a genuine source of differentiation or where no vendor covers the workflow. A bespoke CRM is almost never justified when a configured platform will do the job. McKinsey’s private capital research has repeatedly flagged over-customization of standard systems as a source of technical debt that suppresses margin, and you can follow that body of work at McKinsey.
For revenue systems specifically, most portfolio companies get further by configuring what they already own than by building parallel tooling. The reasoning behind that call is laid out in this piece on Salesforce RevOps for PE portfolio companies. Custom development should sit on top of the platform of record rather than operate as a separate system.
3. Separate one-time build cost from the cost to run it
The build quote is the smaller number. What the operating partner has to underwrite is the total cost of ownership: hosting, monitoring, security patching, the developer capacity to fix things when they break, and the eventual rewrite. A common failure is approving a fixed build budget and treating the software as done at launch, when in practice a live application needs a standing owner and a monthly run-rate cost that shows up in EBITDA every period after.
Classify the value the same way. Enterprise-value improvement from a build is usually forecast or enabled at approval, and only becomes realized once adoption and the financial result are measured. Do not let a forecast number sit in the model as if it were already in the bank.
4. Name the owner and the decision right
Every custom application needs a named owner inside the portfolio company who holds the roadmap decision right, the priority calls between competing requests, and the accountability when the system fails during a busy quarter. Without a named owner, a build defaults to whoever shouts loudest, and the software drifts away from the thesis it was funded to serve.
This is where a lot of operating partners get it wrong: they approve the money and leave the governance to the CTO, then discover twelve months later that the roadmap answers to engineering convenience rather than commercial priority. The owner sits on the business side and negotiates with engineering, not the other way around.
5. Judge the vendor on operating fit, not portfolio logos
A development partner for a portfolio company has to work inside PE constraints: a hold period, a value-creation plan with quarterly checkpoints, and a management team that will still be running the software after the vendor leaves. That is a different job from building a one-off product. Judge the vendor on how they handle handover, documentation, and knowledge transfer, because the point at which they walk away is the point at which the operating risk transfers to the portfolio company.
The same discipline applies here as in choosing a diligence advisor, and the criteria carry over well from this guide on how to choose a technology due diligence advisor. Ask for the exit plan before the kickoff.
6. Tie the build to a real trigger in the deal timeline
Custom development is not evenly urgent across the hold. The triggers that justify moving now are specific: a system migration that cannot wait, an first 100 days integration dependency where two acquired companies run incompatible platforms, or a revenue leak that grows every month it stays unfixed. A build that has no trigger and no deadline is a build that can wait, and waiting is often the correct capital decision.
During confirmatory diligence, the software questions belong inside the broader technical assessment rather than as a separate exercise. That reasoning is covered in the site’s guide to technical due diligence services for the mid-market, and the underlying discipline connects back to formal technology due diligence.
7. Insist on a baseline before you approve the spend
You cannot claim a result without a starting point. If the build is meant to lift conversion, capture the current conversion rate first. If it is meant to shorten quote-to-cash, measure the current cycle in days. The baseline is what turns a launch into evidence at the next board meeting, and it is the single most common thing missing from build proposals that later fail to prove their return.
For revenue-facing builds, the measurement discipline is the same one that governs any conversion program, laid out in this piece on conversion rate optimization for portfolio companies. Agree the metric, the baseline, and the review date before the money moves.
8. Watch for the integration dependencies a build creates
Custom software rarely lives alone. It reads from the CRM, writes to the finance system, and depends on data that lives in a third place. Each connection is an integration dependency that has to keep working through platform upgrades, add-on acquisitions, and eventual carve-outs. A build that assumes today’s systems will never change is a liability at exit, when a buyer’s diligence team will price the fragility into the offer.
Where the portfolio includes carve-outs or planned separations, the build has to account for that from the start. The considerations are set out in this guide to carve-out consulting. Software written against systems that are about to be separated becomes rework at the worst possible time.
9. Price the risk of building nothing
The decision is not always build or do not build. Sometimes the honest comparison is a custom build against a manual process that is quietly costing money in headcount, errors, or lost revenue. That comparison deserves the same rigor as the build case. PitchBook and S&P Global Market Intelligence both publish data on how operational efficiency separates strong holds from weak ones, available at PitchBook and S&P Global Market Intelligence. A manual process that scales badly is a real cost, and a build that removes it can be the higher-return option even at a large upfront number.
10. Set the review cadence at approval
A funded build should have checkpoints written into the value-creation plan, not reviewed only when something breaks. Tie the first review to launch plus a defined measurement window, and require the owner to report actual against the baseline. If the software is not moving the lever it was funded to move, the operating partner needs to know at the first review, not at the exit audit when a buyer asks what the investment returned.
The build decision checklist
- Can someone state the enterprise-value lever this build moves in one sentence?
- Has build, buy, and configure been compared, with configure as the default for standard systems?
- Is the total cost of ownership priced, including the monthly run-rate that hits EBITDA?
- Is there a named owner on the business side with the roadmap decision right?
- Does the vendor have a documented handover and knowledge-transfer plan?
- Is the build tied to a real trigger and a deadline in the hold timeline?
- Is the baseline metric captured before the spend is approved?
- Are the integration dependencies and any planned carve-outs accounted for?
- Are review checkpoints written into the value-creation plan at approval?
Most rejected build proposals fail on the first three items, and most of the ones that ship without a baseline never prove their return. The operating partner who runs every request through this checklist funds fewer projects and defends the ones that survive with numbers rather than narrative.
Where to take the build question next
Custom development inside a private equity hold is an embedded, ongoing commitment rather than a one-off project, and it works best when the team building it also carries the run-rate ownership after launch. If a build is on the value-creation plan and the decisions above are still open, review the embedded engineering and RevOps model at the DevriX private equity practice and bring the checklist to that conversation.
