If you’ve worked with other custom software companies, you’ll notice that Atomic’s approach to budgeting is unique. It’s a lot more time-intensive and comprehensive.
In fact, when I deliver a budget model to a customer who is comparison shopping, they often tell me something like, “This is the most comprehensive analysis I have seen from a vendor.”
So why do we invest our time creating an extensive budget model? A few reasons:
Our goal is to give you enough capital to succeed so we can deliver on our brand promises:
Because of this, we’re not usually the lowest estimate. But we’ve done enough homework to make sure the project budget is realistic for achieving your goals. (We’re rarely wrong on this, and if we are, we make it right.)
Great software is never done. If your software project is successful (and we’ll do everything in our power to make it a success), you will likely need to invest in it year-over-year to continue growing your business.
In light of this, Atomic isn’t incentivized to be the highest bid or the lowest bid. We’re incentivized to be the right bid.
Here’s another secret: Atomic’s salespeople don’t work on commission, and we’re the same people who are responsible for project success and keeping Atomic’s teams highly utilized.
This means that if we set a project’s budget too low, we deal with the pain of this mistake in the form of a disgruntled team and an unhappy customer. If we set a project’s budget too high, there’s also nothing in it for us—we lose the sale, and we didn’t stand to gain anything in the first place by inflating the budget.
Stated simply, we’re incentivized to make the budget as accurate as possible.
We’ve developed a few different methods for budgeting. We like to look at the same project through a few different lenses in order to come up with the right budget.
For each project, some approaches are more relevant or effective than others, so we use the tools that make the most sense for the project we’re analyzing. However, we like to apply at least two methods to each project, as a gut check.
All of Atomic’s salespeople are experienced makers with 10+ years of career experience in creating custom software. This means that we’ve seen a lot of projects, and we have developed pretty good instincts about what a given piece of software might take to build.
For this budgeting method, we simply decide on an idealized team structure—how many team members it would take, and how many hours a week from each member of that team. Then we multiply it by our gut instinct on how many months it would take the team to complete the work. It’s crude, but often it’s pretty close to the mark.
If you’ve ever had a home appraised, this method will sound familiar. Atomic has built hundreds of custom software projects since we opened for business in 2001. We rigorously track data (hours) related to the effort it took to build each project.
For this budgeting method, we plumb the depths of our database for a similar project (or more than one) and pull the data on what it took to build. Then we make adjustments for characteristics that make a prospective project either more or less complex than the comparable project. In the end, we come out with a budget number for what a prospective project could cost, based on actual data from a previous project.
This method is the most in-depth one we use. It’s an important exercise to make sure we’ve thought deeply about a prospective client’s needs. We’ve also found that it’s typically no more or no less accurate than any of our other methods!
This method involves listing out every prospective feature for a piece of software, and then estimating it in developer days (because developers are always the constraint on a software project). We apply a special buffer formula, convert that to weeks, add in hours for design, delivery, and test support, and come out with a dollar amount.
This method is dangerous because it’s performed at (almost) the point of maximum ignorance, and it can indicate a false level of precision. One of the core tenets of Agile software development is the flexibility to pivot when it becomes clear that user requirements differ from the initial plan. I’ve never seen a project that exactly matched its original bottom-up budget model. There are always features that we discover we absolutely need, and things that we discover aren’t relevant. The bottom-up budget model is not a promise or a guaranteed estimate, and it’s important to recognize this early in the process. But when understood and wielded correctly, it’s a good gut check.
Sometimes, our customers want to buy a team for a set period of time (maybe to add to an existing development team to work faster through an existing backlog of work). In this case, we identify the team structure including roles and hours/week from each role. We multiply that by an hourly rate and calendar time, and we’re able to come up with a total cost for the engagement.
There are times when a client really wants to work with us, but they only have a certain amount of budget to spend. This can happen for customers whose projects have moved from a capital to an operational expenditure, where we work with them year-over-year to enhance software that was previously built.
It can also happen for new customers with a very constrained budget (for example, $150,000 is generally an absolute, bare-bones, minimum amount for a working, production, B2B or B2C web app) who really want to work with us and are willing to make some initial compromises in order to get a project up and running. In this case, we use the budget as a constraint and do additional homework to validate (for example, a bottom-up analysis). As long as there’s not a completely unfeasible gap between goals and reality, we work carefully and creatively with the customer to structure the engagement deliverable targets and the team’s priorities so that we can meet the client’s goals.
At Atomic, we view budgeting as an art and a science. We do our best to work cleverly and collaboratively with our customers to correctly capitalize on each project. We’re not out to lowball you, and we’re not out to get the biggest budget possible. In fact, we embrace reasonable constraints because they drive innovation. We’re all about our clients’ success, and that starts even before a contract is signed.
We’ll send our latest tips, learnings, and case studies from the Atomic braintrust on a monthly basis.
