Do you need custom software?
Software has already been built for the most common business tasks – accounting, HR, document management, etc. If you need software like this, don't build custom software. Do some research and buy an existing product instead. It may not match all your needs, or you may have to pay for functionality you don't need, but it will be much cheaper than custom software and can be used right away.
Commodity software is software that doesn't give your business a competitive advantage. For example, everyone has accounting and payroll software. You may save a little money or run payroll a little faster with one software package over another, but if you are not in business for your accounting skills or payroll turnaround time, it's a minor advantage. Your customers don't come to you for that.
Custom software makes sense in cases where commodity software won't do. If it's a new or unique business problem or product, or the software on the market today doesn't match your business needs, custom software is a good option.
How we estimate custom software costs
Most people want to know what something is going to cost before they buy it. I'm no different. When we finished our basement, we had an estimate for the total cost and the builder stuck to the original estimate plus the cost of some change orders. The pricing is upfront and transparent.
But the builder had finished 100+ basements that were like mine. He knows from experience and repeating the same construction tasks what's involved and the labor and material costs.
Custom software pricing is different. We've never built the same kind of software for two different companies. The whole point of custom software is that it is one-of-a-kind and tailored to the specific needs of that business. There will be overlap in some pieces of the software (e.g., everyone has a login screen), but the core applications are always very different.
When someone asks me what it will cost to build their app, we break down each module and give a minimum and maximum range of time we think that module will take for one developer to build. Then we add that up and estimate how many developers and testers we'll need for the software team to build, test, and deploy all these modules. Once we've got a sense of team size (is this one developer for 12 months or two developers for 9 months), we can estimate duration using those minimum and maximum ranges.
Importantly, what takes one developer 6 months does not take two developers 3 months. You can't divide by the number of developers. There is communication and code integration overhead to account for. Having more developers usually means you get the software delivered more quickly, but there is a point of diminishing returns. We've found that most of the time, three to five developers can be as productive as ten.
The pricing estimate is a monthly running cost for a development team, and the duration and total cost are given as ranges based on the minimum and maximum estimates for the modules in the system. We are clear with potential customers the total cost and durations are a big guess constructed by adding up lots of smaller guesses, so the margin of error is very high. But we can commit to the cost of the development team for each month, and we can resize the team and monthly budget up or down as needed.
Avoid fixed bid pricing
We don't provide fixed bid contracts, which require all the project details to be known and documented up front. We've never been on a project where those initial plans didn't change, and they usually change significantly.
Fixed bid contracts put the consulting company in the position of arguing with their customer that the new thing or the change or the different interpretation they have was not in the original specifications and was not included in the price they were given. The remedy is usually a change order contract.
But this model of constant contract negotiating with your customer is not a positive experience for either party, and it adds to the overhead of the project. Both parties need project manages to argue and resolve and write up the resolutions of these disputes.
It's a lot easier and our preference, to say "yes" to customer ideas and changes. We tell the customer the impact of the change, and the customer decides if it's worth the extra time and cost.
Deliver the most important software early
If we don't give fixed price quotes, and we can't be certain of the total cost or duration of your project, only the monthly cost for a development team, how can you be sure you will get the software you need?
We use an agile software development process where the most important features of the system are built first. These are usually the highest value modules in the system. Building the login and forgot password screens can wait. We know we can do that and we know how they will work and what they will look like.
Building the key modules early brings the value and the risk forward in the software project. Maybe you need to demo some key modules to get additional funding from investors. Maybe you need to show off some key modules to your potential customers to verify the would buy this software. Maybe you need to demonstrate progress to key executives to show the project is going well and some of the key goals for this system are already being met.
Because the most important software is delivered earliest, as we near the end of the expected duration and budget, we should ideally be working on the last minor pieces. Front-loading the high value parts of the system ensures the software meets your goals and can be a successful product.