Software is never done—there are always more features and functions you could add. So how much should you budget for a custom software project?
Some companies keep throwing money at the project without any budget at all. But they can miss out on early client feedback and end up wasting money on the wrong things.
Other companies focus on making their budget as small as possible. But they can also miss a lot of opportunities. Spending more than the minimum—in the right places—is how you get a return on your investment.
At Atomic, we like the term “responsible budget”—one that gives you enough capital to create software that starts paying for itself. No matter who you work with, the process below can help you put together a responsible budget for your project.
1. Estimate the Value/Impact of Your Project
How much is this software worth to you? Before setting a software project budget, figure out how much you hope to earn (or save) with the software you’re imagining. Otherwise, it’s impossible to know if the project makes business sense—regardless of what it might cost.
Building a model requires understanding the business and project. If you’d like help with this work, we may be able to assist.
2. Understand Internal Costs & Get a Ballpark Estimate
If you have an internal development team, ask them to estimate how long it would take them (in hours) to build the product. This will give you a useful point of comparison when talking to outside developers.
You should also have a holistic understanding of what the project is going to cost internally, including marketing, ongoing support, executive time, the opportunity cost of internal resources, etc.
Then share your project with the software firms you’re considering. Pay attention to the level of detail in their response. It will tell you a lot about how much transparency you can expect from them going forward.
If you talk to Atomic, we’ll introduce you to our budget/engagement modeling process:
- Using several estimation methods and 17+ years of experience, we’ll consider the project from all angles—identifying risks and unknowns.
- We’ll present you with a budget range that we believe will give you enough capital to succeed. (Our budget model also expresses cost in terms of time, given an ideal team made up of developers, designers, and delivery leads. We encourage you to compare our estimates with your internal team’s estimate.)
- We’ll create an engagement model that will help you evaluate different options and choose a responsible budget for your first release.
You’ll then need to decide if the value of the software falls within our budget range. We are dedicated to our clients’ success, so Atomic won’t work on projects that we believe are undercapitalized. Undercapitalized projects cause a great deal of pain for everyone, and they don’t cost less in the end.
3. Secure Funding for 150% of the Ballpark Estimate
The reality of custom software development is that it’s never “done,” and there are always more ideas than the budget can cover. There’s also a significant risk that the development team will uncover previously unknown complexity, adding cost to the project. To protect yourself, secure funding internally for at least 150% of the ballpark estimate.
It’s much worse to spend too little than it is to spend too much. Allocating funding for 150% of the initial estimate doesn’t mean you have to spend the money, but it does protect you from the disaster of being undercapitalized.
Investors know this idea as “keeping some dry powder”—they anticipate the need for future rounds of funding, and they recognize that the first round may be wasted if there’s no way to get to the second round.
3a. If it’s a Rewrite, Buffer More
We’ve rewritten a number of software products and internal tools over the years and learned that they are uniquely challenging.
Every rewrite starts with a set of core features to be replaced. But there are things about those features that you can’t know until the project is underway. Digging into the old system’s features always uncovers details and corner cases that weren’t apparent at first (much like a fractal). This makes scope very difficult to control.
As a result, consider securing internal funding higher than 150% of the ballpark estimate. And be ready for tough conversations about scope priorities throughout the project.
4. Set a Phase 1 Development Budget
Work with your software developer to set a fixed project budget for Phase 1 of your software. It should be in line with the original ballpark estimate (but below what you’ve funded internally).
A fixed budget will focus you and your team on the hard work of defining and building the smallest possible product that delivers value. You’ll need to make hard choices about scope. The team will need to offer creative alternatives and tradeoffs. And you’ll be forced to build less and release sooner.
This is intentional! Once you release the software, you’ll learn a lot from your users, which will help you plan future phases. And you’ll still have money left over for key updates and bug fixes.
5. Build the Smallest Possible Product that Delivers Value
Now you (and your software team) need to do the creative and challenging work of figuring out how little software you can possibly build that, when deployed, will start delivering value.
Cramming in as many features as you can is a recipe for cost overruns, usability problems, and quality issues. Instead, focus on a smaller set of functions, and use human-centered design principles to create a great user experience.
At Atomic, we do this by:
- Data-gathering with your team and interviewing future software users
- Making and testing several levels of prototypes
- Developing with an Agile approach, and managing your budget through scope control
(This approach assumes that you’re confident enough about the market or the need for your product. If you don’t have this confidence, you should consider using a technique like Steve Blank’s customer development strategy.)
Historical Data on Software Product Cost
I reviewed the cost of all projects Atomic has developed since 2013 to further explore the real-world costs. To clean up the dataset, I removed design-only engagements, maintenance work, and projects that were strictly consulting.
After filtering, 93 software products remained. Developing some of these products involved multiple phases of design and development work. I feel this dataset accurately reflects what it costs to engage a company like Atomic to build a product. For clarity, I sorted data along the x-axis by cost:
- The median cost of a software product in that timeframe was $228,000. That cost represents roughly 1,750 hours of team effort.
- The majority of non-rewrite, consumer-facing product costs fell into the $100,000-$500,000 range.
- 75% of projects cost less than $600,000.
- Rewrites (in red) were significantly more costly, averaging $1,050,000–or about 8,000 hours of team effort.