You have this great idea for a website, or Mobile app, or a software; and you choose a developer to make this fabulous product for you. Exciting times, and great adventure until something goes wrong, and you find you are held with a gun against your head!!

Sadly we see this too often. With clients at their wits end, their business in disarray, and nobody can help them, or more to the point, nobody wants to get involved.

So what goes wrong and how can customers avoid this?

All websites and applications are made using code. There is a good reason it is called “Code”. Code by definition is a secret language, which enables only those who know the code to understand it.

So if you do not have documentations detailing the code, you are in deep trouble, as you cannot decipher the code and nor can anyone else.

What Documents do you need?

Web development or any other kind of software development needs to be documented and these are the documents you need.

1. Requirements Documents

The best advice for everyone working with a developer, is to make sure that they document what they require the software, or the website to do. It is absolutely essential.

We know this is boring, but being a hostage later is not much fun either!

Sit down with your team and define:

• What you need to achieve?
• What functionality your website or software MUST have?
• What functionality is nice to have?
• What are the “What if” scenarios?
• What do you want to happen in each case?

Hopefully you get the picture, but you must document these. It not only helps your developer understand your needs and expectations, it also helps you avoid any misunderstanding and disputes.

Here are some guidelines on what your “Requirements” document should include.

2. User Manual

When the development is finished, insist on a user manual. Your user manual should have a clear description “How to do things”, and where necessary screen-shots, flow charts, etc.

This will help you train staff in the future, but also if you ever need to add functionality, or request a bug fix, you have a reference point. Remember the very definition of a bug is “when the software does not behave as described in the manual”. If there is no manual, there can never be a bug, which explains why some developers are reluctant to provide you with such a document.

3. Code Documentation

This can only be done at the end of the project, and it should be a supplement to your user manual, which describes “How things are done” within the software.

For example it should describe what PHP calls are made, or scripts are run, when you press a specific button, or what scripts/php calls are used to deliver the results and make the functionality, well…, function!!

This is a critical document as it allows your developers to identify problems, or add supplementary functionality. Additionally, this allows other developers to help you if you ever need to go to someone else for help (which explains another reason developers are not so keen to provide this).

Why do some developers not do this?

There are 2 major reasons some developers do not like this approach.

Firstly, most engineers are reluctant to do this as it is boring and tedious work, but this is also a time consuming and therefore expensive process.

Secondly, by not providing documentation, it ties the client to the original developer, which means any future problem solving, or enhancement to the product, can only be done by the original developer. If 3rd party technicians attempt to do any work, they have to reverse-engineer the code so that they can decode what is going on inside the magic box. Remember it is code, and if you cannot decode it, you cannot support it. Reverse-engineering a product with documentation is difficult enough, but doing it without is time consuming, painful, and not always successful, hence costly.

Developers may ask for more money for documentation, which is reasonable as this is extra work. However, this is well worth paying as you will save in the long run.

Summary

Documentation for your bespoke software, website, or additional functionality is critical. Miss this part and you will be held hostage. Most experienced developers will not touch an undocumented software as they have no idea what the outcome might be!

Ask for documentation as part of your bidding process, and ensure you get the correct documentation before you pay for the work in full.

If your potential developer will not offer this service, or refuses to “get involved”, we recommend you walk away and find someone else or contact us. If you do not, you will pay a heavy prices later.