When someone reaches out to us about building software, the first question is almost always the same: how much will this cost? It has been the first question since 2005, and it is a fair one. Custom software is a real investment, and the moment you are least able to estimate it is the moment you most want a number.
The version of this article we published years ago said we had a process for getting to a sound budget. We still do. It has gotten simpler, and it now starts with you instead of with us.
Start with the value, not the price
Custom software is an asset. Like any asset, it has to do one of two things for the business: make money or save money. Usually both. Before anyone talks about cost, get clear on which it is and roughly how much.
Some examples of what that looks like in practice:
- A quoting tool that cuts turnaround from three days to one and wins more bids
- A scheduling system that lets dispatch handle 30% more jobs without another hire
- A customer portal that takes two people off the phones and lets them do something else
- A reporting layer that closes the books in a day instead of a week
Put a number on the value, even a rough one. If the software saves two people half their day, that is a payroll figure you already know. If it lifts close rates, you know your average deal size. The number does not need to be precise. It needs to exist, because it sets the ceiling. We only take on work where the value should clearly beat the fee, and you should hold every vendor to that test.
Decide what you are willing to invest
This is the step most people skip, and it is the one that matters most. Before you ask anyone for an estimate, decide what the business is willing to put into this. Not what you hope it costs. What you can spend and still sleep.
That number is your budget. Everything after this is about fitting the right scope inside it.
Owners sometimes hesitate to share the number, worried that a vendor will simply spend all of it. That is a real risk with the wrong vendor. With the right one, the number is the most useful thing you can hand over, because it lets them tell you honestly whether a strong first release fits inside it. If it does not, you want to hear that before you spend a dollar, not after.
Get a ballpark by type of project
Once you have a value and a budget, you need a sanity check. Different kinds of projects land in very different ranges. A narrow internal tool with one integration is a fraction of a customer-facing platform. A modernization of a system that already runs the business is different again. The typical budgets by type of project are on our pricing page, along with why the ranges are as wide as they are.
The drivers are mostly the same across projects. Integrations. How many different kinds of users the software serves. Data quality, which is where cost usually hides. Compliance requirements. How fast you need it. And how much has already been decided, because a validated plan shrinks the range more than anything else.
If your budget and the ballpark for your kind of project are in the same neighborhood, keep going. If they are far apart, that is useful too. Either the scope needs to shrink or the project is not viable yet, and both are better to learn now.
Tighten the number before you commit
A ballpark is not a budget you can plan around. The way to tighten it is a short, fixed-fee planning step that produces a real scope and a real cost.
For something new, that is a VDP Sprint: three to four weeks of validation, design, and planning. You leave with the key screens designed, the requirements for a first release, a technical plan, and an investment estimate you can hold us to. For a system you already have, it is a System Evaluation: one to four weeks looking at the code, architecture, and infrastructure, ending in a written plan with the cost to fix, extend, or replace it.
Occasionally the number that comes out of this step is higher than the ballpark. Do not let that scare you off. It means the plan found something the ballpark missed, and finding it for a small fixed fee is far cheaper than finding it in month four of a build. Either way, you own everything the planning step produces and can take it anywhere.
How the budget holds during the build
This is where most projects go wrong, and it is mostly a contracting problem. Our default is a fixed budget with controlled scope. Budget and quality are fixed. Scope flexes. When we learn something mid-project, and we always do, the scope adjusts to fit the budget rather than the budget stretching to fit the scope.
In practice that means:
- We agree first on what a strong first release looks like and confirm the budget can carry it.
- Every week we look at the remaining budget and the remaining work and ask how to get the most value out of what is left.
- You see the list and make the trade-offs. Nothing gets cut or deferred without you knowing.
There are two other ways to buy software work. Fixed price with fixed scope works only when the scope is truly nailed down, and we do quote it in that case. Time and materials with a monthly cap fits ongoing or advisory work where scope is still forming. We recommend one of the three after the Deep Dive. You should never have to pick from a menu before anyone understands your project.
Budget for what comes after launch
Most of the lifetime cost of software comes after launch. Budget for it from the start. That means maintenance and support, which we price as reserved hours billed monthly with response times set by priority, and hosting, which is cloud costs at pass-through plus a fixed monthly management fee. Details are on the Managed Hosting & Support page. If you plan to keep improving the system, and most clients do once it is live, plan for that too.
What to look for in a team
Whoever you work with, look for a team that:
- Has a clear process for refining your budget along the way as requirements get more focused.
- Cares about the return, not just the build, and will tell you when the value does not beat the fee.
- Actively looks for scope to cut so the first release ships sooner and starts earning.
Those three habits are the difference between a budget and a wish.
The first step
Write down the value, write down the number you are willing to invest, and check both against the typical budgets by type of project. Then book a 30-minute intro call. We will tell you whether a VDP Sprint or a System Evaluation is the right next step, or whether the honest answer is to wait.