How to Set a Budget for a Software Development Project

Software is never done—there are always more features and functions you could add. So how much should you budget for a custom software development 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.

The Unlimited Budget

The worst possible budget for a project is zero. If you have no funds or no time, you have no power to build anything worthwhile. That’s not a surprise to anyone – no one likes working under absurd constraints.

The second worst possible budget is unlimited.

Reasonable constraints provide guidance. They help you narrow your focus and work on the things that really matter. A well-considered constraint can be a road map for your project: Even if you know where you’re going, the map can help you measure the distance and figure out if you’ll have enough gas in the tank for that side trip you were thinking about.

The design process always creates more ideas than can be built in the available time frame. That’s not a bad thing – an excess of ideas will provide rich fodder for future work. But you must take care not to get lost in myriad possibilities. The risk is this: Even if the project has the funds to build a feature you don’t need, that is time you can never get back. Two weeks spent building something you don’t need means two weeks stolen from a more critical feature, or alternately a release delayed two weeks.

The strategy I have been employing to help keep focus is to make a simple “mission statement” (for lack of a better term) for the next release. The intent is to distill your goal down to the simplest possible terms with a statement following the form: “some person or persona will be able to do something by date.” Here’s an example: “Individuals will be able to order books via our website by March 15th.” By distilling the intent down to its absolute simplest definition, we’ve obtained a statement short enough that everyone can keep it in mind throughout the next phase of development.

This statement is a context – not a commitment. A dozen words is clearly not enough to specify a product – but as you work through your list of ideas a mission statement can help solidify the line between what’s in this release and what’s out until future releases. It’s a very simple tool to help keep everyone on the same page and provide a context for the trade-offs every project needs to make at some point.

“But my project is more complex than that,” you may cry. That might be true, but I’m skeptical. If you can’t cut a release statement to under, say, 50 words, that’s a red flag warning you that you might be building more than you need.

A one sentence release statement may seem like too simple a tool to be useful. If you think so, then please humor me and figure out what yours is. It shouldn’t take more than 5 seconds and if you’re right you’ve lost nothing – and it may just tell you that half your team got different marching orders than the other half.

The Responsible Budget

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:

1. Using several estimation methods and 17+ years of experience, we’ll consider the project from all angles—identifying risks and unknowns.
2. 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.)
3. 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.

‍

Check out our additional client resources on:

1. Estimating software projects
2. Fixed Price Software Development vs T&M vs Scope-Controlled
3. Questions to ask when implementing new software