Let's be honest, it sounds easy. Write a few lines of PHP or knock-up some wordpress with a theme, tinker around with it and sell the service to your customers for a few thousand dollars a pop. I've made a wordpress site in less than an hour so even with some customisation, I should comfortably finish in week so a few thousand dollars for that is good right?

It would be great, except.....

It doesn't work like that for a whole load of reasons. These not reasons that you learn on one of those "learn to code in 30 days" courses that promise so much. All they really teach you is a few basics but learning to lay bricks does not enable you to build a house, there are a load of other issues. Most of these come out in testing obscure combinations of things late in the day when you thought you were nearly finished and which although you don't think are very serious, the customer thinks they need to be fixed before they can possibly sign-off the site.

There is also the difference between your assumption: That the customer knows exactly what they want before you start anything and the reality: The customer has no idea about anything, including their own business processes and they definitely have no expertise in anything web related so usually what happens is that you think you have a whole lump of the site finished before the customer then decides, "now that I can see it, I've realised that it won't work properly".

There are soooooo many examples of this happening in all sorts of trades but I see most of it in web designs and the massive gap between customer expectations and your own expectations.

So where do we need to rewind to? The first contact:

Customer: How much for a web site?
You (should say): There is no way on earth I can answer that question without knowing almost everything about your system
You (actually say): They usually cost around $2000 depending on how complex
The customer hears: It will cost $2000 unless some kind of natural disaster occurs.

Straight away, your expectations are already adrift because you want to be nice and helpful (engineers like being helpful) but you are not being helpful because you are creating a poor foundation. It would be great if developers could start acting like professionals. Could you imagine saying to an architect, "how much to design a house"? What would the architect say? So why don't we say that?

We should have a pre-packaged piece of text that describes what affects the price of a web site. We can point people to it on a web site or we could print it out and give it to them. Let them know that although web sites look simple, they are not. Small changes on the surface can have large knock-on effects in timescales, stability and most importantly: costs!

This is hard because some people will say, "a web site costs X dollars" and the customer thinks you are being awkward and evasive so they go somewhere else but you already know that people say that, so you need to manage it, you need to tell people convincingly that anyone who offers a fixed price is either going to short change them or will not allow them to make changes.

So knowing that customers do not usually understand web technologies and sometimes don't even understand the business they are trying to help with their new web site, you have to manage that too. You should really employ a Business Analyst who is both cheaper than an equivalent developer but also, hopefully, much more skilled at digging into what the business is trying to do. This might be a quick conversation, "I want an online shop" or it might be very complex and take several weeks of time (or longer). The good thing here is that even if they get to that point and things start getting complicated, they can still pay you for your analyst time and could walk away with something that they can reuse later perhaps after saving more money or perhaps once they've thought about what they want.

The really important thing that follows is change control. In smaller companies, we get a call from the customer and he says, "I just noticed that button was a bit small, can we change it?". Of course we can, we are helpful but what is the knock-on effect? How are we going to record or charge them for this work? Seems small but we still need to pre-empt what will really happen. The customer will ask for loads of small things without realising how quickly they add up, they will then be surprised at the bill we are sending them and get all funny thinking we are ripping them off. It's a pain but we need to manage change - it does happen. We might have included some hours in the bill for rework, which we will agree up-front. All changes are then requested, put into some technical detail and costed and then SENT BACK to the customer to authorise. Funnily enough, the person paying the bill is usually tighter than the people who are asking for the changes so let them argue about whether the change is important now or never! The same list gets added to for every change, the billing amount increases each time so the customer has visibility. We should do NOTHING until it has been authorised however tempting it is because then we are working for free and you will eat up enough of your free time fixing unexpected things.

So then how do we finish? If they keep paying you to change things and are happy to defer the release of the site, that's their call but you have to decide before you start the project what your acceptance criteria are. At what point can you objectively say that you've finished? Again, you know that people have different opinions on things so work it out in advance, put it in a document and get it agreed. You might say that the site will work functionally on all the latest versions of browsers and IE from version 8 onwards (for example) meaning that the site is navigable and looks close to correct. You might exclude browser-specific layout issues that are minor and you might exclude any browsers that are not mainstream. If it's broken in them, it's up to the customer to pay to fix it if they think it's important enough, otherwise, it doesn't get done.

Of course, the job doesn't stop there. You have a working site and 2 days later, someone calls you up again and says that X,Y,Z isn't working. Perhaps the server disk is full, perhaps the database has fallen over but have you agreed up-front what service you are providing? You might say that you will investigate and find problems for free but fixing them will cost money except in certain cases where you have made some kind of serious error. Of course, the customer will want you to support it forever but that is probably not your main job so make sure you charge money for it (most industries give X months free cover and then you're on your own or you pay) and MAKE SURE you have agreed this all up-front so you can point to the document and say that replacing broken hard disks is not included in the price and you will charge X hours at Y dollars per hour.

This stuff seems boring but it will totally increase your profitability. It's not that the current popular way of working is providing cheap sites for people, it is providing inefficient expensive sites that are a pain for the customers who order them and a pain to the developers who are building them!

Learn these things, ponder them, consider the types of things that will go wrong and then put in place some kind of framework that makes it pleasant for the customer and efficient for you!