Software project budget estimate.

Software project cost = developer time + contingency + infrastructure. Most estimates underprice the contingency. A well-planned project still overruns 20-40% on time and budget because of scope creep, integration surprises, and dependencies that reveal themselves during development. The 20% contingency here is a floor; anything estimated without one will overrun by more.

3 developers at 80/hour for 320 hours each = 76,800 labour. Plus 20% contingency (15,360) and 3,000 infrastructure (servers, tools, licences) = 95,160 total. That's a reasonable estimate for a 2-month feature build with a small team. For larger projects, increase contingency to 30-40% - complexity scales non-linearly.

For agency bids, add another 25-40% margin on top of this to cover overhead and profit. A 95k internal project typically quotes at 120k-140k from an agency. Freelancers without overhead can charge closer to cost plus 10-20% margin and still be viable.

Run it with sensible defaults

Using number of developers of 3, avg hourly rate of 80, hours per developer of 320, contingency of 20%, the calculation works out to 95,160.00. Nudge the inputs toward your own situation and the output recalculates instantly. The defaults are meant as a starting point, not a recommendation.

The levers in this calculation

The inputs — Number of Developers, Avg Hourly Rate, Hours per Developer, Contingency %, and Infrastructure Cost — do not pull with equal force. Frequency and unit price pull the total in different directions. The biggest surprise for most people is how small recurring amounts compound into large annual figures — that's where this calculation earns its keep.

How the math works

Labour = devs × rate × hours. Contingency = labour × %. Total = labour + contingency + infrastructure. The working is transparent — you can verify every step yourself in the formula section below. No black box, no opaque "proprietary model".

What to do with a low result

A disappointing result is information, not a judgement. Pick the single input that dragged the figure down most and focus the next quarter on that one factor. Breadth-first improvement rarely works; depth-first on the worst input usually does.

What this doesn't capture

The score is a composite of the inputs you provide. Life context — job security, family obligations, health, housing — doesn't appear in the math but shapes the real picture. Use the number as a prompt, not a verdict.