A shared technical investment can be rejected for the wrong reason: no individual customer contract can carry its full cost.
That does not make the investment worthwhile. It means the project budget may be too narrow a boundary for deciding.
Consider a hypothetical software business onboarding customers whose integrations need the same specialist. Each contract covers its own bespoke delivery. A shared connector would cost more initially, so the business keeps approving customer-specific work.
Every approval can be reasonable on its own. Taken together, those decisions may preserve a dependency that makes later customers expensive to serve.
The question is whether a defined piece of shared work would improve the economics and reliability of serving customers the business can credibly expect, after accounting for what it takes to build, adopt and maintain it.
Compare both choices over the same period
Comparing the connector’s full build cost with one bespoke integration puts the entire investment on one side and only part of the alternative on the other.
Choose a period that reflects the expected useful life of the shared component, then compare the work each approach would require within it. Keep later, less certain demand separate from near-term commitments so a short budget cycle does not decide the outcome by itself.
For bespoke delivery, include customer-specific implementation, testing, support and changes as external systems evolve. For the shared connector, include development, customer-specific configuration, adoption, testing, support and maintenance. Existing customers may need migration; later customers may still require exceptions.
Include the consequence of a slower first delivery. If building the shared component delays a customer commitment, that cost belongs in the decision, even if later deliveries become easier.
Be equally careful with the benefit. Specialist time released is not automatically cash saved or revenue earned. It becomes useful capacity only if the business can assign it to work that matters. Count released hours according to how they will actually be used. Hours used to serve additional customers cannot also be counted as hours removed from staffing costs.
Recurring demand must contain recurring work
Several customers asking for an integration does not establish that they need the same integration.
In this hypothetical business, authentication and connection monitoring might be common, while data mappings and approval rules differ. Sharing the stable parts could be worthwhile without forcing every customer into one connector design.
The technical evidence should show which behavior can be shared, which must remain specific and how changes will be tested. If every new customer requires a change to the common core, the proposed reuse may simply move bespoke work into a component that is harder to change safely.
A maintenance owner matters for the same reason. External systems will change. Someone must decide which versions to support, handle failures and fund updates. A component without that responsibility is an unfinished operating commitment, not a completed efficiency investment.
Demand needs timing and confidence
A promising pipeline is not interchangeable with committed customer work.
The investment case should distinguish contracted demand, qualified opportunities and broader market expectations. It should also show when those customers might need the capability. Work arriving after the planning period cannot justify an assumed near-term benefit.
There is no need to pretend the forecast is certain. Ask whether the investment still makes sense if fewer customers arrive, arrive later or need more exceptions than expected. If it depends on every opportunity closing on schedule, leadership should see that dependency explicitly.
A smaller commitment may be the better answer
Suppose the next integration can validate a common connection layer while leaving customer-specific rules separate. Funding that limited scope may be more defensible than approving a broad connector for unconfirmed future needs.
But if the near-term customers use materially different workflows, or the first delivery cannot absorb the delay, bespoke delivery may remain preferable. Revisit reuse when evidence changes; do not build a platform merely because repeated work is frustrating.
Before approving either path, leaders need a comparable whole-period cost estimate, evidence of the common behavior, a demand forecast with timing and confidence, and named responsibility for adoption and maintenance. They also need to know what would cause the team to narrow or stop the shared investment.
One customer contract should not have to carry the full cost of an investment whose benefits extend across several customers. Equally, future customers should not be used to make an unsupported technical investment look economical. Assess the shared work across the customers it can credibly serve, with its full obligations visible.