Price a custom feature with its future maintenance in view

A customer offers to pay for a feature your product does not currently support. The engineering estimate fits the proposed fee, and sales sees an easier renewal. Before accepting, ask what the company will have to keep doing after the customer approves delivery. A feature that takes six weeks to build can create several years of compatibility tests, documentation and support.

Begin with the actual promise. Is the customer buying a one-time deliverable, access to an addition to the standard product, or a privately maintained variation? Those arrangements create different workloads. A price cannot be assessed until the team knows which one it is offering and which future changes it has agreed to accommodate.

The decision model should follow incremental cash costs and scarce staff capacity across that promise. It is separate from the accountant's treatment of development expenditure and revenue. An acceptable commercial price does not establish how the fee or development work belongs in the financial statements.

Have an engineer explain which systems the feature touches. A new report may depend on an existing data export. A private integration may depend on a customer's authentication method, changing file format and test environment. A change to a shared calculation can require regression testing across the main product. The relevant unit is the work the company must continue supporting, not the number of screens delivered.

Separate routine upkeep from defined change requests. Record what happens when the underlying platform changes, a third party retires an interface, or the customer requests a new field. Identify any promised response time and whether supporting it requires backup coverage. A small feature with an urgent response commitment can consume more capacity than a larger feature supported during ordinary hours.

Ask how the work ends. An agreed support term, migration path and retirement procedure make the cost estimate more concrete. An indefinite promise to keep a private variation working is difficult to price because the delivery boundary keeps moving.

Consider an illustrative project with $24,000 of initial engineering and testing cost. The team estimates another $4,000 for documentation, customer training and release work. Annual maintenance is expected to use $6,000 of resources for three years. On an undiscounted basis, the modeled commitment totals $46,000 before selling costs, uncertainty and any contribution requirement.

A $35,000 development fee would exceed the initial $28,000 delivery estimate by $7,000. It would fall $11,000 short of the full three-year resource estimate if the same fee included all maintenance. The apparent project surplus comes from stopping the calculation at launch. These figures illustrate the method; they are not benchmarks for software development prices.

Now compare possible terms. A separate annual maintenance charge could fund continuing work. A smaller feature could reduce the support surface. A shorter commitment could make later work subject to a new agreement. Show the economic effect of each choice alongside its customer consequences, rather than adding an unexplained contingency percentage to the original quote.

Product leaders may expect the feature to become part of the standard offering. That can improve the case, but distinguish evidence from hope. List customers who have requested the capability, the problem it solves for them and what they might actually buy. Do not count the full contract value of those customers as feature revenue if they would purchase the product anyway.

Keep the committed customer's economics visible before adding a broader adoption scenario. A contribution from future customers can justify a deliberate product investment, but management should see that it is making that investment. Otherwise a discounted custom engagement quietly spends the product budget without a separate decision.

Shared development can also cost more initially. General configuration, documentation and testing may be required to make a feature useful beyond one customer's workflow. Include that work explicitly. Calling something reusable does not make the first customer's specification representative of the market.

Even when the direct margin is positive, engineers may be taken away from an already committed release. Ask which work moves and what that delay changes. Use a specific displaced project and credible consequence when estimating opportunity cost. An arbitrary premium for every busy hour can double-count capacity already included in the budget.

Map dependencies before promising a delivery date. Customer data, test access, security review and acceptance feedback can all determine when engineering can finish. Commercial terms should address those dependencies with qualified contract review where needed. Finance should understand which delays extend staff cost and which create a right to revise the schedule or fee.

Give one person ownership of changes after approval. Small requests made through support messages can accumulate into a different project while the original price remains unchanged. A clear change record lets the account team discuss the new work before the cost is absorbed.

Preserve the approved scope, estimate, assumptions and customer commitments with the project record. Compare delivery effort and the first maintenance cycle with the original model. Distinguish a poor estimate from extra work the business deliberately chose to provide. Both matter, but they call for different corrections.

At renewal, review actual incidents, testing effort and planned platform changes. A feature with little ticket volume may still require substantial release testing. Conversely, a well-contained addition may cost less to support than expected. Use the evidence to adjust future offers and to decide whether the feature belongs in the standard product, remains a paid exception or should enter an agreed retirement process.