Dev Shops and Upwork Contractors, How to Build Best

There are lots of ways to get an app built. I explored some tradeoffs in my article on outsourcing vs hiring inhouse. Here, we’re discussing the advantages and disadvantages of dev shops and hiring single contractors.

Dev Shops

Software development shops can vary wildly in quality, but share a lot of similar attributes. Dev shops generally have 2-50 developers on staff, and they work in the technologies they work in. Whatever they’ve used in the past is what they will use for you. You can make a decision on language before engaging with a dev shop, but any open source components, libraries, or third party integrations will be those that have been used in the past. It is unlikely that the PM or dev will do the research for what’s best for the use case at hand. Dev shops often employ developers that are cheaper labor. This means there is a layer of PM or account management between you and the dev. This person is lower skilled, and primarily adds value by being bilingual in the native tongue of the devs. The biggest downside, however, is taking instructions at face value, and interpreting it to something that’s easy to deliver that could reasonably pass as that thing. Even though the shop wants to maximize the hours billed, that doesn’t mean the right thing will be built. Additionally, there is never push back on what features can or should be built. The PM doesn’t have any insight into your business to help advise you on questions of how to best reach your goal. Tradeoffs like “feature A will cost twice as much as feature B, but won’t move the needle on customer acquisition,” will not come to light. For this you need a technical partner.

There are some advantages, though. Cost is usually high for dev shops, compared to other solutions, but long term support is generally good (at a price). They are also generally good at replacing devs as they come and go on the project, so you don’t need to handle turnover or personnel issues.

Individual Contractors

Hiring single contractors is another main option. There are a number of sites to do this on, each with things to look out for. Upwork is good to find a specialist at a single task, or very low cost work. Arc is a low cost option for mid term contracts. Facet is for high skilled contractors at mid length. I’ve done work on all of these platforms and hired on them as well. Hiring single contractors poses some problems in communication and timezone. In these relationships, the functions and features have to be spelled out to a t. It is almost necessary to be technical yourself to communicate the requirements in the language of code and systems design. Timelines and dev schedules are difficult to manage, if the person you’re working with goes on vacation, or decides to take a higher paying opportunity, and leave the gig. Tight controls on deliverables is key here as well, and knowing the scope of the work you’re giving is the only way to not overpay. Long term support is difficult here, as well, since devs want to be writing code, not supporting their old work. They may move on to a new contract, rather than have 5 old contracts at an hour a week to support.

The biggest positive for this approach comes in specialization in some tool that you’ve chosen. If you know a particular library that will integrate well with your software and solve the problem at hand, you can find someone who’s done that task 10 times before. This will reduce time to launch considerably. It’s also relatively easy to hire and fire contractors of this type, though ramping up on the codebase takes time.


Both of these approaches have a number of cons, but can work in certain situations. Using a fractional CTO can marry the best of outsourced contractors (specialization), with the long term support of dev shops. Most importantly, though, a fractional CTO can understand your business needs, and marry that together with the technical constraints. This is where the true value comes, to make sure you’re building the right thing, not just building it right.