Blake Callens is CEO of online publishing startup PencilBlue and co-founder of the Raleigh Entrepreneurial Acceleration Lab, a non-profit incubator with the mission of creating profitable, self-sustaining, technology startups in the Triangle. He is a DEMOgod and Webby award winner, and writes regularly on the subjects of software startups and UI/UX development.
One of the most common stories I hear from founders is that of the wayward software development contract. It’s so common that the top post on the entrepreneur subreddit last weekend was from a business owner who is missing a sales cycle because a contracted project went late.
On the other hand, the sentiment from contractors about unreliable clients isn’t any better or any less deserved – it has even inspired its own parodies.
I’ve been on both sides of the issue. Contractors I’ve hired have missed deadlines and attempted to charge multiples on the original estimate, even when the project parameters never changed. I’ve also been the contractor, with clients who were never satisfied, couldn’t stick to the plan, and expected their every whim to be accommodated at no additional charge.
With all the things that can go wrong, trusting a complete stranger with the development of a company project can be rightfully frightening for any client, or contractor for that matter. While there’s no sure-fire way to prevent a contracted project from going awry, here are four things you can do as a customer to lower the risks.
Know exactly what you’re looking for and stick to it.
The most common reason for contracted projects going over time and budget is the client changing requirements during development. Every contractor has a story about a customer who couldn’t make up his or her mind and was always changing the project’s scope. A common theme in these stories is the customer not understanding why adding unplanned functionality to the program raises the price.
Indeed, some contractors make their living by feeding off this type of situation. A client that’s never satisfied is more likely to pay for a monthly retainer after the project is delivered. That client is also less likely to be technologically savvy and can be more easily convinced to sign up for extra services that the contractor profits from, like a managed hosting plan or technology consulting services.
This isn’t always a bad thing, especially if you have no idea how to manage software. But a lot of money can be saved if you focus your needs and learn a little about the technology you’re ordering.
Start by defining the requirements of the project, then sleep on them. Don’t hire a contractor until you know exactly what you want developed, and make sure it’s in the statement of work that you sign.
Then stick to the plan. If during development you realize that you want to add something, save it for phase two or expect to have to pay more and wait longer for the final product. Nothing will kill the motivation of a contractor and threaten a project more than the client asking for free additions to a program or not allowing for a properly-adjusted timeline.
Remember that you are purchasing the technology, not just the services. Always retain control of the source code. You should have complete access to any code repository (a place online where the source code is stored and updated), and you should be able to move the software to another developer at a moment’s notice and for no additional charge.
Accept that a contractor doesn’t care about your company’s success.
You obviously care about the success of your business and, therefore, the success of the software being developed for it. But contractors have own business to worry about. That means meeting defined requirements, getting paid and nothing else.
Don’t expect the contractor to get involved in your business like an employee would (you should actually be wary of contractors who attempt to do this). They’re vendors, just like any other, and are looking to close sales. This is why it’s extremely uncommon to find a successful software company that contracted the development of its core product.
Initial software design and development, more often than not, requires rapid engineering and changes on the fly by a team that has a stake in the company’s success. When your development team is divvying up time between multiple clients or constantly has one eye on a future deal, that type of focus is impossible.
The results of contracted website and application development can be great, just don’t bank the success of your business on it (like that redditor did).
It’s okay to off-shore development, but know what you’re getting into.
There’s no quicker way to lower the cost of a project than having it developed overseas, and there are plenty of local liaisons that will manage communications between you and developers in places like South America, Eastern Europe and Asia. There’s a reason this development costs less though.
Software developed in low-cost locales is almost always of a lesser quality than programs engineered in North America, Western Europe and Japan. South America is catching up, though, and I would generally recommend it over other offshore locations.
The lower quality of applications developed overseas is not primarily due to the quality of the developers, but because of the quick turnarounds needed for such low-cost implementations to be profitable for the development firm. The firm’s margin shrinks even more if the stateside middleman is an independent contractor taking a cut.
While there are plenty of legitimate businesses managing offshore development, when programming teams are in developing nations, you need to be more on your guard for less than savory business practices. For example, an offshore development firm once personally offered me ten cents on every dollar itearned if I convinced the company I worked for to use their services – a practice more commonly known as embezzlement.
Applications developed by low-cost, quick-turnaround shops are often hastily thrown together and rarely scalable. Nothing will be built to accommodate features not clearly defined in a functional design document – there’s no room for interpretation. Even a microscopic change to the plan will cost you. That doesn’t mean offshore development is always a bad decision, but it should be reserved for well-thought-out implementations that will either never need to be upgraded or can be completely scrapped for a new version when you have the budget.
The differences with software developed offshore don’t only apply to what’s behind the scenes either. User interfaces are cultural, just like any other form of communication. User experiences designed and developed overseas can be like spaghetti Westerns, where everyone is playing an American, but you can tell some things are a little off.
Experienced interface designers and developers can look at an app or website and immediately tell if it was designed overseas. Your users might not know, but they’re more likely to get frustrated with interfaces that don’t fully match their expectations. For the best results, have your application interface designed locally.
Penny pinch now and pay for it later.
The biggest difference between a discount contract and a full price one is that you’re likely to make more money with the full price product. A well-designed and maintained retail store is more profitable than a hole-ithe-wall, and there’s no difference when the physical location moves online.
We’re all visual creatures who are more likely to be trusting of transactions when the showroom is pleasing to the eye and our experience is one of comfort. You wouldn’t hire a merchandiser for a store based solely on who gives the lowest bid, so why would you do it with your client-facing software?
This is not to say that the highest bidder is always the best producer. Some of my worst contracting experiences were with big, expensive firms, and some of my best were with freelancers who gave me a great price so they could expand their portfolio.
Do your homework and give yourself enough time to find the right fit. Always ask for a portfolio and references. Walk through the project, step by step, with every prospective contractor. And be wary of anyone who is overconfident or too unsure and repeatedly talks about things being “only estimates.” Take the median of all the estimates and multiply it by 150% to get a good ballpark for what a solid implementation will cost you from a responsible contractor. If that’s too much, then cut back on your scope, not on your quality.
Follow these tenets and you’ll have a much better chance at success when contracting software development. If you have any questions on these methods, feel free to reach out to me in the comments or on Twitter at @blakecallens.
