This post was inspired by the countless nightmare stories I hear from prospects about how they hired a designer or developer, spent money and were left in the lurch. Either their site was never delivered, or it was delivered in horrific condition, or the cost spiraled out of control or about a hundred other variations that all boil down to the same thing:
I spent money. I didn’t get what I wanted/expected. Now I’m broke.
That’s usually accompanied by some variation of:
And my developer won’t answer my calls or emails.
I sympathize, not only from the standpoint that you’ve spent your hard-earned money for a whole lot of nothing, but also because that’s a job I’m not going to get now that you don’t have any left to spend.
This post is a bit tongue-in-cheek but the consequences are serious. So if you’re in the market to build a site, take it to heart and be careful about how you vet and hire a developer.
If you see yourself in one of these scenarios and have already been burned, then I’m sorry… and I hope that my suggestions at the end will help you avoid that trap again.
1. “I’m Eventually Going To Quit To Do Something Else And Leave You With No Way To Access Your Site.”
Call this an inevitable consequence of the DIY industry. With an internet connection and the vaguest notion of how to follow directions, just about anyone can get a website up and running.
Long gone are the days where you needed to know even rudimentary HTML or CSS, let alone design or programming.
But that doesn’t make someone a designer or developer. It doesn’t mean he understands your business needs or how to create an effective user experience or how to work to meet your goals.
It also doesn’t mean he is running a web business, which does mean that he is likely to move on and get a “real” job.
When that happens you may find yourself with just another “my developer disappeared” story.
You may find you don’t know how to access your own site, which means you won’t be able to update it and that even if you wanted to hire someone else, they wouldn’t know how to access it either.
Unless you’re lucky and can eventually track your developer down, you’ll end up having to start over.
The result? Wasted time and money and nothing to show for it.
2. “I’m Doing This At Night To Make Some Extra Cash But My Day Job Is Accounting.”
Thank those easy-to-use tools again, and couple them with a tough economy where everyone is trying to make extra money, and suddenly everyone is a designer or a developer.
You run the same “disappearing developer” risk when you work with someone like this but you also have additional risks: that you won’t be able to get in touch with your developer during business hours. That you won’t be high on your developer’s priority list. That there may be long delays between when you request something to be done and when it’s actually done.
Plus, when you’re dealing with someone who has a “day job”, you’re not really working with someone who specializes in the kind of service you require to run a successful website.
The result? Frustration, long waits, poor results and of course the inevitable… wasted money.
3. “I Don’t Know What I’m Doing But I’ll Do My Best And When I Get Stuck I’ll Disappear And Leave You With A Mess.”
A little bit of knowledge can be a dangerous thing. Since you’re busy running your own business, you don’t have time to study web design, SEO or keep up with whatever acronym or buzzword is taking over the internet.
So when someone talks a good line you nod along and assume she knows what she’s talking about.
She may, in fact, know a little bit. Enough to get by, and enough to give you some semblance of what you want.
The problem arises when you need a little bit more. And that little bit more falls outside your developer’s limited expertise.
That’s when she starts hedging. Or not returning your calls. Or being very busy. And you’re left with something that doesn’t work the way you need it to work and no way to get anything done.
Even worse, when you finally get fed up and go to someone else for help, that person won’t touch your site with a ten foot pole because your previous developer made such a mess out of it that the only recourse is to start again.
The result? See all of the above.
4. “I’m Going To Host Your Site From A Server In My Closet So I Can Make Some Extra Cash And It’s Going To Be Slow And Down A Lot.”
For a minimum investment and with the right technical knowledge, even you could set up a web server and host your site from your home or office.
If that sounds like a great way to save money, think again. Even the best of the best of the most expensive hosting providers experience problems. You can imagine the things that can go wrong in a home setup.
Just on the surface, there’s the issue of speed, which is limited by someone’s home internet connection. There’s security, which is as good as the next time his dog chews on a wire. There’s up time, which relies on never having a power outage. Plus what if a hard drive fails? What if there’s a fire or flood or a good, strong wind?
Hosting is pretty ethereal to a lot of people. They assume that if their site is up on the internet, that’s all they need to know. But if you’re blindly relying on your developer, there’s no knowing what you’re getting.
The result? Anything from down time to a slow site that your customers can’t access to lost data. Plus… lost opportunities.
5. “I’m Not Going To Give You A Contract Because I Don’t Want To Risk Legal Action When You Find Out I Don’t Know What I’m Doing.”
Take it from someone who has been on the wrong end of a handshake: if it’s not in writing, it means exactly nothing.
Sometimes people will justify a lack of contract by telling you it will tie you down to something you may not want or that you just don’t need it.
It’s not easy to write a good contract. Legalese that protects both you and your developer must be combined with the English language so that you can understand what’s going on. Sometimes that requires time to create. Sometimes money to hire an attorney.
So someone who is building websites quick-and-on-the-fly, often as a side job and usually for cheap, is not going to have the time or resources to put together a decent contract.
Plus that person isn’t going to want to commit to delivering something he knows he may not be able to produce. If it’s not in writing, pretty much anything goes.
Since legalese can be pretty scary, you may be just as glad not to sign a contract but you’re only harming yourself. When your developer can’t or won’t deliver, when he gets a real job or elopes with his girlfriend, when he realizes he’s in too deep and has taken your money for something he’ll never produce… you’re out of luck.
The result? Wasted time, lost money, quite possibly nothing to show for it and no recourse whatsoever.
6. “I’m Going To Give You A Low Cost But Later Tell You The Project Is A Lot Bigger Than I Thought And Charge You Twice As Much To Keep Going.”
People who do this are sometimes good scam artists. But more often they are simply inexperienced and they take on a job that’s a lot bigger or more complex than they anticipated, realize they underbid by a lot, and need to compensate for all the work they’re doing.
While it’s not unfair of someone to ask for more money for a bigger project, it’s certainly an unpleasant surprise when you expected to be within a particular budget.
And it may put you in a really tough spot because you expected a certain result for a certain cost and now you’re not going to get it. If you’ve got the money, you can spend more, but that also puts you at risk of falling down an endless rabbit hole of creeping costs.
If you don’t have the money, you’re out what you’ve spent and you probably don’t have much to show for it.
The result? Wasted money, no product, frustration, and a new mistrust for developers that can hinder future relationships.
7. “I Know Flash And Photoshop So It Doesn’t Matter What You Need, I’m Going To Convince You This Is What You Should Do.”
This is a particularly insidious problem because the person you hire may be quite competent. It’s just that her competence is limited to a specific program or method, so she’s not inclined to discuss options or business needs as much as shoehorn you into whatever her skill set is.
You may end up with a lovely site that functions flawlessly… and does nothing for your business. Maybe it’s not optimized for search. Maybe it’s not great on mobile. Maybe a hundred things… none of which are helping you move customers closer to a sale.
And when you ask about those things, your developer hedges. Or disappears.
The result? All of the above plus a hefty dose of misinformation that can confuse you about what you should or shouldn’t be doing.
What’s The Solution?
If you want to feel more confident in your selection of a designer or developer, educate yourself first.
And use these tips to prevent the next nightmare scenario from belonging to you.
Register your own domain name. Never – and I mean never – allow anyone else to register your domain name to themselves. Your developer can help walk you through the process or even make the purchase for you but it should be using your business, contact and billing information. The last thing you want to do is build a brand and get into search results with a domain you have to abandon when your developer abandons you.
Know where your site is hosted. All you have to do is ask. Then do a very simple thing and Google the company where you learn that your site will be hosted to be sure it’s legitimate and reputable.
Ask for business credentials. How long has your developer been in business? Is it a legitimate business or a part time gig? Don’t be afraid to ask tough questions like, “Where were you five years ago?” and, “Where do you see your business five years from now?” Get satisfactory answers and be sure you’re working with someone who is a professional in the industry, not a sometimes-accountant with the latest “Become A Web Developer In 21 Days” book.
Ask for references. You should be able to talk to at least three current clients who are not related to your developer (ie: not her brother, mom or boyfriend). Ask about the relationship, your potential developer’s responsiveness and results.
Ask about qualifications. You should have reasonable reassurance that your developer has the experience and training to meet your needs. If you’re working with someone who is new to the industry, be sure he is competent enough to do what you need and smart enough to know when to call in outside help. Whether fresh to the business or seasoned professional, look for someone who speaks to you transparently about his knowledge and limitations.
Get a good referral. If you have a friend or colleague who can point you to a reliable developer then that’s a big plus. Still, be smart and ask about the important things like qualifications, experience, accessibility, reliability and results.
Look for a blog. It takes a lot of trust to hand your money and the fate of your brand and web presence over to someone else. Unless you get a stellar recommendation from a trusted friend, it can be tough to build that kind of confidence after one or two or even half a dozen phone calls. But if your potential developer is consistently blogging, reaching out to her community, educating and helping, there’s a much better chance you’re dealing with someone legitimate – and dedicated.
Stop looking for the cheap way out. Budgets are tight. And if you’ve been burned before then your budget is that much tighter. But when it comes to your website, there’s too much riding on it to price-shop and base your decision solely on cost. That doesn’t mean you need to choose the most expensive option but it sure does mean you should avoid the cheap one. Of course, you may be working with someone new who is pricing low in order to gain more experience. That’s ok, just be sure you know what to expect and be sure you’re still asking the right questions about availability, reliability and capability.
Never start a conversation by talking about design. If the first thing your potential developer asks about is how you want your site to look, that’s a good sign to back away. A conversation should always – and I mean always – start, end and revolve around your business needs and goals. Good design grows from that but is never the starting point or end result.
Get it in writing. No matter how happy you are with someone, how qualified you think he is or how much of a glowing recommendation he comes with, you always want a basic contract in place. Be sure that you understand what you’re paying for and what you can expect. Understand the caveats and limitations. Understand the payment terms and timelines. A contract exists to protect both you and your developer and define the parameters of your relationship.
It’s no fun to enter into a business arrangement, spend your hard-earned money, invest time and energy and end up with nothing – or worse, lose credibility, customers and your brand reputation.
So be smart and learn to recognize the signs of a good developer vs. someone who is going to leave you high and dry. Start with these tips and then question, question, question everything.
Have you had a bad experience? Are you thinking of hiring someone and feeling doubtful? Let me know so I can sympathize – or help.
Join the discussion 3 Comments
Great article- I’ve come across very similar stories before, especially the first 3! In fact we’ve received quite a lot of business from clients who had websites built by part time developers who couldn’t deliver or went dark.
The whole contract issue is an interesting one. I know many web developers and designers who don’t bother with them. It got me thinking, are they really worth it at the end of the day? If a client doesn’t pay or give you the content to build the website, then is a contract going to help? I do think having a contract looks professional but how useful are they? Have you got any tips on how to write one? Do you have a standard contract for all your clients?
You say Register your own domain name. Actually I find it frustrating when clients register their own domain name, because it then becomes difficult to get them to update the DNS. We always register and manage our clients’ domain names, but we ALWAYS set the registrant (owner) as our client. We make sure that our client knows the domain belongs to them but that we manage the billing and technical side of it. That also ensures that the client can easily move the domain name away from us.
Ah contacts! We had a long, painful one that we used for a while and that was a nightmare. Nobody understood it, not even us (we had an attorney write it).
So we ditched it and went with “this is what we will do, written in English”. And as we went along we added more stuff to it to clarify expectations and payments and things like that. Although to be fair, we mashed together a contract and project agreement into one. Most times it doesn’t boil down to a legal need but a practical one. When the client gets snarky about what you should be doing/delivering, you can say “here is what’s in our contract”. That’s usually enough to mitigate the sticky stuff. In most cases a written document helps guide the project along and you can pull it out and point to it if things go sideways.
We have recently gone back to a legal contract – though a much, much more simplified one – for some practical legal reasons, too. If someone fails to pay, you can pursue the mater legally but that could be more of a nightmare for you unless you have certain legal protections in place. There is value in having it clearly stated “this is what we do, this is how we get paid, this is what happens when we don’t.” And depending on what type of business you do, things about confidentiality and non-poaching. So yes, legalese, but the type that is meant to protect you if things go very, very badly. It does make a difference if you ever need to take legal action to collect a debt.
It also makes a difference psychologically. Anyone who won’t commit to something in writing is probably trouble. It should be clear what to expect and both parties have to agree. It creates a structure to what you’re doing as opposed to an open-ended situation.
As for our project agreements, those are more specific to the actual project. Milestones, more specific expectations and timelines, payment plans, features included/not included. We write those ourselves and use a “template” that we have built over the years based on “stuff we should have included sooner to make this project go more smoothly”.
On another note, I think it’s fine if you do the physical registration of a domain name. The important thing is that it’s in the client’s name. We have login access to most of our client accounts (unless they have an internal IT department) so that’s not a problem. We also do not like to manage their billing because that assumes you will pay for their domain and they will reimburse you. Also can turn out not so well. No need to be a clearinghouse for their expenses!
I’m thinking we should probably chat, lol. We could write about this all day 🙂
Great stuff! I love the point about it being great “psychologically”- I can get on board with that one. I can also very much get on board with having a legal contract written in simple English. For me that is key. It needs to go through what you are delivering and the expectations in a way that the client will understand. It needs to be easy to read and even fun – just like a blog post. Getting the balance between simple English and being legally binding is hard, at least that is my assumption.
Yes, we should chat. Maybe a Google Hangout sometime! 🙂