Magical fairy for freelancers

The past few days have me heavily desiring to have that magical wand as advertised on the Disney Channel and wave either my client or his reported problem gone. For good. But too bad for me, fantasy and freelancing don’t cross paths so I was left with no other choice but to get my hands dirty and fix the problem he’s reporting.

But the problem is that I don’t think the problem he’s raising is actually a problem. Well, at least that’s the case for me and the 3 other people whom I asked to try and test the feature that the client is reporting to be faulty.

So how do I fix a non-existent problem? A product ‘error’ that I am almost sure is caused by his own ignorance. An ID-Ten-T-Error as they call it. Below are some points that I learned from this experience.

ID-Ten-T Error (also seen as ID10T and ID107) is a term often used by tech support operators and computer experts to describe a problem that is due to the user’s ignorance instead of a software or hardware malfunction. It is a masked jab at the user: when ID-Ten-T is spelled out it becomes ID10T, l33tspeak for “idiot”. (Though the usage actually predates L33T as a part of geek culture.) It is also known as a “Ten-T error” or “ID:10T error”. (from Wikipedia)


1. Give your client the benefit of doubt. The problem might not be appearing on your or your testers’ end but that doesn’t automatically qualifies the client reported problem as a fake. As a developer, you have to accept the fact that there is no such thing as a perfectly made, bug free software. Mighty bugs could still get through no matter how thorough you test your programs. As a consolation, consider it your lucky day to have beaten that one in a million odd of a bug getting through your infallible testing procedure.

2. Ask the client as much details as possible. Unless you have psychic powers, you won’t be able to solve the problem until you get to know the real score. How did the bug appear? Did the client do anything wrong that provoked the error? Ask as much questions as you need to in order to get the steps that would allow you to reproduce the error on your own machine. Screenshots would also be great!

3. Provide the client a documentation a.k.a. manual. Manuals are great in making paper boats during stable times but could serve as the client’s lifeboat on rough times. If the project is quite big and complex (I personally define this as projects which takes me more than 2 months to finish), then you might want to consider adding manhours on compiling a manual on your initial quote. Or if you want your client to love you, add a manual on your deliverable as an extra free service. Whatever the case, you just have to remember that manuals take time compile so you have to weigh-in first the benefit of making one against the efforts you’ll have to spend on making them.

4. Double check their computer’s setting. This is the most common culprit for the ID:10-T error. And this is actually the star of this post being the reason why my client was experiencing unexplainable bugs. Don’t expect your clients to be as technically savvy as you. That’s why they hired you in the first place. But sometimes, people could be so unnerving. You give them instructions in clear, plain English and yet they still don’t get things right. Exercise extreme patience on cases like these lest you’re ready to burn bridges with the client you’re dealing with.

5. Don’t forget the warranty clause on your contract. It’s my standard policy to provide all my clients warranty against defective work. However, I try to make it clear to my client that defective works are limited to errors attributable to my coding mistakes. Any errors outside of that should be charge accordingly. If you don’t do this, you will find yourself with the burden of having to support your client for the rest of your days here on earth (if that doesn’t scared you enough, contact me and lets celebrate Halloween together).

6. Charge support/maintenance fee if you must. The problematic work that I did for my problematic client is actually just an add-on feature to a previous web app which I did for him. And I only charged him a day’s worth of work since, well, it’ll only take me a day of work to finish his job anyway. Sounds fair enough. But then, the unimaginable thing happened. His job kept me occupied for 2 more days thus greatly reducing my income from that work. Extra work wouldn’t matter if I’ve caused the problem as stated on item #5. However, I didn’t. Sometimes, letting my clients know in advance that I’ll be charging them extra for the support is enough to filter out valid support requests from ID:10-T type of errors thus saving me time that I could instead use on making my other clients’ projects better.

Client’s have the right to request support for the services which they paid for and service providers have the obligation to make sure that their clients walk away with smiles on their faces.

For the past year that I’ve spent freelancing, I’ve learned that clients love the assurance that they have someone to run into should things go amok. After sales support is the magnet for repeat works and referrals.

But of course, assurance should come with a price. I guess it’s pretty safe to assume that my clients don’t want to work with a dead hungry developer. So don’t go fuming mad with the client if they keep on giving you ID:10-T errors. Help them solve it. Guide them. And don’t forget to bill them.