So, it's been roughly two years now since I 'officially' became a web developer for hire. Formerly, my development work was either not web-related, or it was for my employer or my own business/personal projects. In that time, I've learned some lessons. I post them to remind myself of these lessons, mostly. But if you come across this, and learn something from it - I'll be very happy to have done some good.

Background

My work for hire has been almost exclusively for micro-to-small businesses or organizations. Most of the time, I am working for entities where a very small number of persons have the ability to approve things. Every client of mine I can think of right now has between 1 and 100 employees, with the average probably being 10. I mention this because this is going to make a difference in my thoughts and advice.

The type of web development work I do could be summed up as developing web sites with custom Content Management Systems (CMS). I generally provide end-to-end service; including hosting, administration, database design and development, and the like. I do not do design myself; I am either hired to work with a design provided otherwise, or I secure the services of a designer to provide that. I usually do the 'cut up' of a design into XHTML/CSS, and everything thereafter.

Be Clear About What You Do

Those who do not generally work with this sort of thing often will not know - or care about - the difference between a web site designer or a web site developer. Most of us know that. Most of us also know that the client probably shouldn't need to know it; that we should take care of it all. But where possible and useful, we should let them know what the difference is, and why it matters. A client who comes to me must know that 1) I am not the person to go to when you just want a 'simple' site designed and, 2) if you do need my services for your site, the cost and time spent will be greater than if you just hire a freelance designer to do a simple site with brochure-level content on it.

And for me in particular, one thing I have to learn to be careful about for my sake and the client's is to explain that it is not always in the best interests of everyone involved to actually have me entering content on the site. I provide systems to allow most computer-literate users to do that on their own. Clients, particularly on the scale I help, will want to seriously consider the extra cost of having me entering their content. But I have to be clear about that up-front, for them to make that determination.

I'm reminded of an attorney whose services we retained for issues related to an administrative subpoena with which we were served. Responding to the subpoena involved a lot of photocopying of documents. The attorney asked to make sure we were able to take care of that ourselves. When I assured him we could, he commented how that was fortunate; some of his clients at times were not able to do it on their own due to not being able to determine what documents were needed, not having the time, or even just not having access to a copier. While his staff could certainly do that sort of thing, the cost would not be small for the hours and hours it would take. For some, the cost would still be worth it. For us, it was not.

My clients must, likewise, be given the information they need to make choices like that. Both for the initial creation of the site, and for ongoing updates.

Get It in Writing - But Be Sure It is Understood

If you put together a good contract before you start your work, also be sure the client understands the important points. It is so easy to assume a client knows the difference between graphic design, database development, writing code and content entry. But honestly, do they? Don't try to overload them with the technical details of the differences; let them know what the differences mean to them, and to their project.

For instance, be sure your client knows of the differences between getting a proof of the site design and template(s), and final approval of the complete application, complete with functionality and content. Some clients may think that proofing the 'design' means that the site will basically be done. It's up to you to be sure they know just enough to know the difference. Not doing this can cause some awkward moments and some deflated expectations from the client.

Make sure that the client understands completely what is required of them, as well. Again; do not rely on wording in a contract/agreement to do this for you. Working with micro/small business has its own challenges when it comes to this. Sometimes, your sole proprietor won't have the time to meet with you to give you information you need or give appropriately detailed feedback on what you are doing. Creating a custom web site and CMS can be difficult without getting the custom feedback you need to do that in the first place.

It is especially important to be sure that you and your client both know and agree on who is doing what, and when; and what the cost of doing it will be.

Beware the Flat Fee - and the Hourly Fee, Too

For the creation of highly custom, database-driven web sites, without a very detailed spec list up-front, it can be impossible to come up with a fair flat fee from the start. Even if you are very experienced, and know how long X, Y or Z will take you to complete, be sure you also know what external factors will be involved. No matter how you are charging for your work, time is money.

Our contracting peers in all fields have told us this before, but those of us who are relatively new to being a contractor may need to learn the hard way, anyway. If a prospective client is absolutely set upon a flat fee, here are some random items to consider as possibilities. Not hard rules, necessarily; just things to think of.

Consider charging (perhaps a flat fee) for the time you will need to spend to get the quote. You will need to meet with the client quite a few times. They will need to provide you with information on the quality and quantity of information. They will need to agree with you up-front on exactly what functionality will exist; meaning a document describing that content will need to be written and revised multiple times. You will need to know when to expect data needed (either to help in development, or for content generation). In short, you need to know everything up-front.

In actuality, you should know all of that even if you are charging hourly - because you'll need that information to give a good, solid estimate to the client. Generally speaking, the perception is that an hourly fee places greater financial risk on the client, while the flat fee places the risk on the contractor. You should always do your best to do what is fair for your client, and you should always operate in good faith with them, and assume they are doing the same. That means you should do your best in both cases to make sure everything that is expected is known, up-front.

If a prospective client's demands for a flat fee make you uncomfortable, carefully consider things. I know how hard it can be to do something you feel may risk the loss of a potential client; insisting on more details and information up-front, before you give a quote; and being forced to increase a quote based on that information might make you worry you will lose the work altogether. But you must seriously weigh that against the risks of promising to be able to do far too much for what you are being paid.

Leave a Way Out

You never know what's going to happen six days down the road, to say nothing of six weeks or six months. No one likes to enter into an agreement while talking right away about how to get out of it. That's why prenuptial agreements seem a bit strange to most of us. "We promise to be wed until Death do us part; but just in case..." But a clear and fair Exit Plan is important.

Such a plan could be needed for all manner of unforeseen circumstances. Of course, everyone wants to complete the work on time and on budget, and be paid on time. But sometimes, someone's parents pass away at a bad time. Or someone's business location burns to the ground. Or someone gets sued. Or gets called for jury duty for the next trial-of-the-century. Especially when you are working with micro business - and when you, like me, are yourself a micro-business - things can happen, and when they do, they throw a huge monkey-wrench into things.

Your agreement should cover the possibility that, at any time, something may instantly prevent any further work on the project. It should explicitly detail what will happen at such a time. If there are different resolutions depending on who is at 'fault' for an inability to complete the project, it should also make clear how that fault is determined.

Either way, the resolution(s) provided should be as fair as possible. The ideal is that each side is left with something of equal or greater value for what they have put into things so far, especially if they are the 'innocent' party.

Clients can feel fairly uncomfortable about this topic at times. I try whenever possible to be sure that at any stage of a project, they would get more than their money's worth if I were unable to continue. I also try to plan the timeline of a project such that the things they need to have from me are done the earliest possible, while things they could more easily get from someone else come later. Cut-up of the site design into the XHTML template(s), database design and development, and then application code are therefore what I work on first; Implementing the site within the templates and data entry are the last things. It actually just so happens this isn't an illogical way to do it, either. But one effect is does have is that I tend to leave all data entry until as late as possible in the schedule, as it would not be of much use for a client to have a site with one part of the CMS database and code done, and all that part's data entered, but other parts of the system completely left undone.

Finally, keep in mind when laying out these terms that one side or the other is likely not to be happy if it comes to these terms being applied. If ever there is a time for clarity and fairness, this is it.

How Much Technical Detail?

Software Developers, like many other skilled workers, have their own language. Actually, we have multiple of them! And just like most other professional languages, no one outside of our little clique' really has any clue what we are saying. Aside from the MBA types perhaps, no one appreciates the use of arcane terminology simply because it is the 'correct' terminology. Just as a heart surgeon speaks to their patients using very different language than with their colleagues, we must do the same; we must learn what our clients' general level of technical knowledge is immediately, and remain sensitive to the more subtle details of their level of knowledge. For instance; just because two of my upcoming potential clients own and operate technology companies, that does not mean I can use exactly the same language I would with a fellow developer. In fact, it's good even to be mindful of what technologies a developer uses on a daily basis before making such assumtpions!

But I'm actually not speaking just of which words to choose, but also, how many? If you are reading this, you can probably guess one of my faults - I tend to overwhelm with information. Other developers, feeling it is futile to try, will share far too little. For people like me, keeping the information I do share organized better is helpful to my clients. For instance; if I have to ask questions or for information, I take care to try to do so in a single message (such as an e-mail, text/IM, or voice mail), without any additional information. If I feel a need to expound on some topic, I try to do that in its own message, and note at the top what it is; "Trivial info", "Important Details FYI", "File and Save", etc.

Further, however, you must consider not just what you believe must be asked or shared, but also; what does the client expect? It makes no difference here, in my experience, if the client's area of expertise is computer programming or brain surgery or landscaping; Some want a lot of details, some want no details, and most are somewhere along an infinitely variable range in the middle. Because folks like me do not have client representatives to handle that interaction, we have to constantly keep that in mind; Do I need to send this client an update? If so, what do I say? Do I need to ask for an opinion, proofing, or for them to choose from some options? How much detail in a response will they want?

In all writing, the best advice is generally to use as few words as possible to clearly convey whatever it is you must. When both/either you or your client are wearing the multi-tasking hat of a micro/small business, that is even more important.

Get a Lawyer

It's easy to make lawyer jokes. Ultimately, they are a little bit like us software developers, though; Few people understand what they do, and how important it is that it be done properly. The fields of law and programming both have so many amateurs in them, with or without the proper degrees and certifications. What would you tell a potential client of yours who decided to download and install a shopping cart application themselves, using some free software they downloaded off the 'net, based on the recommendation of the guy who taught the one-night "Computers for Morons" class he took at the local community college? Probably, "even if you don't pick me to do it, please get a professional!"

You should consider at minimum, having an attorney look over the basic contract(s) you will use with clients, or draw one up for you. It must be one familiar with business contracts at bare minimum, and should be one familiar with contracts for software/web development if at all possible. You could use something you found online and just add/remove from it as needed, but how do you know it covers exactly what you do or do not do? A few hundred dollars spent now can save you thousands later - or at least help you sleep better at night.

Build the Relationship

At important milestones in a project, and of course at the end, be sure you keep in touch with your client and thank them. Again, this is something that one of those sales reps would do if we were working for a larger shop - if it sold our services directly at all. But when it's just us, and a couple hired/contracted code monkeys otherwise, it falls on us to do this. A lot of the hair-pulling difficulties we can encounter - or the worrying about whether they will come up - get eliminated when we form a relationship with our clients. I have a handful of regular clients for whom none of the above things ever enter my mind as a potential problem. I've worked with them long-term, and they with me; we both know what to expect. This works both for good clients and the not-so-good ones. Knowing the good stuff about working for a client means you are much less likely to have to worry about it later. Knowing the bad stuff about working for a client means you can allow for it right from the start, by adding to the time and money you expect the project to cost.

So, be sure that beyond just getting the job done and collecting your fees, you also build something of a relationship with your client. No, I don't think you should use tricks from all those sales books, like spying on them to know every detail you can and springing those details on them to surprise and wow them with your ability to use Google or ogle the photos on their desk. Instead, I just mean the basics; be pleasant, be honest, be interested, be ready to give any assistance you can. People, like computers, respond well to certain kinds of 'input', and badly to others.

Relationship Tools

Some tools I've found to be invaluable;

• How to Win Friends and Influence People (Amazon), by Dale Carnegie. This is a must-read for anyone, and is simply timeless. Almost every word in the book feels like plain old common-sense. Yet, I don't know about you, but I seem to forget those lessons all the time. If you've avoided this classic because you don't like the idea of all those worthless "self-help" books out there, trust me; this one is different. It's an easy read. You can pick it up five minutes at day at bedtime, and you will be reminded to do little things every day which will help.
• Send Out Cards The simple effect of a 'thank you' card, birthday card, anniversary card, etc. can not be overstated. Especially in this day and age. You might go and post a dozen "Happy Birthday!" posts on the Facebook walls of your friends, but how many of your friends and business associates hardly get a real, physical greeting card any more? Send Out Cards lets you send these real cards right from your computer, with a selection that blows any card store out of the water, and unlimited customizability. And you can even have your real signature appear in the card(s) you send out. All for a great savings in time and money compared to going to the store to pick up a card.
• BNI For almost 25 years, BNI has been the world leader in helping its members increase their business through a structured, positive and professional program that enables them to build long-term, meaningful relationships with quality business professionals. BNI is an organization whose sole purpose is referring business between its members. Not providing 'sales leads' or having after-hours mixers where a dozen of your competitors are already schmoozing with the people you want to do business with. It would not be possible for me to be doing software development of any kind where I live without BNI, and all of my ongoing clients have come through it; Two, in fact, are actually other members of BNI. Because of all it has done for me, I am an assistant director (a largely volunteer position) in the BNI West Virginia region, which includes S.E. Ohio and parts of Eastern Kentucky. I recommend anyone looking for work as a freelance software/web developer find if there is a chapter in their area, and visit it to see what it's all about. Feel free to contact me if you'd like more information, and I'll send you in the right direction.

Closing

I consider myself an optimistic realist; Yes, people will occasionally try to trick you into a bad situation, and you must protect yourself from that by being careful how you approach new work. But more often, it is merely misunderstandings which cause issues. Much of what I've suggested here ultimately will help avoid some of the misunderstandings which can cause you some major headaches. Feel free to comment if you have anything to add!