Developing Software when you are Technically Challenged

Matt McCormick


Recently I read a blog post from one of the RSS feeds I subscribe to. The author was looking to create an iPhone app to promote his business. He researched a few options - one quoted him $20-$30,000, another $8-10,000 and he also came across a website offering to create one for $499.

From reading his blog, I assume he has little-to-no software development experience. This is a scary position to be in. How do you choose between widely varied options? What could the difference possibly be if the product is the same?

To the layperson, the obvious choice is the $499 option. The logic for choosing this option is sound - he wants an iPhone app; these companies all make iPhone apps; therefore the cheapest one will be the best option for me.

Unfortunately, it is not so simple with software.

After being involved in software development for the past five years I’ve learned that out of the full cost of developing software, only a part of it comes from the initial creation. To rephrase, much of the cost of developing software comes after the software has been created.

How can this be?

Many non-technical people put in charge of software projects do not really know what they want. Usually, they have a vague idea but as the product is developed, more ideas will come. These new ideas require changes to the product. If you’re not familiar with the way software is developed, you may think this is simply moving around text as you would with a text editor like Microsoft Word. Nothing could be further from the truth. In practice, software development is a type of architecture.

Let’s say you want to build a house. You have a general idea of what kind of house you want so you tell the designer you want a house with a certain number of rooms and so on. He designs the plans and begins building the house. Part-way through, you walk through the half-completed house and realise you would like the kitchen to be bigger and the bedroom to be moved to a different location. Is it going to be easy to make this change? No. Although software is not quite as inflexible to dynamic changes, it still requires the foundation to change which can be major.

Now a good software architect will try to design the software to allow easy adjustments along the way. However, these architects usually learn how to do this through years of experience. This means you won’t find them at the cheap end of the pricing spectrum.

So what is the $499 option offering? After taking a look at their website, they are offering a simple template option to create an iPhone app. This means you are locked into their system. If you want to add changes later, it is going to cost a lot.

If you are really, absolutely, positively sure that you will not want changes, then this option is a good deal. In my experience, this is rarely the case. Many clients come up with new ideas only after seeing the product in action.

If you go with the $499 option and you want custom changes, you will probably have to hire another firm as I doubt this company is in the custom-development business. That means that the new firm will have to invest time learning the system and implementing the changes. I’ve even worked on projects where it has been cheaper to throw away the original work and start over from scratch. This means the initial cost for developing the software was a complete waste. Either the company doing the work did not fully understand the client’s requirements or the client did not know what they wanted well enough to explain it.

Probably the worst thing you can do as a non-technical person starting a software project is to just go with the cheapest option. The initial development cost can be only a small part of the final cost.

Detail what you are looking to accomplish with the software. Spend time communicating with the vendor what your end goal is. Make sure any potential vendor has clear guidelines what they will support after development and make sure they are asking lots of questions to fully understand your requirements. Many software projects go awry not because of technical challenges, but because of communication challenges. Good communication will help your software project immensely.