Open to senior rolesBook a call

Feature cost & delivery risk estimator

"It's a two-week build" is usually true and almost always wrong. Add the stages that surround the build - and the risk that inflates them - and see what the feature really costs.

The build

The estimate you'd give if someone asked "how long to build it?"
Fully-loaded cost per person-day.

The stages nobody estimates

15%
15%
10%
20%
15%
The risk factors below are added on top of this.
10%
20%

Risk factors

True first-year cost

-

    Build only-
    Everything around the build-
    Effective cost per engineering day-
    Multiplier on the naive estimate-

    Defaults are conservative mid-range figures for a product team with QA and a review process. Replace them with your own once you've measured a few features end to end.

    Why features cost double what you estimated

    Engineers estimate the part they can see: the build. Everyone then treats that number as the cost of the feature, and the difference gets absorbed silently - in slipped dates, in a QA queue, in the support load nobody attributed to anything.

    Discovery is cheaper than rework. The stages before the build look like overhead until you price the alternative. Fifteen percent spent clarifying the requirement routinely prevents forty percent spent rebuilding it after the demo.

    Rework is where risk lands. That's why the risk factors here inflate rework rather than the build. Ambiguous requirements, an external dependency and a compliance sign-off don't make the code slower to write - they make it likelier that the code you wrote was the wrong code.

    Year-one support is part of the decision. Every shipped feature is a permanent liability: bugs, questions, edge cases, the migration when something upstream changes. A feature nobody uses still costs you that. Counting it at decision time is how you avoid a backlog of things you'd never build again.

    Use the multiplier, not the total. The absolute number depends on rates you'll argue about. The multiplier - typically somewhere between 1.8× and 2.5× for a team with real QA and review - is the durable insight, and it's the number to apply next time somebody says "it's a two-week build".

    Want your estimates to hold?All free tools
    Embed this tool on your site

    Free to use. The line under the frame is the only thing I ask for - please keep it.

    <iframe src="https://veljkobarnic.com/tools/feature-cost/embed/"
        width="100%" height="900" style="border:1px solid #e1dad9;border-radius:12px"
        title="Feature cost & delivery risk estimator" loading="lazy"></iframe>
<p style="font:14px system-ui;color:#666">
  Feature cost & delivery risk estimator by
  <a href="https://veljkobarnic.com/tools/feature-cost/">Veljko Barnić</a>
</p>

    Optional - add this if you would rather the frame resize itself to the result:

    <script>
window.addEventListener("message", function (e) {
  if (!e.data || !e.data.vbEmbed) return;
  var f = document.querySelector('iframe[src*="/tools/' + e.data.slug + '/embed/"]');
  if (f) f.style.height = e.data.height + "px";
});
</script>