The most popular question from our clients is…

How much will it cost to build software that does X?

It’s a fair question. I’m writing this post from the lobby of an auto shop where I just had to have that same conversation with my mechanic. He wanted a pretty penny to make some repairs and I wanted to know what the cost was for. He explained how much was for parts and labor and the effort involved. Then I told him to proceed.

So I want to take a minute to give you a look under the hood, to understand the general factors that affect the cost of the software.

Cost Factors

Requirements

The cost of developing a feature depends on how complex you want it to be. This is usually the most intuitive part of the price. A text change should be cheap. Adding a form should be less cheap. Developing “Uber for X” is going to cost a bit more.

Scale

A simple form becomes complex when it needs to handle 1,000,000 concurrent submissions. A footbridge is going to cost a lot less than the Golden Gate bridge.

Out of the Box

A lot of the time your problem isn’t unique to you. Other people have encountered it and someone has usually created a generic solution that you can utilize. As long as you stay within the bounds of the generic solution, then you can get some really quick and cheap wins. Go outside the reservation like the special unicorn that you are, and things get expensive.

Specialization

The term “developer” is about as broad as the term “doctor”. In both fields, there is a large amount of specialization, but for developers, it is probably less organized and we jump horses a good bit. On top of that, technology moves fast. So it is perfectly normal for a well-seasoned developer to regularly encounter new problems and new technologies. Most custom development involves some level of research. Sometimes you benefit from the experience that someone else paid for. Sometimes you are the generous benefactor.

Domain

Most developers will work in multiple domains throughout their career (e.g. Healthcare, Finance, Education, …). Each domain has its own jargon which allows people familiar with it to communicate quickly. If the developer is familiar with the domain, then they can understand the requirements quicker and more completely. They may also already be familiar with common ways to solve problems in that domain.

Context

This is the context that is specific to your custom developed product. When you start, there isn’t any context. As it is built, the context increases. When a new developer comes in on the project, they will be severely disadvantaged until they can gain the solution context. The speed at which they can gain it depends on how well organized and documented the code is. The greatest boost they can have is being able to talk to the original developer.

Technical Debt

Often developers take shortcuts to get things done. These shortcuts are usually motivated by tight deadlines, frequent requirements changes, or just plain laziness. Taking a shortcut is like taking out a loan so you can buy something quicker. You pay interest on it until you pay off the principal. In this case, the principal is taking the time to do it the right way and the interest is the extra time that you have to spend to work around the shortcut. Practically all systems have some level of technical debt. The key is to manage it before you go bankrupt!

Keeping Costs Down

Keeping costs down really comes down to understanding what your costs are and how they align with your goals. Then just be realistic about your expectations relative to their costs.

Know Your Mix

Every project is going to have some mixture of these costs that are specific to it. However, there are some general principles that apply. For instance, simple projects in simple domains get much larger boosts from out-of-the-box solutions as they are better positioned to stay within the bounds of the generic solution. Also, with greenfield projects, you can ignore the cost of Context and Technical Debt. In contrast, it isn’t abnormal for Context and Technical Debt to constitute 60-80% of the total cost in legacy systems. This can be very, very significant depending on your goals for the project. Knowing your mix can help you make cost-saving decisions.

Know Your Goals

I have an old beater car I use for commuting. It isn’t glorious but it gets the job done. I don’t know that I would trust it on a cross-country adventure, but I’m not planning to take one either. Know the goals for your software. Your developer might tell you that the software is trash but if you don’t plan to grow it then it might be cheaper to drive it into the dirt. However, if you want to scale to the masses and go cross-platform, then you need to evaluate your short-term vs long-term costs based on you’re mix.

Realize You Aren’t Special

The whole of your product may be unique but its parts probably aren’t. Developers figured out a long time ago that they were solving the same problem from job to job and they decided to make money off of that fact. So spend some resources on that buy-vs-build evaluation and once you buy (or get for free), try to stay on the reservation as long as possible. Leave financing expeditions into the great unknown to companies that are already rolling in dough.

Redefine Your Unicorn

The only cost that people want to pay for is Requirments, but that is unrealistic. If you are able to find that white unicorn with experience in your domain with all of your technology who has experience solving all of your problems, then you either won the lottery or are too late to market!

What you should really be looking for is a competent developer. Someone who knows when to buy vs build, who is a quick learner, builds maintainable solutions, and helps you solve the root issues. If you have a legacy system then finding a technology match (at least partial or equivalent) is beneficial. How to find them is a whole nother matter.

How We Can Help

To help clients and ourselves understand a project before committing to it, we offer a Discovery service. Discovery is a small project (usually 20-40hr) where we dig through the code and documentation and interview the stakeholders and users. Through this, we gain an understanding of the domain, technical risks, business requirements, and the quality of any existing solution. The output is a proposed architecture or architectural improvements and a roadmap that delivers the highest value items first.

If you are interested in learning your mix, then shoot us a message. We look forward to learning about your idea and how we can serve you!