A feature is worth building only if lifecycle value beats lifecycle cost — including what you did not build instead.
Teams count sprint cost but skip maintenance, support, and opportunity cost. ROI discipline stops roadmap drift.
It belongs in our small business finance growth guide, alongside how to prioritise revenue generating features and why building more features hurts your business. Use the cost per feature calculator when you want to model your own numbers.
Feature ROI
Feature ROI is the ratio of value created by a feature to the cost of building and maintaining it. Value can be measured in several ways depending on the feature type: revenue generated (conversion improvements, upsell triggers), revenue protected (retention improvements, competitive defence), cost reduced (support deflection, automation), or strategic value (market positioning, enterprise requirement). Cost includes development time, ongoing maintenance, and the opportunity cost of the engineering capacity not spent on something else.
A feature that takes three months of engineering time to build and improves trial conversion by 0.5 percentage points needs to be evaluated against what three months of engineering could have produced on alternative priorities. If the conversion improvement adds £8,000/month in net new revenue and the engineering cost was £45,000, the payback period is approximately 5.6 months — a strong return. If the improvement adds £800/month, payback is 56 months — a weak return that was probably not the best use of three months of engineering.
The Cost per Feature Calculator structures this calculation. Enter the development cost (engineering hours × blended hourly cost), estimated maintenance overhead, and the measurable value the feature is expected to generate, and it calculates payback period, annual ROI, and the break-even point. Running this calculation before committing to features — not after — changes the prioritisation decisions significantly.
Cost Breakdown
Accurate feature cost calculation requires including all relevant cost components, not just the initial development time.
Development cost: Engineering hours × blended cost per hour (salary, benefits, overhead). For a product team where the fully loaded engineer cost is £85/hour, a feature requiring 200 hours costs £17,000 in development alone. This is the number most teams use as the feature cost. It is also incomplete.
Design cost: Product design and UX work precedes and accompanies development. A feature requiring two weeks of design time at a fully loaded designer cost of £60/hour adds approximately £4,800 to the total.
Testing and QA: QA is often underestimated in feature cost calculations. Complex features touching multiple system components require disproportionate testing time. A feature taking 200 hours to develop might require 60 to 80 hours of QA.
Ongoing maintenance: Every feature that ships adds to the maintenance burden of the codebase. A conservative estimate is 15 to 20% of initial development cost per year in ongoing maintenance time — bug fixes, compatibility updates, edge case handling, and refactoring as the surrounding code evolves. A feature costing £17,000 to build costs approximately £2,500 to £3,400 per year to maintain indefinitely.
Opportunity cost: The hardest cost to calculate but the most significant. The true cost of a feature is not just its direct cost — it is the alternative value that could have been created with the same team capacity. A three-month feature that produces modest value prevented three months of work on a potentially high-value alternative.
Decision Making
Feature investment decisions are improved by three specific practices:
Score features against a consistent framework before committing: Impact (what measurable outcome does this feature improve?), effort (what does it cost to build and maintain?), and confidence (how certain are we of the impact estimate?). A feature with high estimated impact and low confidence is a hypothesis to test cheaply before committing full build resources. A feature with high impact and high confidence justifies full investment.
Validate impact estimates with data: Most impact estimates are guesses dressed as forecasts. Conversion improvement estimates are wrong more often than they are right. Where possible, validate with small experiments before committing full development capacity — A/B tests on feature concepts, landing page tests for proposed premium features, prototype testing with target users.
Track actual ROI after launch: Features that ship rarely get retrospective evaluation against their original business case. Building a post-launch review into the feature development process — three months after release, compare actual impact against the original estimate — produces calibration data that improves future feature ROI estimates. Teams that do this consistently make progressively better investment decisions.
Worked example: feature ROI payback
Billing export build: £14k dev + £2k/year maintenance. Expected: reduce churn 0.2% on £60k MRR = £120/month saved + £200/month support time → £320/month benefit. Payback £14k / £320 ≈ 44 months — reject.
Alternative: dunning emails, £2k build, £600/month recovered failed payments. Payback ~3 months — accept.
Same quarter capacity; choosing by payback doubled recovered revenue.
They add a simple rule: any feature without a quantified payback estimate does not enter the sprint until product and finance sign off.
Check results in the burn rate calculator and see should you build or buy software for related guidance.
What to do next
- Document build, maintenance, and support cost per feature.
- Estimate monthly revenue protected or gained.
- Compute payback in cost per feature calculator.
- Kill or defer >18-month payback unless strategic.
- Post-launch: compare forecast vs actual at 90 days.
This article is for general planning and education — not professional financial, tax, or legal advice. Figures are illustrative; check current terms and your own numbers before acting.
Frequently asked questions
What if impact is strategic not numeric?
Name the strategic outcome and set a maximum €/£ you will pay for it.
How do we value retention features?
Translate churn reduction to MRR saved using churn impact calculator.
Should small fixes need ROI?
Quick fixes under a day are hygiene; multi-week builds need scoring.
Who owns the business case?
Product proposes, finance sanity-checks assumptions.
Can we aggregate low-usage features?
Sometimes one maintained module beats five orphans.