Why is customized software so expensive?

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.

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.

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.

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.

You seem to have two problems: 1) the overall perception of tech; 2) the sales cycle of substantial B2B purchases.

For #1:

Blame the pervasiveness of high technology. In general, technology is wayyyy overexposed as an opportunity area. Everyone now believes that they "know" that technology is straightforward in our society.

I mean - open up a typical cheap smartphone you can buy today. It contains more computing ability than everything onboard the Saturn 5 based Apollo moon missions.

There is an old saying - "familiarity breeds contempt" - technology has been a business media staple for 20+ years. Today, virtually every two bit low end business owner believes that gifted techies are a dime a dozen and he can summon them cheaply by clicking his fingers.

The first inkling I had of this was when Business Week in the early 90s started publishing glowing articles about object oriented programming. My boss at the time, a relic himself with dreams of self-aggrandizement of enslaving low paid coding serfs as menials in his imagined empire (I'm really not kidding!) immediately seized on this as further proof that techies were expendable, dime a dozen lowlifes.

Also, software has indeed become a consumer and business commodity. Unfortunately, software and technology in general are perceived by most outside technology (and a lot of those within technology, in management and leadership roles) as a commodity, like beans, hog futures or scrap metal.

This started when it became very difficult to show a business customer the difference between a highly refined product like Microsoft Word that cost $200 at the office user level, and a custom software program that may require hundreds of hours to develop. "Word costs $200, why are you being an arrogant geek who plays at your work and ripping me off", the narrative goes.

The only answer to this problem of image is portraying high business value and face time. Now this leads to point #2 - handling the sales cycle.

Non-idiots will realize that something extremely specific to their particular business situation will most likely have substantial associated cost.

The rest should be disqualified as prospects.

The subject of "adding value" itself is a constant challenge.

One challenge is clear and accurate communication. Many customers really don't want to tell you that they need help in a particular area, so you never get to the core of the problem where you could help them uniquely.

Partly it's a pride thing, and partly, it is legitimate competitive intelligence that could help their competition if disclosed. Also, a lot of prospects just want to play games - they believe that it's your job to participate in a guessing game until you spot their problem, or, God-knows-what.

Another challenge to complex sales is qualifying the prospect in the first place. Perhaps their business does not produce enough value or even have enough unrealized value to cost-justify custom software.

And yet another aspect is comparison to off the shelf tools. Look at the prevalence of CMSs and things like WordPress in the web design space. The age of custom code for generic web sites is over. Enterprise and B2B software is headed for that place. At some point the arguments in favor of custom/special lose their weight.

I'd say look for books and articles on selling high end IT solutions. The overall concept here is the "complex sale". The key is building enough trust that the prospect starts to understand and accept your formulation of their problem.

Now, words to the wise -

If the prospect is untrusting and dismissive of any overture to drill down to their real needs, LOSE THEM.

If the prospect plays games, LOSE THEM.

If the prospect doesn't listen to you, LOSE THEM.

There is no compromise possible on these three points. You can't do high end business with someone who doesn't listen or who is distrusting.