Why is customized software so expensive?

Actually, I know the answer but I don't know how to market my answer.

Quick background We're an independent team of 3 developers who write software for a company with 2B in revenue. We've been working very closely with this company for the past 5 years. We had a great opportunity to embark on a very niche market as well as enjoy an A+ project (a project with sophisticated algorithm that actually solves a big pain and returns money). In a way, we are very lucky to have them!

The problem Every time we give a proposal we hear the same mantra: "WHAT?! Why is this so expensive?". The first reaction that goes through my brain is this: do you have any idea what's going on behind the scene every time you click a button? It's expensive because we hold a master degree in CS and we need to research, design, test, implement, and redo everything because you will change the requirement. This is not Excel, this is customize for you! And we're not one of your $30K employee that's worked for you for the past 20 years (ok, I'm venting now, sorry).

Back to my subject: can anyone give me a line that a Director/CEO (that's also IT illiterate) can understand why software is so expensive?

if you know what a big pain the problem is and how much money it will save them then include that in the cover letter. You have to sell the proposal and show the value of the project, not the expense.

Stop trying to justify the costs, and focus on the added value. For example what it's going to save, or by how much it will improve business. Then ensure that the delta between that and the cost is sufficient to make it a "no brainer".

"Feature X will enable the company to save 3 million in labour costs, per year", is an easy way to sell a deal that will earn you half a million.

If feature X is going to cost 1 million to save 1 million, you're going to have a much harder time justifying it, unless there's another clear and compelling argument, in which case, use that.

I have a cousin who is quite bright (PhD in Mathematics, etc.) and when I read your posting I thought of something he often says:

"Compared to what?"

It's a great question in certain situations because it causes people to pause, think more deeply and broadly, and have an intelligent conversation. In your situation you would have to be careful not to sound cheeky, but it might help make the point that yes it's expensive compared to cheap lousy software, and it's expensive compared to no software (except that it isn't because with no software you are not accruing any of the savings the software provides), but it's not expensive compared to the savings it provides.

Here are some non-cheeky ways you could ask this question, or ask different but also good questions:

• Hmmm, how so? I'm surprised you feel that way since it saves you so much money.
• Well, I hear your concern, but please clarify why you think it's expensive. Relative to what?
• I'm glad you expressed your concern to me. It's an important topic. Let's talk about it.
• The costs are driven by how easy the software is for people to use. The more complexity that has to be pushed to the back so it's invisible to users, the more time and creativity is needed to make it happen.

The tricky thing about software is that if you've never written it, it seems like magic. Many people view writing software as a talent, a quality you possess. They can't write software, but you can. It's like being tall, or having curly black hair. It's not a skill that has to be developed over years of learning and practice; it's something you're born with.

Unfortunately you can't present your argument in terms of your education, your skills, or really anything about you. It's not about you. It's about the client and what they need. So you need to sell the value of what you're providing.

There is also a lot of confusion about the relationship between the cost and quality of software. Many clients look at something like Basecamp, Dropbox, or Omni Focus and confuse software of that caliber with commodity software development, not realizing how much more expensive it is to develop high-quality software. The difference in quality and ROI is huge, but many business folks can't help but think they can get high quality on the cheap.

Because my father was a building contractor and I grew up on job sites, I often use the home-building analogy. It frequently (but not always) helps people understand. It goes like this:

QUALITY When you think about the construction of a home, there are essentially two components: Expertise and materials. Good materials cost more. That's just the way it is. Expert construction professionals cost more, too. Why? Because they know how to build a roof that won't leak. They know how to do a concrete pour in such a way that your house won't settle in odd ways later. They know how to cure a subfloor so a year from now it won't creak as you're walking over the carpet. You can pay less and get less experienced software developers, but don't be surprised when your roof leaks and your floor squeaks.

TIME Every house is different, but in general when building a house, you need to follow this rough order: First, create the plans. Then set the foundation and frame it out. Then move on to walls, windows, and roofing. Then build in electrical and plumbing. Finally, polish the details.

As you'd imagine, any time you want changes to the plan, you have to pay for them. The architect goes back to the drawing board and gives you the modified plans. Once the plans are finalized, you move on to the foundation and so on. Imagine that you approve the plans and then decide, half-way through the framing, that you actually want a 4-story house instead of a 3-story house, and you want the entrance on the north side, not the south side. Such a change would require an awful lot of work (leaving out dealing with housing permits), including tearing up work the contractor had already put in. You get charged a lot of money to adjust the plan of your house while it is in construction.

A house is tangible. You can see it and touch it. You can see the lumber sitting on the job site. You can see the workers tearing down walls and jackhammering concrete so the changes you need can be made.

Software is intangible. But the same sorts of things are happening when a change gets made. Programmers have to adjust code, sometimes completely overhauling it. Information architects need to reformulate how users move through the application. Designers need to reconstruct the interface. The fact that all this effort is more difficult to discern does not make it any less real.

When I run this analogy past clients, I also add this point: The flexibility of software, the fact that it doesn't require beams and concrete and glass and steel is a strength. It means that software can be adjusted in ways that physical structures cannot. But those changes are not made without effort.

The home construction analogy is far from perfect, but it has helped me put things into perspective for clients.

Quite simply, because there aren't enough people who are able to satisfy the demand. And because if you give them the right commitments (bug fixing, maintenance etc.) you can get stuck forever on a project if you're not a professional.

It's all about ROI. Ask how much does lack of the solution costs them. If no clear/detailed/honest answer, figure out with the client what it is, before you start. If it ends up being that ROI is lower then what you're charging, offer not to take the project. In the long run, you'll have happier customers.

If this is in response to RFP, and a lot of information is confidential, then ask for enough information to come up with base ROI with bunch of variables, so that client can plug in their own and extrapolate.

If it was me, I'd probably ask if there was any point continuing the battle. In my experience, some clients will pay you x10 for x100 productivity and return on investment, but some will not.

I had a client that hired me for a couple of projects at around ten times the normal salary they paid their in-house developers. This caused a lot of tension, but they trusted me to do a good job, and I ended up saving them millions of dollars. Their in-house guys could never do that, even if they all worked on it for twenty years, because I had something that they didn't have [1].

In the end, if the client doesn't see the value you will add, it may be time to move on, rather than fighting an up-hill battle. Of course, IMHO, YMMV, etc.

[1] The client asked for something that everyone told them was impossible - a complex system that business users could extend and modify themselves, without relying on developers to do the changes for them. All their in-house guys said it was impossible, not a shock really, but I said I'd do it, and I did.