So, you’re an “idea guy” (or gal) and have the next new new thing…you just need to get it built! But you are not a developer, and all the developers you know are busy working on their own thing!
What about outsourcing your software development? Just post a quick note on Upwork or other site and sit back and let the power of the web change your life 😉
Of course, it’s not that simple, and learning by trial and error can get expensive fast. Outsourcing is fraught with risks and inefficiencies particular to the industry. Here we show you how to manage those risks, so you can have your cake and eat it too!
It’s a well-known and accepted trade-off: Outsourcing can be inexpensive*, but the quality, usability & expandability of the results may be less than desired. One assumes one is rolling the dice and figures “Hey, for the price (compared to hiring locally), we can always build it a second time if it’s a complete mess!” Or, you’re just stuck with no other option – at this or any price.
(*Some would argue that outsourcing is NOT inexpensive, considering the long term costs associated with poor quality. This article assumes we can manage that risk, and therefore make contract development & outsource a viable cost-saving option.)
What are the risks? They fall into these general categories:
- Time: Missed deadlines, missed market opportunities
- Money: Budget overrun, having to cut features later in build
- Quality: Why build it if it breaks, or looks ugly?
Of course, not all of these issues are limited to outsourcing – internal development teams can fall behind and run over budget too. Additionally, there are issues specifically in using freelance sites.
Let’s jump in.
Managing Risks Before We Begin
1 Set Realistic Expectations (with yourself)
There are always issues with new people and new processes. If you are not a developer, this may seem very new to you. Will you use their workflow or yours (do you have one?)
Educate yourself on project and workflow management – Google it. Learn about it, its limitations and requirements. Then, you can focus on keeping the project on track better.
DON’T expect a year’s work in two weeks. (Don’t worry, you’ll narrow the scope, per below…)
DO expect to be available to clarify, and to update or further detail your specs.
DO expect to drop some functionality or features (or postpone to rev 2), to manage time/money risk.
Do your part (garbage in > garbage out)
2 Write good (great) specs, and stick to them! In the absence of good specs, expect them to build whatever they think you want, and charge you for it.
Use free tools such as
3 Narrow your spec! This will afford you the MOST risk management. By building only a small part, you have the option to switch contractors or strategy soon after starting, without a huge loss of money.
This is a big enough problem to be one or more additional posts (coming soon!), but for now suffice to say you need to set aside anything and everything that is not your core offer to the user. Of course you will need a back end component to operate the whole app, but on top it shoujld only be the very minimalist of functionality.
Almost as simple as one button. “Push this to get your most pressing need satisfied.”
This winnowing down of the spec and product build is a core tenant of the Lean Startup methodology, and Agile development. In this case, you get the added benefit of managing risk. If you have issues with your developer, just cut them off at the end of the (short) build.
Managing Risks When Engaging A Firm or Developer
Selecting a firm or developer is the single biggest point of risk. Most people understand that, and so they become mired in the process.
You want someone who has built on the stack you think is best, or close to what they might recommend. In some cases, specific domain experience would be helpful, but it’s not required if you have deep knowledge. A reservation system is goign to be similar acrsoss differnt industries (hotel rooms, apartments, travel) or even similar enough to other systems such as appointments that you don’t need to require that the developer have built an “online airline reservation” tool.
It goes without saying that you won’t hire a .NET shop to build LAMP apps, or a web developer to build on iOS, so we won’t make this a tip for reducing risk.
Managing Selection Risk
4 Pay by the project is a good strategy in most cases. But you need to find that sweet spot: If you set the price too low you’ll lose good programmers (or they’ll save time by lowering the quality), If done right, it helps keep on budget, by eliminating the temptation for them to take the long way in solving the problem.
5 Ask for, and check, references.
Ask about availability for the duration of the project
Ask about other jobs that the contractor may be running in parallel and how that might impact your job.
Selection risks inherent with freelance sites:
Freelance sites such as Upwork or Guru.com aim to address risk with well known but simple systems like ratings, reviews/comments from past jobs, amounts earned or other financial stats.
These systems work until they no longer work. Ratings & reviews for example are fine, as long as the field is relatively dispersed, usually when it first starts off. But as time passes, and only a few providers show for top reviews, and they keep getting the lion’s share of work as a result, then they have market power and can raise their prices. This eliminates much of the value of outsourcing.
Contractors on marketplace sites may not be who they say they are; it’s the Internet after all! All we care though is they may not be able to deliver what they claim. They may show you portfolio work that is not theirs, or after landing your job, hand it off to a more junior developer who can not deliver the same.
Sometimes a firm is bidding on the job, with good ratings and work history and portfolio, but the developers doing the actual work are some junior devs, or who are new to the firm. They may have nothing to do with the good reviews or portfolio.
Some freelance sites show you the results of tests the developers have taken, in an effort to help you the buyer reduce risk. This may be more window dressing than actual risk-reduction. Developers self-test and there is little accountability or verification of who in fact took the test. The freelance sites are not in the business to make their people look bad, so the tests are not the most rigorous. Lastly, technologies change and update, so recent testing is important.
Managing Freelance Marketplace Site Risk
5 Ask applicants about their past work, and who will be doing your work.
6 Limit applicants to those who read (& care) about your job post; embed a code word into the description and reject any applications that do not reference that word. Something like “so I know you’re real, please add the word “Pineapple” to the subject of your proposal”
6 For bigger jobs, consider asking applicants to test somewhere independent of the site.
6 Use multiple contractors (across multiple sites) and run in parallel (generally a good idea for the “interview” portion of the process, even though it costs money. Great idea if on a tight deadline)
6 test smaller portion of larger job
Managing Risks After Development Starts
Once things are rolling, you arguably have less control. That’s why selection is important, as is building only a small part of your solution.
That said, there is still work to be done:
6 Review project daily, and let your developer know you are reviewing it, but don’t get in the way. It shows you care, so that they care too. A note as simple as “progress looks great – keep it up.”
6 Be available, Time zones may be terribly inconvenient, but make it a point to be available to answer questions and clarify specs to keep things moving along, and to keep the contractor motivated (easy to work with clients get extra special care!)
6 Job should be small, if narrowed down and spec’d right, but if not, and if it looks like a total derailment, Pull the plug
With Freelance sites:
Test code / application as often as possible. This means building into the spec stages that allow for running and testing some portion.
Have code inspected by third party. Hire a trusted local developer familiar with the technology stack to review code every few days for an hour or so.
Review code early & often
Make it testable or run tests
With outsourcing, you can also run into issues with developer availability. Contractors may take other jobs or otherwise disappear from your job anytime during the process.
This might assume the worst in outsourcing, but not all are bad, or subpar! Just check our resource page, where we in fact say it’s OK to outsource!
[ lead bait? ]
Want to take it a step further? Or want someone else to handle the suggestions here, so you can use outsource development without risk? Check out our Team page for partners that operate at this level.
Correct number in title
You can try to assemble a team from freelance sites, or use their teams, or try a outsource company outside those sites.
It’s like when a person who doesn’t know cars talks to a mechanic (and wonders if they need all the work). Solution? Review systems (BBB, Yelp), taking along a person who knows cars better, and even attempts at transparency (in California, shops are required to hand the customer old parts to show they were worn out or broken.)