All custom software development projects have one thing in common; something unexpected happens. We use libraries and tools that reduce risk and make a project more predictable. But this is not a paint by numbers business. No one has ever built this specific piece of software before.

Which is why estimating the cost of a custom software project is so difficult. It’s an exercise in trying to predict the future. We often get the question “How much will this cost?” The better question is “How much should we budget to collaborate on solving this problem?”

Unlike off the shelf products, we are not configuring a set of tools that already exist. Said another way, it’s not like shopping from a menu. The reality is that while we use data to inform the budget, the main input is intuition.

We say creating a budget is more of an art than a science. But we have been shaping project budgets for the past 8 years. And while we will never be 100% accurate, we have a good idea of how a project might play out.

This process of setting a budget comes to life for us via four models. None of them are better than the other, it’s only a matter of which one makes sense for a given situation. And we always use more than one model to triangulate on a budget for a given project.

This post aims to create some transparency around a mysterious part of our industry. And give insight into exactly how we create budgets for a given project.

Rough-order-of-magnitude (ROM)

A ROM budget buckets a project into a range based on gut feel. For us, the ROM buckets are $50-75k, $125-150k, $250-400k, $500k-$1mm. Many times after a first call a client wants to know “What something like this might cost?” We would communicate a ROM budget at that point. And caveat that we should head into our Blueprinting process to understand more.

Another way of ROM budgeting is to consider the team size and calendar time required for the project. The result of that consideration is a “full time equivalent” (FTE) count and sprint count. Then, based on that number of hours and our hourly rate, we can communicate a ROM budget.

Comparable Analysis

At the time of writing this, we have shipped over 300 projects. Those projects range from marketing sites, to web applications, to IOT projects. With that experience comes a wealth of data. Our team uses Harvest to track hourly time entries on every project. This means we can always go back and see how much time we spent on a given project or problem.

When we encounter a new client project we will often look to that data. We ask “This kind of feels like Project X, how long did Project X take?” From there we ask, “Does this new project feel more or less complicated than Project X?”

This allows us to create a comparable analysis, not off of a previous budget, but from an actual cost. This works well when there are technology or feature similarities across projects.

Bottom-up Budgeting

This is by far the most time consuming approach, but it is necessary on every project we do. It is the best model at driving alignment with our clients and setting up our project teams for success. Our Blueprinting engagement produces two key deliverables; a Story Map and an Assumption Inventory. These are the backbone for creating a Bottom-up Budget.

Transparent assumptions inform how we estimate at the User Story level. Having them is critical in aligning on a healthy budget. Assumptions may include requirements around accessibility internationalization, or performance. These do not show up as individual User Stories. But they do impact the work required and QA time for each story.

Armed with these assumptions, we tackle a spreadsheet that has a list of User Stories. We assign a developer day estimate to each story. We use days as the unit since most of our projects are in the 3-6 month range and this unit works well for us. Summed up, we now have an estimate of the developer effort to complete the project.

But having worked on custom software projects for 8 years, we know where risk might pop up. As a result, we add buffers either across the whole project or across an individual Epic.

For example, we are more likely to misunderstand the scope of a project if we skip our Blueprint process . In that case, we add a buffer across the whole project. If we need to integrate with a specific 3rd party tool for authentication that we have never used before, that would introduce risk. We would add a risk adjustment to the Authentication epic in that case. The size and application of these risk adjustments are all based on feel and intuition.

With a range of developer days, we can now add time for Design and Product Management. Design and Product Management work tends to be more front-loaded in a project. But our designers and product managers are active throughout. For example, our PMs help with QA and our Designers program in HTML, CSS, and some JS.

As a result, we add a smoothed FTE count of Design and Product Management across the whole project. This smoothed FTE count is an over-simplification. But it works for us and keeps our process focused on the right things.

We base the FTE counts for Design, Product Management and Development on intuition. And our availability. If there is a hard deadline the client needs to hit, then we can design a Developer FTE count to hit that timeline. More people should equal a shorter timeline. But that is a limiting strategy. You can not infinitely add people because you can not parallelize all work. Also, we prefer small teams. We try to keep the FTE count between 1-3 Developers on any project.

Budget Anchoring

A Budget Anchoring approach means that a client has come to us with a budget in mind already. This is either because they have approval for this amount. Or they are raising capital to fund this project. If we don’t think it’s possible to deliver the desired outcome of the project given the proposed budget, we decline. Not every project is for us.

But if a ROM budget seems in line with what the client’s approved budget, then we do a Bottom-up analysis. Next, we take a scope axe to that analysis, and shape the project into the anchored budget. This process takes really good Product Management.

The challenge in this case is trying to visualize the order of operations of a project. And then deciding what to cut. Here are our considerations in this process:

This is also a great opportunity for us and the client to align on how the other makes tradeoffs. Constructive conversations around how to cut scope is healthy. They tend to be a leading indicator of a successful relationship.

Why We Approach Budgets This Way and What to Expect

Our approaches to business and process are grounded in Our Constants. The way we budget is no different, and two Constants inform this process. First, Own the Outcome. We need to align on a healthy budget that will allow us to deliver quality software. Software that will deliver the outcomes you want in your business. A budget constraint can be helpful for making tradeoffs. But if it is too tight, we may not be able to solve your business problem. We can only take ownership over an outcome if we have enough budget to do so.

The second Constant is Be Authentic. We may do things different than other agencies. And those differences may show up in our budgeting process. Here are some topics related to budgeting and how we handle them.

We hope this information pulls back the curtain on what can be a mysterious part of our industry. If you want us to help your business grow with custom software, the best place to start is by contacting us here.

Paul Gonzalez

Director of Product

Paul has always been a builder of things. K’nex were his tool of choice as a kid, but as an adult he has turned his focus to software. Prior to joining LaunchPad Lab, he spent six years in investment banking where he learned a valuable lesson he still uses today- run towards problems. Paul has also yet to find a beer he won’t try, a competitive reality TV show he won’t watch, or a fairway he won’t miss.

Ready to Build Something Great?

Partner with us to develop technology to grow your business.

Sign up for our newsletter.