Home > Founder Friday > Don’t be a pushover with outside developers

Don’t be a pushover with outside developers

Founder Friday is a weekly guest post written by a founder who is based in or hails from the Silicon Prairie. Each month, a topic relevant to startups is presented and founders share lessons learned or best practices utilized on that topic. December’s topic is outside development. 

About the author: Ben Anderson is the founder of Bandwidth Pool, a startup based in Cedar Rapids, Iowa. 


When I set out to create Bandwidth Pool, a complex online bidding website, I knew I wasn’t going to be able to do it alone. I don’t have any practical experience designing, developing or generally understanding the components that comprise a complex web application. Because of the lack of programming experience, outsourcing the build of my website to a development firm was the best option.

I expected that if I found a firm that seemed competent and earned my trust, I would be fine. However, reality couldn’t have been further from my expectations. I chose and contracted a firm that fit my naive requirements for a web development team and started a year-long journey that had no end in sight.

After employee turnover, repeatedly missing deadlines and empty promises from the firm’s management, I didn’t know what to do. I was over budget, a year past the original deadline and my “finished” web application didn’t even work correctly.  

I decided to hire three separate code audit firms to sort through my web application and see if it was salvageable. The site had absolutely no documentation, it was built in a highly non-standard fashion and any attempts to repair or add to the site caused widespread complications. Coincidentally, all three firms provided me with the same two recommendations: try to document this unique application or start over. I’d be lying if I said the thought of giving up didn’t cross my mind.

I made the decision to start over with a new web firm and, in the process, learned a lot about how to best work with an outsourced web development team. Here are a few tips to help you avoid the problems I ran into:

  1. Don’t be a victim. A highly respected mentor of mine once told me, “Don’t ever be a victim.” Statements like, “I can’t be successful because of something or someone else’s shortcomings” transfer your power to be successful to someone else. “Be accountable for every action, decision and outcome.” In my case, that included transferring the accountability and blame away from the development firm and back to me. I had the power to find a better relationship and ultimately it was my responsibility to become a better, more educated consumer.
  2. Become a better, more educated consumer. I made an extremely important, difficult and expensive decision without all of the facts. I will never be an expert web developer, nor do I have the desire to become one. That doesn’t mean I can’t obtain a basic level of understanding on the complex development aspects of my project. The Internet is full of great (and credible) resources to help you learn more about development. I highly recommend resources like Khan Academy, Tree House or Udacity. Steve Huffman, co-founder of Reddit.com, has a great web development course on Udacity for free.
  3. Don’t go it alone. It’s not wise to make important decisions without advice from an expert. If you’re not a lawyer, you’re not going to represent yourself in a court of law alone. If you’re not an expert at web development or database architecture, you shouldn’t represent yourself to your development firm without an expert either. Find someone you trust who only has your best interests in mind—pay them if you have to. Have your expert evaluate the more complicated aspects of the firms you are evaluating: their proposals, site design and coding techniques.
  4. Check your site code. Check it often. Contract an outside code auditor to check in on the progress and technique of the code being written to enforce best practices. Based on the pace of your project, schedule regular meetings with the development firm, code auditor and yourself to identify and address any concerns the auditor uncovers.
  5. Don’t be a pushover. Be on the look-out for “red flags.” When I look back at the 18 months spent with my original development firm, red flags were all over. When you see them—and I can’t stress this enough—don’t be a pushover. Confront your development firm immediately with your concerns.

Here are a few questions to ask yourself as you try to uncover any potential problems with your development firm:

  • Does your firm exhibit project transparency with you throughout the process? In my case, when I asked to learn more about some of the more complicated aspects of my project, I was told, “These are areas we are in charge of. You don’t have to worry about them. We will take care of them for you.” Huge red flag.
  • What is the workload of your developer or development team? If you have a dedicated team within the firm, you’re off to a great start, but realize that you’re the exception, not the rule. What other projects does your team have on their plate? What priority has management placed on your project over the projects of their other clients?
  • Do you see any employee turnover within the firm? Employee turnover can be one of the best indicators of how a business manages itself and its employees. If employees are constantly leaving the firm for better opportunities, that can be a great indicator of employee happiness, quality of management and the overall culture of the organization. If not handled correctly by the firm, turnover also can cause disruption for your project, leading to delays or inconsistencies in your site code.

If red flags don’t seem immediately apparent, invite your development team out for beers over the course of your project (without their manager, if possible). It’s not only a great way to develop a sense of comradery between you and your team, it can be a great way to learn, first-hand, what pressures your team is under and how they may affect your project.  

Luckily for me, I found a silver lining in this situation. The negative experience with my first firm helped make the experience re-building Bandwidth Pool with my new firm much more successful. I’m a much better consumer this time around and have found a firm (Folkhack Studios from San Diego, Calif.) that’s doing a great job with my project!

 

Credits: Photo courtesy of Ben Anderson.