I recently passed my 1 year mark building Buink Web Development and thought it is about time to address one of my biggest competitors: offshore development. 🙂

I say competitor, but I honestly don’t see it as that. Looking to the future, I hope that offshore development is my friend, not my enemy. In fact, I don’t think you’ll still be alive in this industry in 20 years if you don’t learn to leverage offshore resources (unless offshore is also made obsolete by artificial intelligence, mu ha ha ha!).

I hope that offshore development is my friend, not my enemy.

That said, offshore development is not for everyone. In this article, I’ll share some of my experiences, list the pros, list the cons (including some solutions to counter the cons), and make some recommendations to help you make the most of your development dollars.

Here is how this article is broken out:

• Pro: Come on Down, The Price is Right
• Con: Their Timezone is Sleeping On the Job
• Con: Lost in Translation
• Con: Spaghetti Code
• Con: Stolen Code
• Solution: Make Offshore Work

Pro: Come On Down, The Price Is Right

The low price of offshore development is the only “pro” that comes to mind. There may be more, but I can’t think of any.

I’ve met and interviewed lots of developers (offshore and on) and, its true, most offshore developer costs less than onshore developers. No surprises there, in fact, some charge quite a bit less; for example, the lowest hourly rate I’ve seen is $9. That is cheap! Imagine, a highly skilled developer in a distant land making less than we pay people at McDonalds. Nine dollars, however, is unusual, the range I’ve seen is from $9-$60 and the average is about $25.

“The only ‘pro’ that comes to mind is low price.”

These rates sound great, but are they too good to be true? They can be if you’re not careful.

Con: Their Timezone is Sleeping On the Job

When you’re trying to move at the speed of business, you’ll quickly realize that having a 5-12 hour delay in communication can really slow a project and even waste money. When you’re asleep, your developer is awake and vice versa.

I’ve seen the following two scenarios many times. You wake up, rub your eyes open, grab your mobile phone, and review the developers work from the night before. You realize they spent the whole day going down a “rabbit hole” of misunderstanding. You send an email clarifying something they did wrong. They wake up 12 hours later and respond with a question, which you don’t see for another 12 hours. The cycle continues! Work stops for multiple days and time is lost. Or, worse yet, they don’t clarify and spend another 8 hours going down another rabbit hole.

This cycle isn’t a product of the distance between lands. The internet and new technologies like Google Hangout, Slack, Trello, Basecamp, and others have virtually eliminated the distance between two points on planet earth, but the timezone barrier is still a serious issue.

I experienced this problem first hand with a developer not long ago, I’ll call him Victor. Our relationship was already on the rocks because he was hard to communicate with and he missed a small deadline. I gave him a second chance with a small project. I expected him to return the code in two hours, but when I woke up the next morning I found that he had billed 8 hours and still hadn’t delivered the code. He had all kinds of questions and I quickly realized he was trying to make changes on the wrong code base. No wonder he was confused about my instructions. Had we been on the same timezone, he could have easily reached out and I could have followed up. Instead, he spent all night spinning his wheels.

“The timezone barrier is still a serious issue”

The only solution I’ve found to fix this con is to require the offshore developer to work in my timezone. They won’t always do that and sometimes they’ll make promises they don’t keep, but if they do, it will save you a lot of time and money. If they don’t, just consider your true cost of offshore development at something like $40/hr and not the sticker price of $25/hr.

Con: Lost in Translation

As I’ve said in previous articles, development specifications are hard to communicate EVEN to native English typers and readers. When you add in the language barrier, you may find it impossible to communicate.

Notice, I specified typing and not speaking. Speaking English is important, but if a developer can’t type quickly, they can’t code quickly. It sounds simple, but it is often overlooked. Coding is typing; and typing in English will always be harder for non-native speakers.

Reading is also critical. Your developer needs to be able to easily comprehend the project specifications. In addition, they’ll need good reading skills to find help with bugs and features. When a developer hits a snag, a quick search of the internet often results in a solution. Most of the time, someone has written an article about a feature you’re trying to implement. If a developer can’t read and understand quickly, they’ll likely be re-inventing the wheel with every new feature.

The truth is, I’ve never met an offshore developer that types and reads as well as a native English developer, and even some native developers struggle. 🙂 You just have to understand that this is going to be an issue. The question is, how much of an issue. Are they twice as slow? If so, the true cost of offshore development is looking to be closer to $80/hr.

“Coding is typing; and typing in English will always be harder for non-native speakers.”

The best you can do is try to asses their English skills and avoid those who have trouble. You’ll realize really quickly if a developer is avoiding email communication and opting for conversations via Skype instead. This is a red flag. I try to force them to communicate everything via email and chat. If I notice some big grammar errors, the kind where you can’t even understand what they’re saying, then I usually don’t move forward.

In addition to screening their typing and reading skills, you must also realize that they’re going to misunderstand some things and they’ll waste money in the first or second rabbit hole. As you can imagine, things get out of hand very quickly.

Con: Spaghetti Code

I have yet to work with an offshore developer whose deliverables were significantly more valuable than that of an onshore developer. I’m not saying they aren’t out there, but I’m still on the lookout. In my experience (which isn’t trivial) they aren’t much cheaper.

For example, I’ve talked about the first project I sent offshore in earlier posts, but I’ll summarize it here again. It was a custom WordPress site. When I took over the code it was filled with all types of security flaws, they had hacked the WordPress core (making it impossible to update), and there was almost no structure/organization/architecture to the code. I’ve heard other people talk about “spaghetti code” and that is exactly what this looked like. From a user perspective, the site looked great, but from a developer perspective, it was a mess.

Even Victor, who I mentioned previously, delivered code (albeit late) that on the surface looked good but had to be re-coded in some aspects. Did his code add value to the project? Yes, but not without exception. Even though his rate was lower than my other onshore developers, his code ended up costing about the same or more.

“From a developer perspective, it was a mess.”

The only solution to this con is that you have to have an experienced developer review all offshore code. Just because it looks like it is working, doesn’t mean it is.

I’m sure I’ll mention this again, but I highly recommend you track code changes (via Git) and require all code changes to be packaged into small, feature related groups (called pull requests).  These pull requests should be reviewed by an experienced developer you trust (like an onshore developer you hire as a lead).

Con: Stolen Code

This con is only hearsay, in other words, I haven’t experienced it myself. I include it here because I could totally see this being an issue.

I was out to lunch with a client recently, we’ll call him Zuck. He had me act as a developer lead on a project with a short timeline. I brought in several contractors to speed up the process. I mentioned to him that one of the developers was from Kiev, Ukraine and he said he was glad that I wasn’t working with anyone from India. He told me how he’d worked with several in the past and questions their ethics. “Sometimes,” he said, “they’ll just hack someone else’s code and package it up for you instead of developing it themselves.”

I didn’t dig into Zuck’s claim, but I take his word for it. I’m not saying that India is somehow worse than anywhere else, but the rule of law isn’t the same in many other countries. The risk of getting sued by a client is drastically less for offshore developers than for us onshore. Offshore developers don’t operate under the same rules we do, and as a result, I can imagine there is less incentive to write honest code.

Luckily, the solution that prevents spaghetti code will also solve this con. Hire a developer lead like Zuck! I can’t stress it enough; you should require developers to track code changes (via Git) and package code changes into small, feature related groups (called pull requests). Then, have each pull request reviewed by an experienced developer.

Solution: Make Offshore Work

So, with only one pro and several cons, you may be wondering why I started this article hoping that offshore development would be my friend in the future. Well, you have to admit the price is very nice, if you can figure out how to prevent the cons.

Some of the cons are easier to solve than others. Timezone and communication issues are difficult, but through some trial and error with different offshore developers, most businesses can overcome these cons. Just be prepared to loose some time and money in the trial and error process.

It is, however, much harder to asses coding skills, both before hiring and while on the job, unless you are a developer yourself. For this reason, I don’t recommend overseas development for anyone who is not a developer. There are just too many phonies. There are too many overseas developers charging high rates and delivering substandard results.

If you’re not a developer, the only way I’d recommend you use overseas developers is if you hire an onshore lead developer you trust. This lead developer will review all code changes, review progress based on the number of hours worked, and make decisions about the effectiveness of overseas resources.

“Hire a developer lead like Zuck!”

I have several clients, including Zuck, who use my services to lead a team of developers. Some have existing developers they’ve worked with for a while and they want me to take over and make sure things are going as planned. Others want me use developers I’ve worked with in the past. Either way, you’re better off letting me worry about timezone, communication, and skills assessment.

What do you think? I’m sure I missed something, so please share your comments below!

I’m creating this page mostly for me. I often find myself needing a git command I used one time a while back. The trouble with Git is it’s really hard to find a lot of the nuanced commands and there isn’t much written about them. When I find a command helpful, I’m going to record it here and attempt to describe when I’ve used it. I’ll start with one and add over time.

Branching

`git branch -rd origin/[branch name]`

We don’t clean up branches like we should! I’m including myself in this. Sometimes I’ll get on a new project, clone the repo, and type `git branch -v` to list all the branches and I get a 10 page list! That is where this command comes in. If you try to delete a local branch (`git branch -d origin/somebranch`) it won’t work. That is where the -r comes it. Use it to delete a local remote tracking branch that is cluttering up you branch list command.

It seems like everyone is looking for web developers these days.

Being a developer, I get lots of questions in these 4 categories: (1) my development skills, (2) my contractor rate, (3) my work location (on site or remote), and (4) my willingness to be an employee again.

My skills usually start the conversation and I’ve tried to make it easy to review them by project, skill, or client. In addition, I’ve already addressed my contractor rate in a couple articles: good development isn’t cheap and the importance of good development.

In this article I want to talk about #3 and #4: why every company needs a contract developer like me, despite the fact that I only work remotely and don’t want to be an employee.

Here is a quick list:

1. A contractor relationship produces high quality work
2. A contractor can be cheaper than a full-time employee in several ways
3. With a contractor, you only pay for billable hours
4. A contractor can fill in employment gaps
5. A contractor can offer help to meet deadlines
6. Contractors are great on projects with short-term needs and uncertain futures
7. Technology makes working remotely easy and transparent

Contractor Relationship Produces High Quality Work

Have you ever noticed how good the customer service is at the mom-and-pop restaurant near your house? Why is it so different than the drive-thru window at Taco Bell? For one, mom-and-pop know that keeping you happy keeps food in their bellies and a roof over their head. That ratty haired teenager at the window, however, couldn’t care less about your service, that is, unless his clip-board carrying boss is looking over his shoulder.

I’ve heard people say that you have to bring people “in house” to get them to really commit to your project/startup. Does commitment lead people to produce their best work? Our initial reaction is yes, but I’ve found an equally, if not more powerful motivator: mom-and-pop’s fear of not having someone to enjoy their sushi.

Or, in my case, my code.

If you’ve never worked for yourself, then you may not know the feeling that your work could end at any moment. This feeling is quite possibly the best motivator I’ve ever experienced.

This feeling leads me to constantly question if I’m providing enough and the right kind of value. To answer that question, I track my time religiously, meticulously, and at the end of the week I tally it all up (actually I use Toggl to do that) and review it. Then, I always ask myself, “Self, is this client going to be happy paying this?”

Luckily, the answer is yes most of the time. I absolutely hate the feeling of sending a bill when I wish I’d provided more value. I know that if this becomes the norm, I may not have food in my belly and a roof over my head.

I’ve experienced this feeling, to a certain degree, working for other people, but it wasn’t until I ventured out on my own that I experienced it deeply. I can tell you this, my work has never been so good.

Contractors Can Be Cheaper Than Employees

Most hiring managers realize that contractors don’t require benefits, employment taxes or payroll, on-boarding, or training.

Most managers, however, don’t realize that there are a couple other reasons why contractors are cheaper…

Think about it, you’re free to send me work (or not) at any moment. There are no string attached! There is no check that is automatically cut and put in my bank account.

My clients use my services only when they need them. This reason alone saves my clients thousands of dollars a year while not sacrificing the technology they need to drive their businesses forward. Quick bursts of work followed by pocket book silence.

Not only am I a resource for your team that can be engaged quickly, I also have my own equipment. I work with a state of the art workstation that I use with either a Mac or PC. I have an iPhone and iPad for testing and will soon be buying an Android. I sit in an ergonomic chair and have a standing desk. All stuff you don’t need to buy. 🙂

Just send me a link to your git repo and we’re running. Oh, and I don’t take up space in your office.

You Only Pay For Billable Hours

If you analyzed the number of hours an in-house developer is making you money, you’d probably find that even the best are only “on” 80% of the time. The other 20% is filled with pointless meetings, water cooler chatter, in office banter, and watching the latest cat video.

I’m not saying that these things are useless (except for maybe the cat video); I’m just pointing out something you probably already know: even though you’re paying for 40 hrs a week of work, you’re only getting 32 (if you’re lucky).

With me, you only pay for the portion of the 32 that you need.

Contractors Value Is More Transparent

Most employees balk at the idea of tracking their time. This makes it difficult to really understand which employees are effective and which are not. It also makes it difficult to understand how long features typically take.

Contractors, on the other hand, are typically very comfortable tracking there time (Buink is exemplary at being transparent with time tracked). This helps us weed out less effective developers and helps us drive progress more efficiently. Regardless of the type of project, the developer lead quickly gets a sense for how long things should take and who they should send them to.

Deadlines

Deadlines are often a function of business needs, not team resources. The truth is, companies live and die by deadlines.

That said, they aren’t always good for producing the best quality code. Sometimes, they cause us to make trade-offs that may not be desirable, like just making the code work rather than sculpting it into an eloquent piece of technology. That is not to say that deadlines are bad, they aren’t, but having a resource that can help you meet it effectively is valuable.

A good contract developer can be up and running on a project in hours, not weeks, and can provide you the extra man/woman power you need to meet the deadline and still produce quality, functional code.

If you could use some help from time to time, let’s do a small project together so when the deadline is looming, I can swoop in and help you dominate.

Employment Gaps

I remember when I got hired at one of my previous companies, they decided to add an employee because they were swamped. The problem is, they had too much work for three developers, but too little for four. It didn’t take long before the company had nothing for me to do. After a slow 3 months, things started to speed back up and then became overwhelming for a while before we hired again.

This cycle is a good example of the fact that, hiring is typically slow while business needs are urgent. So, companies go through periods of intense work before they hire and after they hire they go through a short period of too much labor.

Maintaining a good relationship with a contractor can help your team manage the periods of intense work longer. This means a happy team!

Short-term Needs With Uncertain Futures

One of the companies I’m working with right now, we’ll call them GameChanger, is bringing an old technology to an new industry. They’re in the beginning stages of their business and they have a limited budget. They could hire a full-time developer, but then they’d be burning cash every week even if their needs slow down temporarily. They’d also need to invest time making sure the employee had a full queue of projects.

Rather than hire, GameChanger reached out to me for some short-term help. I did a ton of work on their site over a two week period, creating a minimum viable product, and now they’re using it to pitch potential customers. They’ve already landed one. Nice work!

Contractors are ideal for this type of relationship. Rather than needing to manage a full-time developer they get quick bursts of work only when it is needed.

Technology Makes Remote Work Easy and Transparent

I’ve been doing contractor work since February of 2015. I’ve worked with about 18 clients so far and of those clients, I’ve met only a couple face-to-face. I laugh sometimes because I’ve never seen a couple of my best clients in person.

This type of work would not have been possible even 5 years ago, but the time has arrived. To make this work, I use all types of communication. Here are just a few (in order of frequency): email, phone, text, chat, hangout, skype. For managing projects, I use all types of software including trello, basecamp, jira, asana. I also use several code repositories: github, bitbucket, springloops. And finally, I use uxpin for wireframes.

These technologies increase the speed and accuracy of my communication.

Lastly, for transparency I use Toggl. I track every minute I work and send you a summary of my projects. This summary looks very similar to the requests sent and gives you a line by line breakdown of how your money was spent.

In my mind, over-communication is a good thing and I’ve received good feedback so far.

Conclusion

I guess I should answer the original question I asked. Who dominates, employee or contractor? Both. 🙂

As you go about building your team of stellar in-house developers, don’t forget that contractors can be a valuable part of your secret sauce.

I’ve been doing contract development long enough to know what the market will pay for my services and skills.

That said, I’m still surprised by people who won’t. They choose to go with cheaper, less experienced developers or overseas developers because of the lower rate.

Let’s investigate (dear Watson) why a higher rate may be cheaper in the end. Let me know if you think any of these reasons are off base.

Your Time is Valuable Too

I’ve been meeting on a weekly basis with a couple entrepreneurs to share business concerns and get advice. This week, one of the entrepreneurs asked our thoughts about hiring an overseas contractor to develop his first website. Another entrepreneur, I’ll call him Bob, shared the story of his first site. “I was surprised by how much testing I had to do,” he said, “by the end of the project I’d lost all motivation to even go forward with the business because testing was so tedious.”

I know exactly what Bob meant, my first site was the same. I literally had to test every button, every link, every hover state, every requirement, everything! I was blown away by how much stuff was missed. Catching these little details was expensive. Not only did I waste my time, but I had to wait for a fix when I should have been more focused on the overall business.

Developers eventually get better at catching problems, and no developer is going to catch every bug and every missing link, but these should be the exceptions, not the rule.

Foundation is Important

When building a house, you start with the foundation, add walls, and top it with a roof. When building a website, you start with the technology you’ll use (Node.js or Laravel backend, Angular front-end, SCSS, Grunt, etc.) then you build the overall architecture (folder organization, routes, etc.), and then you start adding the pages, snippets, plugins, etc.

Although it is a good practice to keep code independent of other code, a good foundation coupled with building reusable code snippets, directives, and plugins makes it easy to add functionality through the whole site without copying and pasting. This means fewer lines of code, which are usually cheaper to write and always cheaper to maintain.

A great example of code building on itself is CSS. A developer implements the design of the overall site (header, footer, H1 tags, etc.) that is reused everywhere. When you add styles to a specific page, you don’t have to re-design the header and footer, the page inherits the overall site styles and allows the developer to just tweak the design based on a page’s need. If the CSS foundation is weak, you’ll find that you have to add a lot of styles to a page that should have been added at the site level. More code, more money. Also, a future developer may want to go back and tweak the site level styles to save time in the futrue, but this is costly because every tweak to the overall styles means they have to test the whole site for bugs.

All too often, businesses neglect the importance and value of setting a good foundation. They’ll bring in a cheap developer at the beginning thinking they’re getting value. Later, when the site isn’t performing or is cost prohibitive to update, they’ll bring in a more experienced developer who usually calls for a re-write.

Lost in Translation

The #1 reason to work with someone who speaks native English is that code is hard enough to communicate without a language barrier.

I had a potential client reach out to me recently, I’ll call his company GameChanger. They had worked with a developer in Vietnam for a very low rate (about 1/9th my current rate) but they decided to find a local resource. Why? Because they had been loosing a lot of time and money in translation. In other words, GameChanger would ask for a change, the developer made the change thinking they understood, GameChanger would review the change only to find out the developer didn’t understand. Not only did the developer waste valuable time and money doing something they shouldn’t have, GameChanger wasted time communicating the change and reviewing it. Then, the launch date get’s pushed back and more money is lost.

This must happen more than you’d expect because I’ve had the same exact experience multiple times. Cheaper is sometimes more expensive.

Debugging is Hard

Sometimes things just don’t work like they should. What is worse is that many times broken code doesn’t explain itself. There is no substitute for experience. Books won’t help you because no one writes books about bugs; they just fix them, if you’re lucky. If you’re unlucky, you fix them yourself.

I remember in the early days of coding that debugging would sometimes take more time building. With experience, however, I’ve become exponentially better at finding the source of the problem. Killing bugs take both a solid foundation of the fundamentals of a language and real-world experience hunting them down.

You’d be surprised how much a trained bug killer can save you.

Half the Price vs. Twice as Fast

In the world of development, time really is money. With an hourly contract, which I highly recommend, the important question is, would you be better off with half the price or twice as fast? Think about that, which is better? They seem to be the same until you realize that fast also means less bugs, a better foundation, better communication, and faster debugging.

The learning curve for becoming a seasoned developer is slow but exponential. In the begining, we spend a lot of time just getting the basics of a language. The first time we write a function takes a surprising amount of time due to stupid mistakes. Stupid mistakes are the most challenging because no one writes about them; they’re too obvious to everyone but beginners. Soon functions become second nature and we start learning about objects. Later, we move into learning different libraries, frameworks, and packages. Many of the things we learn span the whole language and development in general.

It may take as much as 10 times as long to do something the first time as it does to repeat it; typically it’s about 3 in my experience. After years of experience, I’ve seen things take me 1/50th of the time it did in the beginning and the curve keeps going. In other words, an experienced developer can provide about 3X the value of a beginner and sometimes as much as 50X.

Again, sometimes a higher price is less expensive.

Conclusion

It is natural to want the most value when choosing anything, particularly a developer. Just keep in mind the counter intuitive truth that a lower rate doesn’t necessarily mean more value.

As a freelance web developer, the first question I often get from a new client is, “Can you give me a quote for X?” This is a great question and I usually give them a ballpark figure or refer them to this article: the price of a website.

These quick estimates are great for helping them make a budget, but they’re horrible contracts. Here are a couple reasons you may want to sign an hourly contract with your next web developer:

Estimates are Always Wrong

Estimates are always wrong. Yep, I’ve never seen one that is right. Ever. And that means that in hind sight, a fixed price contract will always favor you or the developer (likely the developer).

A fixed price contract will always favor one party.

So, lets say the contract favors you in the end. In other words, the developer underestimated the hours for your project. Hooray, you get some value for nothing. Right? Maybe, but take a second to think about your future relationship.

At best, your developer may bite his/her tongue and hope for future work from you. Even so, they’re not going to be satisfied with the deal.

They’ll likely try to negotiate a change in contract. This is usually my goal, although I’ve never successfully negotiated the full value of my extra work and am always left unsatisfied.

At worst, they may choose not to work with you again. That is bad for a couple reasons: (1) You’ve (no doubt) invested (or now wasted) some budget getting them up to speed with your project and business and (2) they’re now likely the most familiar person with your project and would be the most efficient person to perform updates and maintenance (lower cost).

Truth is, it only takes one or two poor estimates by a developer before they learn to either avoid a fixed price or overestimate hours. This is why fixed price almost always favors the developer.

A fixed price contract will almost always favor the developer.

This is true not because they want to rip you off, but because of the many reasons a project can go over budget: out of scope changes, bugs with existing platform, bugs with conflicting features, bugs with niche our outdated web browsers, etc.

When they overestimate, you loose. Regardless, one party always gets a bad deal.

Sending the Wrong, Strong Message

In addition to jeopardizing a relationship with your developer, it can also jeopardize the quality of your code.

The principles of good code as I see them are (in order of importance):

1. It works (happy client)
2. It is well written and readable (maintainable)
3. It is written with as few lines of code as possible (maintainable)
4. It is on time (speed)
5. It is under budget (price)

Some clients don’t realize that a fixed price contract moves #5 (price) well up the list in importance. The developer gets paid the same as long as it works (#1) and is on time (#4) regardless of how well written (#2) and how few lines of code they use (#3). For a non-critical project these incentives may be fine, but I highly recommend you think twice about it for more important projects.

Incentive is the key word here. If you know anything about psychology or economics, you know that incentives have a powerful affect on humans.

That said, most developers, myself included, are going to try to do what is best for you regardless of incentives; but a fixed price contract sends the wrong, strong message.

You Don’t Know What You Don’t Know

Of the hundreds of projects I’ve done, I’ve never met a client that knew everything they wanted from the start. They often have a really good idea, but as we dig into the specifics, things change. Always.

Web projects are in a constant state of flux. By hard coding a price (and by extension, a scope) you make it much harder to react to important and inevitable future changes.

Changes to a fixed price contract take more signatures, effort, time, and overhead. As a consequence, I’ve seen project deadlines jeopardized, important changes never get approved, and a lot of wasted time.

Not to mention how annoying it must be to hear a developer respond to your request with, “sorry, that change is out of scope and will have to wait till phase II.” And yet, that is exactly what you’ll hear unless the developer just bites their tongue and eats the loss. I mostly bite my tongue, but that hurts. 🙂

Alternative To Estimates

I’m not naive to the fact that clients need to have budgets. So, if you need to budget with an hourly contract, try this:

Take the rough estimate and multiply it by 130%. This is your temporary worst case scenario budget.

Estimate * 130% = Budget

Then, decide a max weekly hours you’ll allow your developer to work (without you giving verbal approval). Thirty hours is a good limit for a contractor, but it may depend on your project. Use the budget divided by the max hours per week to get the total number of weeks expected to work.

Budget / Max Weekly Hours = Expected Weeks.

Use your expected weeks to re-evaluate the budget about half way through and weekly near the end. At these times, you should definitely reach out to the developer and get their take on overall progress as well. As the project is winding down, you’ll have a much more stable number for what the project will end up costing and it will likely be under budget.

Start Small

If you’ve never worked with the developer before, start with a small project so you can make sure they work well with your team and their code is quality. If needed, you can hire another developer to QA their code and provide the other developer specific feedback (emphasis on specific!).

By the way, I read and respond to comments on this post, so feel free to speak up.

I  have an interesting power as a web developer, with mere words, I can give people a horrifying condition called sticker shock. If you’ve never felt it, imagine a mix of the feeling that someone is trying to steal your money and the feeling of disappointment when a solution to all your problems exists but you can’t get it.

Truth is, most people have no idea what a website really costs. They’ve heard stories of the wonders and affordability of hiring developers in distant lands OR they’ve seen the tech giants give away amazing technology for free and they think this stuff must come easy. I know because I was once a like them.

A question I often get is, “how much would it cost to build a site like [insert the name of a famous tech company]?”

When asked this, I realize that people usually aren’t thinking about the fact that these tech unicorns are created using hundreds or thousands of very pricey software engineers over long periods of time for millions of dollars.

I’ll admit that even the least tech savvy among us intuitively understand that technology is scalable, you code it once and then benefit an infinite number of times at very little additional cost. That said, the “coding it once,” usually comes at a high cost. Why?

Technology isn’t cheap because the value it provides is enormous. This will always be true.

So, pretty much every time I get the question above, I hesitatingly use my shocking power. Unfortunately, it sometimes ends the conversation, but that is what it takes to have happy clients in the long run.

They usually have someone else build the site for cheap and then come back to me in 6 months to fix it. Sometimes I can, sometimes I can’t. One thing is sure at that point, the client is in crisis mode, they’ve lost lots of business, they’ve wasted money on development, and it is a much less pleasant experience for the both of us.

Cost of a Website

In an attempt to reduce the sticker shock of my future clients, I’ve included some numbers below. The following estimates aren’t meant to include outlier developers; you know, the shops/freelancers that price themselves far above/below the general market for one reason or another. Typically, outlier developers have a very unique niche OR they are about to go out of business.

Here is a table of site developers (Dev Shop, Freelancer, etc.) and the types of sites I typically see (marketing, eCommerce, mobile, etc.). Keep in mind, prices vary widely depending on (1) the number of templates, (2) the types and complexity of custom functionality, and (3) the technology you choose, but these should give you a good idea.

*cms stands for content management system like WordPress, Shopify, etc.

The numbers above are attempting to approximate an average, but they should probably be ranges because, as I mentioned, websites vary greatly in price. For example, we’ve build custom marketing sites for anywhere from $3k to $40k. Sure, $15k is in the range, but your particular site could land far outside the average. Some other reasons the price may vary include: the number of unique pages or components, the complexity of the business logic, the complexity of the data needed, and any third-party integrations needed.

If you’re looking to get a more accurate estimate, feel free to reach out, we have a quick way of estimating projects that turns out to be quite accurate.

One other note about the table above. From an hourly perspective, you’d pay higher in the range if the developer specializes in the technology you’re working with and less if they’re willing to learn it. You’ll also pay a higher rate for more experienced developers because an efficient developer at a high rate can often outperform a slow developer at a low rate. Let me repeat this in a different way, you can’t compare developers based on rate, you have to compare output to rate.

So, who should you choose? I can’t answer that for you, but I can share some thoughts that may help you decide.

Dev Shop (or Agencies)

Although I’m not an expert on agencies, I did work for an agency for 2 years and while there I also worked for several other agencies. They are definitely the most expensive solution, but that doesn’t mean they aren’t right for your project.

Some of the increased price is due to overhead  and some is a premium you pay for strategy, experience, and speed.

Shops often do great work. The code you get is usually well written and eloquent and you can bet they won’t start on your project and then just disappear a month later. They also offer a cohesive team, all focusing on your project, which can reduce some of the risk of launching a new technology.

The only real downside to working with a shop, besides price, is they’re less invested in your project. The developers see hundreds of sites like yours a year and the minute your project is done they move onto the next.

A lot of people ask me if Buink falls into this category. We do call ourselves a dev shop, but our business model makes us more like a group of freelancers.

Freelancers/Independent Consultant

An established freelancer with a good portfolio and a work history will offer many of the same benefits that a shop will. The difference in price is because they typically have very little overhead and are not necessarily profit driven.

A good example of having less overhead is the fact that freelancers typically don’t have project managers as middle man. They talk directly with the client which saves time and reduces communication gaps. In other words, the client doesn’t have to pay for the project manager to learn what they need, then pay the project manager to communicate that to the developer.

Freelancers are also more invested in your project. You’re not just one of the many clients, you’re one of the few. Through time, they become invested in your business and have more personal incentive to do good work.

Hiring a freelancer may not be all kittens and memes, however, there can be some downside. Freelancers typically have less bandwidth than a shop and it may take longer get to market.

Also, freelancers generally have less credibility than a shop. Sometimes they’ll take on work they can’t complete and they may just disappear on you if they don’t like the project. Make sure to get good contact information for them just in case you run into a problem down the road.

As I mentioned above, we consider ourselves at Buink more like a freelancer than a dev shop, really we’re a hybrid that overcomes some of the issues of both.

Read more of the benefits of working with contractors/freelancers.

Overseas

Hiring an overseas developer is one of the cheaper options. The price is an obvious plus and if you can find the right developer, you may have no problems at all. Unfortunately, this isn’t my story or the story you often hear.

In 2011, I outsourced the initial development of one of my startups. At the time, I didn’t think I had the experience to build it myself and I didn’t have the time.

I contacted some local dev shops that all quoted the project at ~$25k.

I experienced a little sticker shock myself.

My budget was significantly less than that, so I found a company that worked with developers overseas and they quoted me $5k. The site took forever and ended up costing $10k. Looking back, I’m not surprised. Tech often takes longer and costs more than the original estimate whether you use overseas developers or those near home.

When I finally got access to the code base, I had more shock than just sticker. The site didn’t meet my specifications, it had ton’s of security flaws, and it had misspellings in functions and variables names that were very difficult to correct. In addition, it was very difficult to communicate with them. In short, I got what I paid for. If I had more capital and time, I would have re-written it from scratch, but I just had to go forward with it.

This is a huge reason to decide early how much you want to invest in your website. If you decide to go with cheaper options thinking that your website isn’t a big part of your strategy, you may have to totally re-write your site if that changes.

I have friends who swear by working with developers overseas but, in my experience, they are the exception rather than the rule. Also, checkout this article I wrote about the pros and cons of offshore development and what you can do about them.

Beginners

Everyone starts somewhere. If you find a diamond in the rough, you may want to invest in the person long term. They’ll start out slow and their code won’t be great, but it will probably work as long as you don’t start growing gangbusters.

Do-It-Yourself-ers

You may have noticed that I didn’t include the cheapest way to build a website in my table above, building it yourself. Technology to help you do this will typically cost you under $200 and a lot of your own time.

I was once in this group myself. I built my first website with a builder (Web.com), my second website on an open-source platform (Magento), and I currently own an eCommerce necktie site on Shopify. Today, there are some pretty credible platforms that help you build a decent site with no knowledge of code: Shopify, Bigcommerce, WordPress.com, ect.

These sites are great for getting started, but if you want to keep growing, your customers are going to expect a more professional, custom looking web presence.

In Conclusion

The price of a website is usually shocking. There are different options, but they all come with trade-offs.

I had a conversation last night with a good friend and very successful business man (I think he’ll be a billionaire some day, seriously). He told me how he worked for years with a freelancer at $70 an hour. He was happy with the work but then brought in a more experienced freelancer at $120 an hour. He found that the more experienced freelancer could do the same work 3 times faster and deliver better code. Turns out the more expensive developer ended up being cheaper.

Hope you enjoyed the read! May the price of your next website be a little less shocking.

The news in my life is that I recently accepted a job at Voltage, a digital advertising and design firm in Louisville, CO. I’m way stoked about this next phase of my career. Like I said in a previous post, I want to get some solid coding under my belt and then who knows.

I’ve been extremely impressed with Voltage. Not only are they good at what they do, but they are amazing people as well. Shortly after starting on the Oktoberfest project I was talking with Erik Fowles, the CEO and Creative Director, about how he grew the business (an obvious question based on my passion for entrepreneurship) and what was their strategy for success. I was impressed by a story he told of doing the right thing for clients. Voltage had purchased an image license for client project. The licencer, who shall remain nameless, then went after the client when they unknowingly continued to use the image after the license expired. Despite the fact that Voltage was in a very difficult financial position at the time, and the project was long over, they took care of the problem.

That story reminds me of a quote that was shared at graduation. Warren Buffet said, “Somebody once said that in looking for people to hire, you look for three qualities: integrity, intelligence, and energy. And if you don’t have the first, the other two will kill you. You think about it; it’s true. If you hire somebody without [integrity], you really want them to be dumb and lazy.” I think the same is true of employers and partners.

I couldn’t be happier to join the Voltage team next week. It really has all the things I love boxed up in one company: development, digital marketing, design, opportunities for growth, and great people.

Our goal is to build the dev team over the coming months and years. I bought into this strategy because I see the value of combining high end design with high impact internet technology. Too many businesses and startups lack good design and we’re looking fill that need and be a resource to the Boulder community.