Budget a software project by the type of build and the scope, not by a gut number. In 2026, a focused website lands around $1.5K, a multi-page site adds 4 to 8 weeks of work on top, and a SaaS MVP starts at $8K. The number moves with complexity — roles, integrations, and how clearly "done" is defined. Fix the scope first and the budget stops being a guess. Skip that step and you're not budgeting; you're hoping.
What do the ranges actually look like?
Honest 2026 ranges from real builds:
- Focused website or landing: around $1.5K, 2 to 4 weeks.
- Multi-page marketing site: more, usually 4 to 8 weeks.
- SaaS MVP: $8K and up, 6 to 10 weeks.
- Web app or internal tool: typically $10K–$30K depending on roles and integrations.
These are starting points, not quotes — scope decides where you land inside or above each band. A good rule: if you can't yet say what "done" looks like, you're not ready to set a number — scope it first, then price it.
What moves the number most?
Three things, in order: scope (page count or feature count), complexity (custom design, user roles, billing logic, integrations), and unclear acceptance criteria. The first two you can plan for; the third is what quietly doubles budgets when "done" isn't defined up front. Integrations deserve special caution — every external system you connect to (payments, a CRM, a third-party API) adds work you only partly control, because their quirks become your problem. The cheapest line item is always the feature you agree not to build yet. That single discipline — naming what you won't build yet — usually saves more than any negotiation on the hourly rate ever could, because scope drives the price far more than the rate does.
Fixed price or hourly — which protects your budget?
For a defined build, fixed price protects you: you approve a number before work starts, and the risk of a bad estimate sits with me, not you. Hourly fits genuinely open-ended work — discovery, ongoing iteration — where pretending to fix a price just means padding it. The danger with hourly is an open meter with no ceiling; the danger with fixed price is vague scope that turns every change into an "extra." Either is fair with a clear written scope and a cap; neither is without one. I cover the tradeoff in fixed price vs hourly.
How do I quote so it doesn't drift?
I lock a fixed scope before sprint one and quote against it, so the price doesn't move mid-project. If scope changes, that's a deliberate conversation, not a surprise invoice. You also own the code and the deploy — no lock-in, no monthly hostage fees. That fixed-scope approach is the difference between a project that lands on budget and one that creeps: every change is a choice you make with the price in front of you, not a line item you find at the end.
What should you budget beyond the build?
Plan for what comes after launch: a domain (~$10–15 a year), hosting (often modest or even free-tier on a modern stack like Vercel to start), and — most importantly — time or budget to iterate once real usage arrives. The build is the start of the work, not the end. The teams that get the most from a project keep a little runway for the first round of improvements, because the best information about what to build next only shows up after real people use v1. Budget the first iteration, not only the launch. If the site is core to the business, pencil in light ongoing maintenance too — updates, backups, and security — which stays modest on a modern stack but isn't zero.
How do you keep a budget from blowing up?
Three habits: define "done" in writing before anyone codes, put new ideas on a v2 list instead of into the current build, and prefer a fixed scope so changes are deliberate. Most blown budgets aren't from bad estimates — they're from scope that quietly grew because nobody wrote down where it stopped. A clear boundary on day zero is the cheapest insurance in the whole project. If you can name the one outcome v1 must prove, you can hold the line on everything that isn't it — which is exactly what how to scope an MVP walks through.
Related strategy guides
Pair this with what to build first and how to scope an MVP. For lane specifics, see my services.
Want a real number for your project? Tell me the scope — I'll quote a fixed price.
