12 tips to make it cool to outsource your development

Recently I wrote a blog post: 6 Reasons why outsourcing development sucks for startups  and it’s only fair to swing right back there by playing devil’s advocate: so here’s 12 tips to make it cool to outsource your development (yep it can actually be cool!).

There are some fundamental requirements that need to be established before you jump right in there and outsource:

1. You’ve managed external resources before and know what to expect as well as how to manage them

2. WATER-TIGHT NDA’S and NON-COMPETES!!! Like tighter than a duck’s @rse.

3. NEVER work on a per/hr basis. Do your own functional spec and get them to quote on each module plus supply deadlines that have penalties for each day it’s not delivered  bug free and live. Any errors or fixes are for their account.

4. Insist on pixel perfection – i’t not acceptable that an image or banner is a pixel “here or there”.

5. Be prepared to manage them – it’s a total myth that outsourcing requires no management. Management can frustrate you and drive you nuts.

6. Never pay upfront. You will feel like you’re over the barrel. Roger. PAY ON DELIVERY (see point no. 3)

Okay! That’s 6 – halfway there!

Outsourcing for Dummies - the presidential edition

Let WW educate ya on Outsourcing!

7. Remember it’s a privilege for a contractor to work on your project – if they don’t feel that, they’re not the right fit.

8. YOU MUST KNOW THE FUNDAMENTALS OF DEVELOPMENT and, even better still, be an engineer yourself that can vet the code that get’s created.

9. Check their previous portfolio. Find a great fit. Find people who have coded in the language you’re working with. They need actual experience. eg:  having worked in PHP does not mean they understand CakePHP. Don’t ever let them tell you: “We’re really competent and will figure it out / all the principles of coding are the same”

10. Interview their previous clients

11. Insist on itemised billing so that you know who is working on your project and how many hours they spend on each module. Especially with overseas outsourcing companies, they will allocate a 2 year xp engineer and tell you that the resource is being carefully managed by someone more senior or that 2-4 years is a senior coder for them. That’s just bullshit. They will pay that resource some chump change and pocket the substantial difference as the bozo bumbles his way to workable code that can never be scaled easily.

12. This leads me to the next point: Vet the entire team working on your project.

The last thing you want, is to outsource the development to a firm that doesn’t produce to specification or standard. Remember that you’re in control here. They work for you.

The best scenario is when you’re a technical co-founder and are able to vet the code the outsourced team generates. Being a techstar means you know which areas of code are precious and which are churn – you outsource the churn. You’re also in a position to know when people are telling you rubbish or just crap at delivery and incompetent.

So those are my 12 tips to make it cool to outsource your development – do you have some of your own? Share them – I would love to learn and hear more.

Eran Eyal
Eran Eyal
Eran is the founder of StartupHat, Springleap, Evly (acquired), iDea (acquired), eSquared (acquired).

11 Comments

  1. I’d like to provide some different thinking about outsourcing. I read your two posts, and I guess you must have had some really bad personal experience with outsourcing. Your second post is almost as negative as your first post. Could you share some of what happened to you along the way?

    I will make comments on your points:

    1. You’ve managed external resources before and know what to expect as well as how to manage them
    >>You should be prepared to manage a software project whether you do it in or out of house. But many startups don’t have people with background in development. Do some homework and understand the Agile methodology before interviewing outsource companies. You need to understand it or you will have trouble.

    2. WATER-TIGHT NDA’S and NON-COMPETES!!! Like tighter than a duck’s @rse.
    >>NDA’s are extremely difficult to enforce. So are non-competes. I use them myself, but I also understand that to enforce any agreement, I have to be prepared to pay the legal experts to enforce it. There are no easy guarantees, but the more you check the reputation of people doing your code, the better. And think about it – what if you hire some people here and they quit? They can steal your ideas and compete. The problem will be just the same.

    3. NEVER work on a per/hr basis. Do your own functional spec and get them to quote on each module plus supply deadlines that have penalties for each day it’s not delivered bug free and live. Any errors or fixes are for their account.
    >>I actually agree – hourly can be tough. Outsource companies don’t really like hourly either. The accounting is extremely difficult. You should be wary of companies with extremely low rates. Sadly, they are the companies that tend to “run the clock” and make things more expensive in the end.
    >>Here’s where I disagree – deliver working product yes. Bug free? Sorry, there is no bug free software on the planet. Major flaws and non-working system, definitely not acceptable. But you have to be realistic and careful about terms. 100% bug free is not realistic. Should the company fix all problems at their expense? Probably. It goes back to picking a company with top quality engineers so they don’t have to do tons of extra work to fix problems.
    >>You also have to be extremely organized and prepared with exact specs. If you make any changes (and you will), then you have to be realistic and understand stuff will break.

    4. Insist on pixel perfection – i’t not acceptable that an image or banner is a pixel “here or there”.
    >>Same comment. “perfection” should be realistic. It doesn’t mean to accept crappy work, but if you are expecting something with zero flaws, you haven’t been doing software before.

    5. Be prepared to manage them – it’s a total myth that outsourcing requires no management. Management can frustrate you and drive you nuts.
    >>This is absolutely true. Outsourcing is augmenting your team. If you expect something to get done while you sleep and it will magically appear, you should not do outsourcing.

    6. Never pay upfront. You will feel like you’re over the barrel. Roger. PAY ON DELIVERY (see point no. 3)
    >>Never is a long time. You should expect to pay up front with at least 50%. Why? Because sadly there are many, many startups who get projects started and then just decide that they aren’t going to pay for part of the work. This happens extremely often. Plenty of startups decide they “deserve” a discount and just help themselves by deciding not to pay. It really goes back to selecting a team carefully and having a good working relationship.

    7. Remember -it’s a privilege for a contractor to work on your project – if they don’t feel that, they’re not the right fit.
    >>Sure, it should be a privilege to have a good project. But if you treat people like servants, you will not inspire them to do good work for you. Think how you would react to this statement. If you were told by a (Chinese / Indian / Russian / Brazilian…) that their idea is so great that it is a privilege for you to see it, would it make you interested or turned off?
    Just try not to be arrogant while you are providing the privilege. People like to be respected, even if they are serving you.

    8. YOU MUST KNOW THE FUNDAMENTALS OF DEVELOPMENT and, even better still, be an engineer yourself that can vet the code that get’s created.
    >>This is a really good point, mentioned above. If you know nothing about software development, it is very hard for outsource firms to help you.

    9. Check their previous portfolio. Find a great fit. Find people who have coded in the language you’re working with. They need actual experience. eg: having worked in PHP does not mean they understand CakePHP. Don’t ever let them tell you: “We’re really competent and will figure it out / all the principles of coding are the same”
    >>I completely agree with this. Previous work is good. And don’t just look at a website someone built. You have to talk with the customer and find out how the process went. Find out what really got built. Appearance of a website doesn’t tell much.

    10. Interview their previous clients
    >>Definitely.

    11. Insist on itemised billing so that you know who is working on your project and how many hours they spend on each module. Especially with overseas outsourcing companies, they will allocate a 2 year xp engineer and tell you that the resource is being carefully managed by someone more senior or that 2-4 years is a senior coder for them. That’s just bullshit. They will pay that resource some chump change and pocket the substantial difference as the bozo bumbles his way to workable code that can never be scaled easily.
    >>My goodness, such bitterness. Yes, this does happen. It’s worth getting to know who is building your stuff. Hourly itemization is really hard to do accurately. The really good outsourcers tend to work at all sorts of hours, just like Silicon Valley people. The good ones don’t just sit down at 8am and work to 5pm and then punch out. They work odd hours. They work at home. They test stuff and try out things. So it’s not so much the hourly billing as the relationship. You need to know your team. See next point.

    12. This leads me to the next point: Vet the entire team working on your project.
    >>Definitely. Frequent communication with the team is smart. Skype is cheap.

    The last thing you want, is to outsource the development to a firm that doesn’t produce to specification or standard. Remember that you’re in control here. They work for you.

    The best scenario is when you’re a technical co-founder and are able to vet the code the outsourced team generates. Being a techstar means you know which areas of code are precious and which are churn – you outsource the churn. You’re also in a position to know when people are telling you rubbish or just crap at delivery and incompetent.
    >>Agreed that you should take the lead and vet the code if you can. But if you plan to just outsource the churn or the boring stuff, you will by definition get boring people who aren’t inspired. It’s the same reason you don’t do it here. Imagine hiring local people and telling them you are giving them “churn” because you don’t want them working on the important things, just the filler. What kind of people will sign up for that work? Yep, the ones that aren’t top quality. Because the top quality people want to work on the new ideas with the newest technology. They don’t want to take out your garbage for you like domestic servants.

    So those are my 12 tips to make it cool to outsource your development – do you have some of your own? Share them – I would love to learn and hear more.
    >>I hope I have contributed to your learning. Do I work with outsourcing? Yes. Lots. It’s not the right solution for everything, and I definitely have my own views. There are lots of big shops that turn out lousy stuff, but there are also lots of boutique shops that do really excellent work. I strongly recommend that startup companies work with small outsource shops. Big coding houses are better adapted to big companies and big projects.

    • eraneyal says:

      Some AWESOME points here. Thank you for the contribution.

      my thoughts:

      2. Non-competes can be enforced in the tech space because you can be very specific about which areas the non-compete is applicable to.
      3. I think there is a reasonable man test to be applied on software shipped and that the dev company is liable. Without a doubt the code should be first deployed to a staging site.
      4. Staging server again – but there is a definite measure of what’s acceptable. Banners that don’t line up, incorrect fonts etc are a sign of sloppy workmanship.
      6. Never is a land if said twice. 🙂 – you’re right – some sort of deposit is fine, but the Odesk style (blog post coming soon!) sucks. Moreover the outsourced company needs to be in a position that they can be called out on missing deadlines or crappy workmanship.
      7. For sure you should never say that (that would be arrogant) – but you should always remember it. If you don’t, you will let them walk all over you. To be honest, those that deliver and ship impeccably get my respect. Those that keep screwing up don’t. And I make them feel it. I’m not there to be their pal. I’m there for a fast-track and I’m paying. Ship on time and to spec and I will respect you. You don’t, I think you’re a bozo. Simple.
      8. Side note – get a good advisory board with at least one star engineer that can help out (heck, that’s how they earn their equity)
      9. Great point on the website.
      11. & 12 – Skype #ftw

      It’s very rare you can outsource anything but the churn. BUT- there are exceptions and generally they are the boutique firms. Take for example Epic, that did the UX for Facebook’s mobile apps. Legendary. Refer back to Points 11 & 12.

      Thanks once again for the kind contribution.

  2. I just have to respectfully disagree that the only thing you can outsource is “churn.”

    There are plenty of examples of good things that have been done through outsourcing, specifically for startups.

    I can’t deny that there aren’t terrible companies out there. Definitely yes.

    But there are also terrible entrepreneurs out there, too. It’s very hard to sit on the outsource side, have “smart” young people sitting in California telling you what to do. Arrogance reigns supreme in Silicon Valley (I live there too, I see it daily). And when these “smart” young folks decide that they don’t have to pay, it cuts both ways.

    I don’t at all advocate accepting crappy work. I just advocate treating people well, including them in your team. It makes such a difference.

    Mostly I like to bring up contrary views, because the world has such a love fest going for Silicon Valley that I get tired of hearing about it. I’ve seen the dark side of so many “smart” people that I want to give a different point of view.

  3. eraneyal says:

    Disclosure – whilst I have lived in SF for a couple of months, I am based mostly in Cape Town, South Africa and busy moving to Canada and USA now (NYC) to expand Springleap.

    My feeling is that you need to know what is good for the business.

    There are 2 sets of dev that happen: Ideation / iteration.

    Ideation:

    My process: Ideation is an inhouse project. You then get consultants in to debunk you junk. Often you’re too close to the project.

    Iteration:

    This can be specced out, and given to an outsourced firm to deal with, if carefully & meticulously specced out.

    When I say churn, I mean non-core development or post-ideation. The team needs to be very close to the code.

  4. eraneyal says:

    NB: You should treat all people well, but when you’re outsourcing: Draw the line in the sand of where your boundaries are so there are no misunderstandings later. Establish hard and fast rules of engagement.

Leave a Reply

Your email address will not be published. Required fields are marked *

Share This