Why is software so expensive to create?

It’s just a little CD or something you can download. How can that possibly cost so much and take multiple years to create?

Over the years, I’ve learned many things about software development. Software is a product just like any physical product you can see and hold. Just because there’s no raw materials like steel or glass doesn’t mean that software is free to create. Just the opposite, really.

When you’re creating a physical product, you can see for yourself when progress is made and many defects are obvious. Maybe it’s a wall leaning to one side instead of being straight, or it’s a door with a big hole that lets mice enter, or it’s a pencil that just feels too heavy. You can’t do that directly with software.

Software is complicated, so let’s compare it with something we can all agree is also complicated. How about a race car? A modern race car has a lot of high-tech and precision components. I’ve never tried to buy a race car myself or have a race car built but I’m sure we can all understand if creating a new custom-built race car costs millions.

Let’s change the race car to make it more comparable to creating software.

Imagine trying to build an invisible race car that drivers expect to run at top speed around a track. While we’re at it, let’s make the track invisible too! And let’s remove the driver and just give the race car all the instructions it needs before the race starts so it knows when to turn left or right, when to make a pit stop to get the tires changed, and how to respond to other crashes so our car doesn’t crash too.

This is unheard of right? Impossible even.

Yet software does all this every day. It runs at full speed making billions of invisible decisions each second. That’s why we have to remove the human driver. It’s too fast for a person to keep up with. Software needs everything planned out ahead of time. Computers don’t think and they have no common sense. Computers only follow the instructions exactly as they’re written.

Just because we can’t see or touch the instructions doesn’t mean they don’t exist. They do exist and somebody had to think and plan out all of them.

Creating software needs an indirect approach. It’s mostly a mental exercise that uses tools to help software engineers break an impossible task down into smaller and more manageable pieces. It takes time, patience, and special training to write software. You can learn how to code yourself with practice.

The absence of a visible form not only makes the software harder to create but it also leaves doubts about what it really does.

Let’s face something we’ve all encountered…

Software piracy

You can’t walk out to your driveway, press a few buttons, and make a full copy of your car. Even if it is invisible. The only way to get a new car is to pay lots of money and spend all day at a dealer haggling over the price and options. So we know and understand it has value. If somebody steals your car, it’s a big deal and they can go to jail.

But with just a few keystrokes and USB storage, you can make a full copy of software and put it in your pocket. It’s easy to create pirated copies. When somebody makes a copy of software and gives it to somebody else so they don’t have to buy it, that’s stealing. It might not feel like theft because the original software remains untouched. But it is.

Even if you don’t steal, the fact that it’s so easy lowers the value of the software in our minds. We tend to think of software as being less valuable because it’s so easy to make copies.

Imagine if money was easy to duplicate. If too many people flood the market with copied money that’s identical to the real thing, then the value would drop. That’s why we have government agents watching out for this and why money is printed with so many protections.

It’s a subconscious response that we have to be aware of in order to change. Whenever we see a price tag for something we feel unsure about or feel deep down that there’s no value, then of course the price will seem expensive.

We’re unsure of software because we can’t see it or hold it. We can’t judge its quality until after we buy it and try running it. This doubt makes us hesitate and question the price.

And we usually don’t consider all the work that went into creating the software. We’re just aware of the final result. A result that can be easily copied. Why pay money for something that’s so easy to steal?

Sure. Not all software does this though. For customers considering buying your software, then this first method will help you and them the most.

This is the trial method.

It helps customers overcome their doubts about the quality and ability of the software to meet their needs.

It’s really simple. Potential customers need a way to try the software before buying it. Just like how a car dealership lets you take a car for a test drive, a customer needs to be able to test the software on their own. They’ll need more than a drive around the block. Let them try all the features for at least a week. This gives them plenty of time to see that the walls are straight, no holes, and nothing that feels clumsy or awkward.

If they like everything and it solves their needs, then they’ll be able to justify the price.

Doing this will help you to get more people interested.

Another thing you can do will prevent copying and raise the perceived value. It also works really well with the first method.

This is the licensing method.

It doesn’t really stop copying. Software is still just a bunch of simple instructions. There’s no point in trying to fight the copying. That’s a losing battle.

A better solution is to enforce the running of those instructions. Build into your software extra instructions that check for the presence of a license key. This has the added benefit of giving your customers something other than software to buy. Buying a license feels more substantial and solid than buying an invisible set of instructions.

Plus you can position the license as an ongoing service. Customers not only get to run the software, but having a valid license gives them the ability to download updates and bug fixes. It reinforces the solution to the first problem by reassuring customers that if there are any quality issues, then they’ll be fixed with an update.

And that initial trial period? Just give the customer a full license that lasts for a week.

When the license expires, you can choose how you want your software to behave. Should it stop running completely? Reduce the features to give only basic or restricted abilities? Or stop future updates and bug fixes?

Now that you understand how difficult it is to build a software application, how much are we talking about?

There’s no single answer to this question. But I can give you some advice that will help.

The biggest problem is the range of software. Are we talking about something that can be finished in a single weekend? A month? A year or more?

Learning how to estimate software costs and schedules is a whole topic in itself. Probably even a whole book. I’ll just briefly say a few things to explain the problem and how you might want to handle it.

It all starts when a customer wants you to create software. Or maybe you are your own customer and have your own idea to create.

How do you begin?

The best way to estimate something is to compare it with something similar that’s already been done. When you want to sell a house, a realtor will find other similar homes that have sold recently and use them to set the price of your house.

This is really hard to do with software. Not always. Sometimes, especially if you work for a large company with a history of writing software, you can find a similar project. That’s not normal though. Most of the time, you’ll be guessing because what you want to create has never been built before or you have no data and price available for other projects.

You might find some advice telling you to break a software design down into tiny pieces where each piece can be completed in a day or less.

Yeah, good luck with that…

Designs change. And coming up with a full design in the first place so you can begin dividing it up is the best way I know to fail. A design document can sometimes be called a spec. I’ve written them before. They usually don’t last more than a week.

If you can’t find something similar so you know exactly what you’re building and how much it’s likely to cost, the next best approach is to be agile. Identify the most valuable need you can help with and then build the smallest solution that solves that need.

This is called an MVP, or minimal viable product.

If your goal is to build a car, then an MVP is not an engine. It’s not the seats. Because the most valuable need is transportation. An engine and seats don’t actually solve that need on their own.

An MVP will answer things like,

• “How many doors do you really need?” Probably none at all. At least in the beginning.
• “What color is best?” Let’s forget about the paint for right now.
• “Does it need LED headlights?” Let’s just plan on driving only in the daylight for now and forget about the lights completely.

Instead of trying to figure out how much the software will cost to create, it’s better to set a budget with your customer that’s within a reasonable range and then deliver a series of products that each follow the MVP pattern. Each delivery will build on the previous and solve the next most valuable solution.

This way, the customer is aware of the progress and can change direction at any time without affecting a bunch of designs that haven’t been built yet. If the customer doesn’t like something or wants to change something, then hopefully only the most recent MVP needs to be adjusted.

The goal of being agile is to always have your most recent software MVP that you can use. You avoid the problem of not having anything in a working condition until the very end. Because what if you never make it to the very end?

This is my personal opinion. I know people who swear that scrum is the greatest way to build software. I don’t buy it. I’m all for agile development. And can contribute to a scrum team just fine.

I’ve seen too many times when scrum is used without any real benefits.

You see, being agile is all about delivering value and avoiding unnecessary distractions. Scrum has always seemed to me to be more about following a process. There’s sprints, and planning meetings, and daily stand-up meetings, and stories, and epics, and the story points… Don’t get me started on story points. Really, I’m going to resist the urge to say more about story points.

Must. stay. focused.

It’s not that scrum is wrong. It just has too much rigidity. Not everything you work on fits into 2 week sprints or needs to be estimated using fibonacci numbers. You’ll be much better to plan your first MVP and get started.

Let each component complete in its own time and don’t try to speed it up a couple days just so it aligns with the end of the current sprint.

Let’s say that you think the first MVP will take you 6 months. That includes a month without any programming at all to figure out the details. And you have a general idea of where you’ll go after that.

Nothing too elaborate. Just a direction more than anything else. You can use that direction to make sure you complete the first MVP facing the right way.

Think of how a professional pool player makes a shot. It’s never about the current shot only. Sure, that ball has to go into the pocket. But where should the cue ball end up to give the best position for the next shot?

Let’s say that you think the whole project might take 2 years to complete. That’s just a guess at this point and that’s okay. It’s a reasonable time to consider when the first MVP will take 6 months.

If you thought the whole project would take 7 months while the first MVP will need 6, then something is not right. Your first MVP should probably be about a quarter or less of the total project. Again, the goal is not to create some fixed and rigid rules.

These are just guidelines.

Once you have an idea of how long your first MVP will take and a reasonable guess for the whole project, you can start putting together a schedule of costs based on how many people will be needed.

You’ll want a mix of skills and experience.

Not everybody needs to be a senior expert. Salaries can also change based on your location. I’m not considering foreign workers in another country just yet. Keep reading if you want to know more about outsourcing work overseas. You can always add that extra complexity to your budget if you want to explore that path.

The following salaries do not include taxes or benefits:

• New developer, program manager, or tester: $75,000 or $6,250 per month.
• Mid level developer, program manager, or tester: $100,000 or $8,333 per month.
• Senior developer, program manager, or tester: $150,000 or $12,500 per month.
• Project manager: $125,000 or $10,416 per month.
• Designer: $100,000 or $8,333 per month.

Let’s plan to have a project manager the whole 2 years to help keep priorities organized and let others remain focused on their primary tasks.

A mid level or senior program manager will also be good to have available for the entire project. A program manager can help work with the customer to define the MVPs. A quick prototype can also be valuable.

We can use a designer for maybe the first 6 months. This role is still useful to the project after the beginning but will probably not be needed full time.

Let’s bring in a senior developer about a month in. And then a senior tester at the same time or a month later.

A lot of mistakes can be avoided by including and getting a test team involved from the beginning. Or at least very close to the beginning. Don’t wait until near the end to start testing. That’s another guaranteed way to fail.

We’ll add other people over the expected 2 year project so we get this:

• Project manager (24 months): $250,000
• Senior program manager (24 months): $300,000
• Designer (6 months): $50,000
• Senior developer and tester (23 months each): $575,000
• 2 mid level developers (22 months each): $366,652
• 2 mid level testers (20 months each): $333,320

First MVP done at this point.

This is not just a demo and then it gets put away. Because this solves a real problem, then people should be wanting to use it right away. Gather feedback. There’s no substitute for real usage. It will help guide the rest of the project. Each additional MVP release should also be put into use.

• 2 new developers (18 months each): $225,000
• 2 new testers (18 months each): $225,000
• 2 mid level developers (16 months each): $266,656
• 2 mid level testers (16 months each): $266,656

Extra testers toward the end will help improve the quality.

• 4 new testers (9 months each): $225,000

Total salary cost: $3,083,284

This also does not include the cost of office space, furniture, computers, software development tools, hiring costs, office supplies, or anything else. It’s just base salaries. Feel free to adjust it as you think best. This is really just a guess that you can use to get an idea of what a software project will cost over 2 years.

Yes, there are ways to lower the price. Let’s talk about mass production first.

We buy a drink at lunch for a dollar and think that’s cheap. Have you wondered why it’s so cheap? Even a dollar lets the store make money. It’s because the store buys a lot of cups and lids at once, thousands of straws at one time, and whole truckloads of the drinks.

The pattern continues.

The drink manufacturer has a factory where it mass produces giant tanks of drinks. Sugar is brought in by trains cars in bags we can barely lift. Everything is done at large scale so the total cost gets spread out over millions of drinks. The cups, lids, straws, and even the machines you use to fill your cup are all made at large scale and the cost gets spread out.

Software is different. It’s not so much mass produced as it’s mass designed.

Sure, there are manufacturing and distribution costs for software. But these costs are much less than the cost of building the software in the first place. Remember, software can be copied easily.

When you create software, you write it once. In order to lower the cost, you have to be able to sell it to multiple customers. Even one other customer will cut the cost in half.

Maybe you can spread the cost between a lot customers. This is hard because there’s a lot fewer people buying software than people buying drinks each day for lunch. But that’s okay because you get the most significant cost savings at the beginning. In other words, going from 1 customer to 2 customers divides the cost in half. While going from 100 customers to 101 customers barely changes the cost at all.

When you want to create custom designed software, having a few other customers or partners who are willing to share the cost can be very effective in lowering the cost for everybody.

This is similar to the previous method of lowering the price. It can be very profitable for the software developer to offer a customer a lower price in exchange for the right to sell the software later to other customers.

Let’s say a customer comes to you and asks you to create software. You figure out the MVP and go through all the budgeting and guess that the total cost will be over 3 million dollars. So far, this is just like the earlier example.

When the customer calms down from the shock, you offer an alternative. You offer to build the software for just 1 million to meet the customer’s needs exactly. The customer gets everything they need at a third of the cost.

In exchange for the discount, you agree that you’ll continue to own the software and can modify it and sell it later to other customers.

You get the first million dollars of the development costs subsidized by your first customer and only have to finance 2/3 of the cost to build a product that you’ll own. It’s a great way to save a huge amount from your own development costs.

This is a technique often overlooked when writing code that can save you a lot of money.

It’s especially easy to overlook by eager developers who want to do everything themselves. And by companies with a culture of keeping things to themselves.

The best way to save money is to make use of mass produced savings yourself. What I mean is this. Instead of writing everything yourself, look for pieces that might already be available for sale.

You might have to pay a lot of money. At least a lot of money as we might think when compared to our personal finances. But not a lot of money when compared to a 3 million dollar software budget.

Let’s say you identify a piece of software that you can either build yourself or buy from a vendor. The vendor wants $50,000. That might seem like a lot until you consider that it should be well thought out by experts who have been working on that piece of software for years. It’s complete and fully tested. Even if you could write it for the same cost in salary, would yours be as good?

Remember that this $50,000 piece of software is for sale and that means the development cost is being spread out between all the buyers with profit also going to the vendor. It might have cost them $500,000 to develop. Chances are good that you’d end up spending $500,000 too if you tried building this yourself.

When you look at it like that, $50,000 is a bargain. It’s not a $50,000 cost. It’s a $450,000 savings.

The one cost that I outlined above was salaries. And I mentioned that salary costs can change depending on your location. That’s true but only because we normally hire employees to work in the same office.

What if you hire employees to work in a different office in a different location where the normal salary is much less? That’s what offshore development is all about.

Countries like India, Russia, and the Philippines have highly trained software engineers ready to work on your projects. And the cost is much less. Even if you pay $20 per hour, that works out to a yearly salary of just $40,000. That’s much less than a basic starting salary of a fresh computer science graduate who might ask for $75,000.

It’s almost half.

And it probably is half when you add in taxes and other benefits. The point is that you can drastically cut down on your salary costs by hiring experienced software developers from other countries.

Yes. Definitely. I’ve had direct experience working with engineers from other countries before.

There are things you need to be aware of.

The first thing is that you’re not likely to hire engineers directly to work for you. How will you even begin the interview process? Where will they work? Do you think they will want to work for you like this? Probably not.

Most talent will be available through agencies that work with you and have their own employees that they make available to help with your projects. You’ll have a project manager who will coordinate the work and be your point of contact.

The project manager will be able to speak English but there’s no guarantee the other engineers will be able to communicate in English.

Because you’re dealing with a company that needs to make money too, then the programmers will actually see less of what you’re paying. If you pay $20 per hour, they might only get $8. That might still be good money but do you really think they’re going to be fully motivated?

It’s been my experience that you can get good quality work that fully meets the requirements you provide. The problem is that you need to specify everything. If you leave something out or forget something, don’t expect the result to meet your expectations anymore.

It’s not because of anything on purpose. They just don’t know. And many times, they’re under pressure to deliver and won’t stop to ask questions.

Speaking of questions, you’ll find the communication to be slower because of the time differences. You might only have a couple hours each day where both teams are available and that usually means somebody has to work late.

It is possible to get good results. I recommend that you carefully choose the tasks that you outsource. Some tasks are better than others. A really good candidate is when you have to do something multiple times with only slight differences. Do one yourself and work out all the details. This can then be followed with fewer misunderstandings.

I’m not talking about free. There is a cost. It’s not money though. You can substitute your own work in place of millions of dollars of salaries.

How?

The first thing to understand is how much software will you need to write. Let’s look at how many lines of code are actually in a typical software project written over two years like I described earlier.

Based on my experience of working on successful projects, I’d put the size at somewhere around 150,000 lines of code. That’s well within what a team of software engineers can produce over two years.

This many developers can definitely write a lot more than 150,000 lines of code. But is there a need for more code? Maybe. I have no idea what your software project is all about. I can say that 150,000 lines of code is a decent sized project that will handle a lot of situations. It should be a good starting point for your estimates.

But here’s the thing, those engineers don’t write code at a constant rate every day. Some days will be full of meetings and nothing gets done. Plus, remember how I described the schedule? Not every developer started on the first day. More time is needed to train the new developers.

It was only during the second year that the project was fully staffed.

How long would it take you, either all by yourself or with a friend, to write the same amount of code? In other words, could you do the same work that would normally cost 3 million dollars in the same 2 years?

Sure you can.

Can you write 300 lines of code each day, 5 days a week?

If so, then that’s what it would take for you to create a project of the same size in the same 2 years. You’ll have to work hard but it can be worth the effort.

Do you have a friend who’s willing to work with you? Then each of you only needs to produce 150 lines of code each day. You can lower that by working together one weekend day each week. You really only need 1,500 lines of code each week. I divided it into 5 days. But maybe you’d rather just crank out the code during the weekend instead.

It’s up to you. If you really believe in your project, then this will work. You can finance all 3 million dollars of work without taking any loans. All it takes is your own work.

And since this is your own project, there’s nothing that says you have to finish in exactly 24 months. Stay agile and keep writing your own code and you’ll get there.

Can you still afford to create your own software?

You’ll need to learn how to code.

It’s not as hard or expensive as you might imagine.

Take Up Code can help you with this part. Spend a few months learning the basics and then use your project as a way to try out the things you continue to learn about.

This link will open a new window where you can browse the available classes. The Essential 42 Live Online Classes will show you everything you need to get started coding from the very beginning. Classes start from $25.

You may not write very good code at first. And that’s okay. You’ll get better. Your mistakes will really help you to learn faster. I’m always trying to get students to build their own software. It reinforces what you learn and helps make it real to you.

So what are you waiting for? You have an opportunity to work a little each week and save a million and a half each year. At the end of 2 years, you can have a product you can sell. A product that others would be willing to pay 3 million dollars to have built for them.