From a client’s perspective it may be confusing to pick up an independent developer. That’s because prices for what seems to be similar work may be drastically different. For instance, it’s not uncommon for web development work to be priced in $20-200/hr range. How so? Why is there a big pay discrepancy between different software engineers?
For the sake of this article we’ll consider just cases when the client is a business representative. That usually means small business without in-house technical expertise. So a typical case would be an owner looking for a contractor to do some software development. We explicitly exclude cases of in-house software development teams/departments here – for simplicity.
Back to the original question: why there are so different prices? Let’s get back to the range we made up and use its ends as two devs. Let’s also imagine that both guys did exact same amount work on the surface. And that they spent exact same amount of time, for instance, 40 hours to do it. With that we end up with $800 and $8000 for the same result – tenfold difference! While it’s a very far-fetched case there are still interesting things in it. These are just beyond the surface easily visible purely from the client’s perspective.
Below the tip of the iceberg
In short: the price paid for software development isn’t the only cost the owner accepts for the piece of software created. I covered this in detail in this article. It’s available only in Russian now but I may consider doing a translation.
In a nutshell total cost of ownership (TCO) of a software system factor in the following:
- Capital expenses (CAPEX) – that’s what was paid to the software developer.
- Operational expenses (OPEX) – a non-technical client is likely to establish a monthly retainer with the original developer to handle this.
- Need for maintenance – that applies no matter how well the software system was designed. It also applies in case of the most cool quality assurance.
- Limited lifespan – there will be a point in time when any software system implementation will become obsolete.
Let’s cover these factors in a more detail.
Why OPEX matters?
The most obvious OPEX is the electricity bill for the electricity consumed by the hardware running a software system. If you run the system in the cloud then that is factored into the bill from the cloud computing provider. And there are many more items similar to this one – recurring license fees, domain registration/renewal fees etc.
A non-technical client don’t know and don’t care what it takes to run a software system. In such case the developer likely will end up suggesting a monthly retainer to take care of that. That’s not something bad per se but it may impede actual ownership of the system.
How this affects the price: a cheap developer may factor in own margin on top of OPEX costs. That leads to getting most money in form of a retainer. Even worse the system created may be held hostage in a vendor lock-in scenario. To achieve that it’s enough to not share access to key services involved. Trustworthy developer will always share access to key services used to guarantee such thing just can’t happen.
Why maintenance matters?
Maintenance is usually perceived as bug fixing. Let’s consider a totally unrealistic case of a totally bug-free system. Or perhaps with only minor inconvenience bugs with a clear well-defined workarounds. And system design is great enough to sustain any possible workload.
Even with that there are following maintenance-related concerns:
- A problem domain which software system is a solution for inevitably evolves. Reality doesn’t stand still, legislation gets updated, business requirements change – so on and so forth. For the system to keep being effective as a solution to a problem domain it should change to catch up.
- Software system dependencies – libraries, frameworks, infrastructure – get outdated. At some point that will surely lead to defects in the system which won’t be fixable. The reason will be because the root cause of a problem will belong to a dependency rather than the system itself.
- Software system dependencies security vulnerabilities surface and security fixes are issued. Ignoring these leads to the expansion of the attack surface. That makes the system a compelling target not only for lackluster hackers but even for script kiddies.
How this affects the price: the system must be really well designed and flexible for future changes. Achieving this requires much more effort that just delivering the scope. And the complexity of the topic requires own series of articles. For now just take my word for it =)
Why lifespan matters?
This is counterintuitive for a non-technical client. Software seems to be evergreen unlikely to other technical assets. In fact software itself may be evergreen as a solution for a problem domain. However, for any particular software implementation the lifespan limit still applies.
Why? In a nutshell because at some point foundational technology at the very core of the software system will become obsolete. You don’t want to keep track of your todo lists via a mainframe & pushcards, do you? Neither there are many specialists in pushcards these days.
How this affects the price: taking “safe bets” for foundational technologies requires expertise & experience. People with expertise & experience prefer to be paid well. Making software source code more portable & reusable across platforms requires additional effort.
Don’t get fooled by a pay discrepancy
Great software developers bill much more because they think about overall TCO rather than just CAPEX they get. It’s beneficial for a client to:
- be aware of the TCO structure and its influence
- consider own requirements in that regard and possible problems
- vet contractors by asking them how they are going to address TCO-related problems
Happy building!