The Economics of Custom Software

It was a Saturday afternoon in spring, and I was sitting in my parents’ basement with the lights off, staring at the monitor belonging to our brand new Compaq Presario computer. I was replying to a client email debating the price of a project (after the work had been completed), which we had previously agreed would be a whopping $600. I was 12.

The whole thing had started for me about a year before, when I got a bit carried away in computer class and ended up building my school’s website. My school was affiliated with a church, so I built their website too. Those two were freebies, although I did end up leveraging the first into an educational copy of Macromedia Flash, which cost several hundred dollars at the time, and I believe the church found a volunteer stipend for me at the end of that year as well. I then made the website for a Bible camp, for which I timidly charged $300.

That early portfolio generated some good old-fashioned buzz, and it wasn’t long before friends of friends or family began approaching “the kid who did websites” with work. I had no idea how to quantify the whole thing (and neither did anyone I knew), so I did what seemed natural: I chose an hourly rate for myself and multiplied that by the time I thought it would take me in order to come up with price quotes. I couldn’t really fathom asking for more than $10 an hour for my time, so that was the figure I used. The whole process seemed simple enough: I’d meet with prospective clients, discuss the project, come up with a verbal estimate on the spot, and if they liked it that would be our fixed price. Then we’d shake hands and I would get to work. When I delivered the website, they would deliver the cash. (I’m pretty sure I was using my school’s server for client sites back then—nobody really had any idea what that meant, including me.)

So I was 12, it was a Saturday afternoon in spring, and I was about to learn a few things about written contracts, but I was also going to learn a giant lesson about perceived value. Obviously the verbal handshake agreement was a bad idea (I did end up getting paid for that job, but it was such a bizarre experience for the 12 year old version of myself to be giving a man 40 years my senior a written lecture about integrity that I avoided freelance work for several years) but what I didn’t understand then was that the crux of the argument had nothing to do with the numbers involved.

The man was complaining because the website “wasn’t working”, ie. people weren’t finding it and it wasn’t driving sales. I had done exactly what we’d agreed I would do, dutifully spending 60 hours writing HTML in Notepad, inserting the exact content he’d requested along with a special banner image for the header (with which he was particularly pleased) and a fancy Javascript drop-down menu, then deploying it all through a server somewhere for the world to see, at the address he’d so nicely printed on 150 business cards. I had exchanged time for money, because that was the only way I understood, and yet my client was unhappy.

I thought it was because I was charging too much ($600 was probably more than I’d ever held at once). Or maybe he was just trying to take advantage of me because I was a kid. But I don’t think that’s what was happening; it took me a long time to understand that what had probably happened was an enormous gap in understanding (a gap which, frankly, I could not have been expected to breach at the ripe age of 12).

Here are the things my client didn’t understand (this is not a list saying my client was stupid; these are things I should have been able to tell them but didn’t):

  1. Even 15 years ago (when websites were not nearly as important for small businesses as they are today), a business unable to generate $600 ROI from a website would have been in very bad shape. (I’m putting this first in the list because it’s a very important side note in this particular case but the rest of the points would still stand regardless of price or the health of the client business.)
  2. Building a website is not the same thing as marketing a website.
  3. If their only metric for website success is final, closed sales (website analytics tools did not exist at the time) and they’re a small business, it’s going to take a while before they have any useful data.

Here are the things I didn’t understand:

  1. Again, the client probably didn’t know points 1-3 above. I should have told them.
  2. The importance of written contracts (and a down payment, for that matter).
  3. The value of my time.
  4. The value of a website.
  5. The client was not paying me for my time. They were paying me for results.
  6. Search engine optimization. (In fairness to me, search engines then were nothing like they are now and search engine optimization was a nascent field.)
  7. Sometimes turning down work is the right decision. If I didn’t think the project would pay for itself within at least a year then accepting the client’s money would have been morally questionable. (As I said before, at the $600 price point this could only have applied to the most unhealthy of businesses.)

I could have saved my 12 year old self an uncomfortable email exchange (which had an outsized effect on me; my skin has thickened quite a bit over the years but I still find myself hinging a little too closely upon my clients’ feelings at times) with two sentences at the beginning of the process:

Please understand that I’m developing this website for you at a significant discount relative to market rates, and that I’m not engaged in online marketing; I can not be responsible for driving traffic to your website. Oh, and please sign this contract.

Today my business, Black Chair, charges orders of magnitude more than $600 for custom software projects, including websites (and when we build them, we help our clients get traffic). Sure, the sites we build now are way bigger than the sites I built when I was 12, and they include way more moving parts, but the only way we’re able to build big projects like that in a way that makes sense for everyone is by understanding the value we create, ie. by understanding what our clients think they’re getting for their money and why it’s worth that much to them. In other words, each prospective project is subjected to an informal cost-benefit analysis.


Building software is expensive. It requires a team of highly skilled workers collaborating on a complex project; 50,000 lines of computer code is not uncommon at all. The salary for computer programmers in North America, even in Winnipeg (where it is below average), is on par with or higher than the salaries for equivalently skilled engineers in other disciplines. Custom software development shops can’t expect 100% utility (percent of their time which is billable) for each of their programmers, either—70% is a more reasonable estimate for a senior developer (especially if they have administrative/sales roles as well). The sales process itself is expensive, and there is the usual company overhead (equipment, taxes, accountants, lawyers) as well. Black Chair doesn’t currently have office space or service/support/administrative staff, but we will probably need them soon. In other words, for the common paradigm of “determine how much time a project will cost, then estimate a price based on that time”, a programmer’s billable rates in a custom software company can easily be well over $100/hour. A team of three programmers working full time for a week would cost over $12,000—it’s easy to see how the cost of a project can reach $50-60k.


Although our average project size has steadily grown, Black Chair takes on projects of all sizes. Every time, it’s important to us that the project can reasonably be expected to provide a net benefit to the client, ideally within the first year. We operate in a space that many traditional business owners don’t properly understand, and which is is often the subject of breathless media and pop culture attention (eg. movies like “The Social Network”, news stories like Instagram’s $1B buyout, and the hype around subjects like “the cloud” and “big data” in business media) so it’s our responsibility to at least try assessing the benefits of a project properly before taking our clients’ money. (Besides being the right thing to do, there is no business upside at all to taking money from a client who can’t afford it—it tarnishes our reputation, prevents any possibility of future sales with that client, and puts us at risk of not getting paid.)

We always aim to build software which is a joy to use, and so I’m tempted to list “makes things easier and more fun” as a benefit, and we would certainly present that as a benefit to the client, but I think trying to assign a dollar value to that sort of intangible asset in this context is silly: our intention as a company is to build projects for which the tangible benefits outweigh the cost. (Side note: the majority of our clients are for-profit companies, which makes assessing benefits a lot easier. We’ve done a bit of work for non-profits, but I have no idea how to assess the potential benefits in that situation. The clients seemed happy.)

So, the financial benefits software can provide:

  • reducing time spent on tedious tasks (eg. providing a way for employees to enter their time sheets digitally instead of submitting a pile of papers to be entered manually by one person for several hours)
  • facilitating collaboration (eg. by having a central worksheet online for all departments to contribute to instead of passing paper around)
  • preserving data (eg. moving from fire/flood/theft-vulnerable paper filing cabinets to more secure and robust online storage)
  • enforcing consistency (eg. a form that automatically formats an output document instead of letting people mess it up in an editor)
  • optimizing processes (eg. automatically finding the employee schedule combinations that meet all requirements, or the closest ones that don’t)
  • improving communication (eg. a sales dashboard showing month-over-month performance of team members, or an internal company chat board)
  • collecting and analyzing metrics (eg. keeping track of how long orders take at a restaurant, analyzing them over time and by wait/kitchen staff)
  • improved organization (eg. warehouse inventory tracking)
  • increased sales (eg. marketing website/online store)

Off-the-shelf software can also provide these benefits, of course, and often at a much lower price. Where custom software hits the “sweet spot” is when off-the-shelf software doesn’t exist for a particular problem, or where extending/replacing it with a piece of custom software will provide benefits which outweigh the cost. Therefore, selling custom software is (or should be) all about finding these opportunities to help companies increase profitability—when we successfully identify those opportunities and properly communicate the benefits, the actual sale is a no-brainer and the project is a win for everyone involved.


Software developer, book writer, beer brewer :)

No Comments

Leave a Comment

Please be polite. We appreciate that.
Your email address will not be published and required fields are marked