Budgeting for Software Development
…while you’re still discovering what you need
A software program can range from a few lines of code to a few million, but if you’re thinking about hiring a software team you are probably wondering how much it will cost.
Even if your business is well established, there’s a good chance you have a budgetary constraint, so you keep this in mind:
- You don’t need everything you think you do.
- Software is never really “finished”.
Understanding this is important to a software owner’s success as well as building a healthy relationship with the development team.
Yet, the industry is consistently flooded with requests for highly specific, all-inclusive estimates based on complex and vaguely described requirements. Full-service agencies accustomed to building successful, market-ready products either have a list of RFP red-flags or a policy of simply not bidding on them at all. Hopeful software owners are left reviewing proposals that lack accountability and clarity, often as a result of their RFP terms. With this model, no one really wins.
Asking for a software development quote is a great opportunity to set yourself up for success.
Many potential software owners make the mistake of expecting a quote to include everything that they will need, all the way through to product launch. Software developers faced with this challenge often attempt to come up with a total project cost based on the vague requirements and an assumption that the client will be on the same page about what constitutes a “change request”.
This is an easy place for expectations to get off-track right out of the gate, especially if no one is thinking about the product design process. Writing code is only one small piece of the process.
Though evaluating a software build-out is often an essential step for founders trying to raise funds through investors or grants, expecting the software team to be able to anticipate the inevitable discoveries made in the process is setting the project up for failure.
So, what’s the best way to plan your project’s budget?
The team at Mindbox uses a couple different methods to help answer the big three-prong question (scope, timeline, cost).
1. Define a Small Project in Detail
If the amount of work being estimated is small enough (less than $20k or so), then the software team can usually estimate the project cost with some level of accuracy. This could be the Minimum Viable Product or an iteration towards that goal.
The key to this approach is defining a reasonably sized project, ideally one that can be completed in about 4–6 weeks. Once the project scope is well-defined, the development team can begin to answer the question of how much will it cost and how long will it take. Every software project plan should include some contingency time, but larger plans tend to include too much uncertainty for the estimate to be meaningful or accurate.
With go-to-market product build-outs, especially of the investment and grant-funded variety, it is nearly impossible to define larger and less predictable, requiring a phased-out approach.
2. Define a Plan in Iterations
In order to efficiently build a software product while keeping risks under control, stakeholders should provide feedback often. One of the most effective ways to budget for this type of software development is by establishing a development velocity (ex. development effort per week) which can be increased or decreased as priorities change.
The software team should help determine an appropriate velocity based on the desired amount of work to be completed in each iteration as well as the overall budget.
Once a reasonable velocity and initial milestones have been established, the software team can begin to map out what can be accomplished within those parameters.
Either scope, budget, or timeline will have to change as new discoveries are made, but the cost of each discovery will be lower the sooner we make it.
Ultimately this is the more cost-effective of the two models when executed properly, but it requires trust and maturity on the side of the software owner. As new priorities are identified, smart software owners re-prioritize the scope of work, accepting that discoveries mean either cutting lower priorities or adding to the overall cost of development.Breaking scope of work down into small but complete pieces allows the team to avoid over-planning for features that may get cut or changed, using a just-in-time approach.
The success of this model relies on mature and experienced product leadership in order to maintain clear priorities with the development team and communication with stakeholders ongoing.
When is it “Done”?
Everyone on the team has a slightly different perspective on when software is ready to go live, after which the software will probably need to be maintained as long as it’s in use. Since active software is rarely considered to be “done” or “perfect”, it may be more helpful to think in terms of milestones.
If you’re looking for a lower-impact path to solving your software problems, it may be better to look for open-source or extendable software, or find a subscription-based software-as-a-service platform online with an API to build on.
Pick your approach.
For a realistic estimate on a software product development initiative, start by asking the right questions.
- Either define exactly what you want to accomplish by breaking work into bite sized, estimate-able projects, then ask how long and how much it will cost.
- Or else determine how much you can afford to spend and when you need work to be completed, then allow your software team to help work out what can be accomplished based on your priorities.
In either case, expect to pivot when discoveries are made. Approaching the engagement this way allows seasoned product development teams to create informed bids, and software owners to make better decisions.
Ultimately, this leads to healthier professional relationships and more success for new software owners.
Get in touch if you’d like to talk about a software project, and follow us on Facebook, Twitter, Instagram, or LinkedIn.
This post was originally published in the Mindbox Journal.
Lauren Jerome is the co-founder of an innovative software studio, as well as a community organization working to make tech careers more accessible to a broader audience. She lives in Eugene, Oregon and works from anywhere with a decent signal. Follow her on Twitter and explore more of her work on Medium.
