How to budget a software development project (without the spreadsheet theater)

May 18, 2026

The first software project I quoted as a freelancer was supposed to take three weeks. It took eleven.

The spec was four bullet points, the budget was a number I picked because it sounded reasonable, and the client was patient until they weren't. By week six everyone was unhappy and nobody was being dishonest. I just had no idea how to budget a software development project.

Most online cost calculators don't help. They ask three questions and return a number that depends on nothing. Real budgeting is six variables in a trench coat, and the trench coat is held together by how well-defined your scope actually is.

Here's what I'd tell my past self.

The six variables that actually move the number

Every software development cost estimate is some flavor of hours × rate. The interesting question is where the hour count comes from.

Six things change it:

1. Project scope: the number of distinct features the deliverable must support. Not "a dashboard with reports" but "a dashboard with 6 specific reports, each with 3 filter dimensions and CSV export". The first phrasing is a fantasy. The second is bid-able.

2. Technical complexity: does the code have to handle real-time updates, custom algorithms, regulated data (HIPAA, PCI, GDPR), high concurrency? Each of those adds 30-100% to the matching feature's hour count because of the engineering trade-offs and the verification load.

3. Integration surface: every third-party API the project touches adds roughly 4-12 hours. Stripe is fine. A B2B partner's custom SOAP endpoint with no sandbox is six days of wasted weekends.

4. Team seniority: a senior engineer at $100-150/hr will deliver in a third of the hours of a mid-level at $40-60/hr. The math sometimes makes seniors cheaper per project. The math more often doesn't, because mid-levels are cheaper per hour. Read the actual scope before choosing.

5. Timeline pressure: compressing a project timeline by 50% adds roughly 30-50% to total cost, not because engineers work faster but because the team adds people, communication overhead climbs, and weekends start to be billable. Brooks' Law from 1975 is still true in 2026.

6. Scope volatility: every change request after kickoff costs 2-4x what it would have cost in the original scope. A button added in week 1 is 30 minutes. The same button added in week 4, after the page redesign is "almost done", is 2-3 hours plus regression testing.

A budget that doesn't ask about all six is a budget that's going to surprise someone.

The accuracy ceiling, and why it's lower than people think

Here's the part nobody likes hearing.

A well-scoped estimate for a defined deliverable (one that the studio has built something similar to before) is typically accurate within ±20%. So if I quote 100 hours, the real number is probably 80-120. That's the honest ceiling for honest work.

For a greenfield product, where the spec is "we want a SaaS for X but we're still figuring out what X is", the accuracy collapses to ±40-60%. So if you hear a quote of "$15,000-25,000" for a new product, the real ending number is probably anywhere between $9,000 and $40,000.

I was wrong about this for the first two years. I thought tighter estimates were a sign of better engineering. They were a sign of clients who hadn't started discovering what they actually wanted.

The fix isn't tighter estimates. The fix is one of three things:

Lock the spec earlier with a paid discovery sprint (2-5 days, charged separately) before quoting the build.
Use time-and-materials with a not-to-exceed cap instead of fixed price.
Quote phase 1 as a fixed price and explicitly defer phase 2 estimation until phase 1 ships.

All three are honest. Pretending you can quote a greenfield product within ±10% is not.

What changes when AI agents enter the workflow

This part has been overhyped and underhyped in equal measure.

The naive overhype is "AI writes 90% of the code, projects ship 10x faster, budget collapses". That has not been my experience.

The naive underhype is "AI is just autocomplete with more steps". That isn't true either.

What actually happens, in numbers I can defend from running a studio with this workflow for the past year:

A mid-complexity integration (webhook pipeline, a few UI screens, basic auth, deploy) used to take 18-22 hours of subcontractor time. Senior reviews on top added 2-3 hours. Total: 20-25 hours.

The same scope, with a proper agent workflow, lands closer to 6-8 hours total. Not because agents write better code than the subcontractor did. The reason is the review-fix-verify loop. Agents catch their own obvious mistakes when the feedback cycle is wired correctly. The "first draft is rough, second draft is shipping-quality" cycle collapses from days into hours.

Token cost is real but tiny. A mid-complexity project consumes $12-18 of Claude tokens. The subcontractor equivalent was $400-600 in labor. The ratio looks dramatic but the meaningful gain is calendar time, not cost — most clients care about shipping in 6 days more than they care about a $400 line item.

Bigger projects scale similarly. A SaaS MVP that traditionally takes 4 weeks of senior engineering can land in 3 weeks with agent support. Token cost across that project is around $140. Lines of code: about 14,000 (without counting tests). Bugs caught in client UAT: typically 2-4, of which one is critical and the rest are cosmetic.

What AI agents do NOT do: tell the client they're wrong about a product decision, catch the subtle business-rule violation in a 200-line file, decide what NOT to build. Those are still human work. The studio model is "one senior plus an agent workforce", not "an AI subscription replacing engineers".

A worked example

Let's budget a real project. The ask: a small e-commerce dashboard for a Shopify store owner who wants daily metrics, abandoned cart recovery emails, and a returns workflow.

Phase 1: scope it out.

Daily metrics dashboard (revenue, orders, top products, repeat customer rate): 4 reports, 3 filters each, CSV export
Abandoned cart email automation: Shopify webhook + email service (Postmark) integration
Returns workflow: admin can mark return, send pre-paid label link via Postmark, refund processed via Shopify Admin API

Phase 2: estimate hours per variable.

Without AI agents:

Dashboard frontend (Next.js): ~24 hours (3 hours per report × 4 reports, plus shared filter component and CSV export)
API + Shopify integration: ~16 hours (webhooks + admin API client + error handling)
Email automation: ~12 hours (template, Postmark client, queue + retry logic)
Returns workflow: ~14 hours (UI + state machine + label generation + refund flow)
Auth + deployment + testing: ~14 hours
Total: 80 hours

With agent support, same scope:

Dashboard frontend: ~10 hours (agents handle the boilerplate, senior reviews architecture and UX details)
API + Shopify integration: ~6 hours
Email automation: ~4 hours
Returns workflow: ~6 hours
Auth + deployment + testing: ~6 hours
Total: 32 hours

Phase 3: apply rate.

At a senior rate of $125/hr:

Traditional: 80 hours × $125 = $10,000
Agent-assisted: 32 hours × $125 + $200 in tokens = $4,200

Phase 4: apply uncertainty.

Both numbers are ±20% because the scope is well-defined. So the honest quote is:

Traditional: $8,000-12,000, delivered in 3-4 weeks
Agent-assisted: $3,400-5,000, delivered in 1-2 weeks

A 60% cost reduction. The temptation is to claim this is the typical case. It's not. This works when scope is defined, the integration partners are well-documented (Shopify is excellent here), and the senior knows what to verify. Greenfield products with 20 features and shifting requirements don't compress as cleanly.

How to budget if you're the client, not the studio

Three pragmatic tactics if you're commissioning the work:

1. Ask for the breakdown. A quote that says "$8,000 for a dashboard" is not a quote. A quote that says "24 hours dashboard, 16 hours integration, 12 hours email, 14 hours returns, 14 hours auth+deploy, $125/hr = $10,000, ±20%" is a quote. The breakdown protects both sides.

2. Run the calculator on yourself first. Before you ask a vendor, write the feature list yourself and put a rough hour count next to each one. You don't need to be right. You just need to know what feels wrong when the vendor's number arrives. A 4-feature project quoted at 200 hours probably has scope you didn't communicate. A 12-feature project quoted at 30 hours probably has scope the vendor didn't read.

3. Reserve 20% for unknown unknowns. Whatever number you arrive at, add 20% to the budget you tell stakeholders. Not because vendors are dishonest. Because the spec isn't done until the product ships. You'll either spend the buffer or you won't, and the conversation in week 6 will be much calmer if you did.

The take

Budgeting a software development project well isn't a formula. It's a discipline.

The discipline is: define scope, count features, pick a rate, apply the right multiplier for complexity, and admit upfront how much the spec might still drift. The variables that move the number are knowable. The honesty about your uncertainty is the part that protects you.

If you want to play with the inputs, the calculator at baodev.studio/estimate.html shows the same logic with a UI. It's not a quote. It's a defensible reference for the budget conversation you're about to have with whoever is funding the project.

If you want a real quote, the intake form takes 7 minutes and produces a number within 24 hours. The number comes with the breakdown, which is the only part that matters.