The most common question on a first call about custom software is some version of "what should this cost?"
It's a fair question, and the honest answer is that nobody knows yet. That isn't evasion. A number given before anyone understands the work is a guess, and guesses in software are usually low.
What buyers really need is a way to spend money on software without losing control of it. That depends less on the rate than on how the work is billed.
Why Custom Software Is Hard to Price
Most buyers have no reference point. One staff member at a small credit union said it directly:
Personally, I've never worked with a website developer, so I truly don't know what costs even begin at.
The ones who do have a reference point often got it from a quote that shocked them. A staff lead at a national trade association described an earlier vendor's answer for a one-way data sync:
They came back and said, okay, well to do this, it would cost $30,000.
Was that number wrong? Maybe not. It may have included things they didn't need, or risk the vendor was pricing in because the scope was vague. The point is that they couldn't tell, and neither can most buyers.
The Three Common Billing Models
Open Hourly
You pay for time as it's spent, with no ceiling.
This is flexible and honest about uncertainty, and it puts all of the risk on you. It works for small, well-understood tasks with a developer you already trust. For anything larger, it's the model we warn clients about most often: it can become a runaway train if you just start throwing the credit card at it.
One Number for the Whole Project
The vendor quotes a single all-in figure for everything, up front.
This feels safe and is often the opposite. To quote a large project in one number, a vendor has to price in every risk they can imagine, which means you pay for problems that never happen. When the scope inevitably shifts, you're in change-order negotiations with the budget already committed. And the number was produced at the moment everyone knew the least.
An Estimate Per Piece, Approved Before Work Starts
The work is broken into pieces small enough to understand. Each piece gets its own estimate. You approve it before anyone starts. When that piece is done, the next one is estimated with everything learned so far.
This is how we work. Our clients get a fixed estimate for each piece, and they approve it before we begin. If the work turns up something the estimate didn't cover, it gets its own estimate, and you decide whether to do it. If the approved work takes longer than we estimated, that's on us. You pay the estimate.
Why Per-Piece Estimates Hold Up
Small Estimates Are Accurate Estimates
A two-week piece of work can be estimated well. A nine-month project cannot, no matter who's doing it. Breaking the work down doesn't just split the budget. It makes each number more reliable.
You Keep the Steering Wheel
Every approval is a decision point. You can stop, pause, reorder or change direction between pieces without walking away from a large commitment. When priorities shift, as they do in every organization, the budget shifts with them.
You Can Fund It the Way Your Budget Works
A staff lead at CASH put the practical version of this well when describing a piece of work they wanted:
I don't need it done immediately but, you know, because I'm trying to stay on a budget.
Pieces can be scheduled against the budget you have. One this quarter, the next after the new fiscal year. That's much harder to arrange around a single large contract.
It Makes "Not Worth It" an Easy Answer
When each piece is priced on its own, the low-value ones become visible. A client can look at a line and say "skip that one," and often should. One apparel founder summed up the goal in a phrase we still use: as little as possible without it being garbage.
How to Build the Budget
Per-piece estimates don't mean you fly without a budget. They mean the budget is built differently.
- Write the scope first. Estimates are only as good as what they're based on. A one-page description of the problem, the users, what done looks like and what's out of scope is enough.
- Order the work by value. Put the piece that removes the most pain first. If the money runs out after piece one, you still want piece one.
- Ask for a rough range for the whole, and a firm estimate for the first piece. The range is for your planning. The estimate is what you approve.
- Hold back a reserve. Something will turn up that nobody planned for, often in how your data really looks. Budgeting a margin for it is realistic, not pessimistic.
- Budget for after launch. Hosting, monitoring, small changes and upkeep are real costs every year. A budget that stops at launch is a budget for starting the project.
- Budget your own time. Someone on your staff will need to explain the process, answer questions and review the result. That time has a cost too, and it's covered in What an Automation Project Actually Costs.
Reading an Estimate
When an estimate lands, check it against these:
- Does it say what's included, and what isn't? An estimate with no stated assumptions can't be held to anything.
- Does it cover feedback? Ours includes one round of feedback. Further rounds are estimated before they're made. Whatever the vendor's rule is, it should be written down.
- Is it broken into parts? A single figure with no breakdown gives you nothing to question or cut.
- What happens if they find something unexpected? The answer you want: they stop, tell you, and estimate it before doing it.
- Who owns the result? The code, data, repository and licenses should be yours when the work is done.
If You Need a Range for the Board
Many buyers need a number for someone above them before any work can start. One executive director asked us for "a high and a low." That is a reasonable request, and the right answer is an honest range for the whole with a clear note that each piece will be estimated and approved before it begins.
If the range is too wide to get approved, that's useful information. It usually means the scope isn't settled enough yet, and paying for a short, focused assessment first will narrow it. Our Operations Audit exists for this: it's $4,500, and the full amount is credited toward the build if you go ahead.
A Simple Rule of Thumb
Never approve more work than you understand.
If you can't explain what a piece of the budget buys, it isn't ready to be approved. Break it down until you can.
Final Thoughts
The rate matters less than most buyers think. What decides whether a custom build stays on budget is whether the money is committed in pieces you understand, each one approved before it starts, with a clear rule for anything unexpected.
If you're trying to budget a custom build and want to understand what's driving the number, we're happy to walk through it with you. See how we approach custom software, or book a short consult.