Building the core of your product
30 September 2015
Everyone has an opinion on outsourcing. Some will tell you it is the answer to all your problems, getting cheap labor that works when you don't, who wouldn't want that? Some will tell you that it only causes you headaches. Like most issues, it isn't that cut and dry, but there is a balance that makes sense as a software startup.
I doubt there is a startup in existence that doesn't outsource something. If you're building the software for your database or web servers in house, you're likely to run out of money and patience before you even start working on anything of value.
There are essentially two ends of the outsourcing spectrum. You can outsource very narrow, specialized tasks to tools that specialize in that one particular thing. These tools likely have a team (and maybe a business) that is working to make that tool better for you and other users. Or, you can outsource broader tasks, like a full "department" of your startup to a firm that provides humans to accomplish tasks for your business. This type of outsourcing essentially gives you more man power, possibly at a cheaper rate. The two ends of this spectrum can be characterized as tools vs resources.
In the early days of your startup, the only thing that matters is making something people want. You should confirm and re-confirm that this is the case as often as possible. Talking to users and looking at data are the only ways to do this well. This is so critical to the success of a startup in the early stages, you should use all the tools you have at your disposal to be able to focus as much time as possible on making your product better. This means designing features, writing code, creating prototypes, and watching people use it.
There are an endless number of tools that are useful to new startups nowadays. If you aren't taking advantage of them, you'll be left in the dust. Pretty much anything your business does that isn't core to the product should be outsourced, provided that it isn't too big of a hassle up front.
Do you need to manage customer relationships? Signup for Close.io or any of rest of the CRM tools that fit your needs (though after spending parts of the last few months building a Salesforce app, I'd recommend you stay far, far away from it). Do you need a project management tool? There are literally thousands of them. Same goes for analytics, hosting, continuous integration, your database, version control, communications tools, newsletters, drip campaigns, dashboards, logging, HR, and pretty much everything else that isn't core to your product. If by some long shot, you're startup is shipping LTL freight, we'd love to help you manage it with Freightview.
All of these tools make starting a startup easier, faster, and cheaper. Most of these services integrate with others or at least have an API that will let you build the integration yourself. Yes, most of them come with monthly fees after the free trial expires, but they are well worth the money and the fewer headaches. Picking the right time for their implementation is important and can save you money, but anything that lets your focus more on your product is a good thing.
This advice might sound like something you shouldn't have to tell someone looking to start a startup and you're probably right. I've seen many people decide that the solutions offered by existing tools aren't a good fit for their business and want to build something custom. Maybe its a form of procrastination. Most of the time they don't realize how big of an undertaking this actually is and how detrimental splitting your focus in a startup can be. After you've grown and your startup isn't fighting for its life everyday, building some of these tools in-house might make sense, but I really doubt it. If you can't find tools that are a good fit for your business you may have found a potential startup idea, but more than likely you should probably take a good look at your business and figure out how you can simplify your needs.
For some very specific scenarios, outsourcing to a third party product might not be the answer and deciding what is "core to your product" can be a very fine line to walk. For example, if you're building a web app, I'd be hesitant to suggest that you outsource your backend to a service like Parse. It probably makes sense if your product mostly resides in the client/user interface, but I'm not sure that this encompasses very many useful products. Outsourcing your authentication and user management to something like Auth0 is another situation that I am unsure about, but I think this one is more of a toss up.
When it comes to building the actual product, you can act similarly. If you aren't leveraging existing frameworks or libraries, you're probably wasting time. Especially if your product isn't out the door yet. There are interesting issues that involve software licenses when including third party libraries in your code, in which I am completely out of my league, but I would suggest that an attitude of ask for forgiveness and not permission will take you pretty far (though you should probably do your research and possibly consult a lawyer).
The choice of an open source library that you can use freely vs a library you have to license for money is an interesting trade off. For more general things, like your web server, database layer, UI toolkit, etc. there are usually only a handful of battle tested open source libraries in each ecosystem and making use of them would be very wise. These things usually have lots of contributors and have active development communities (recent commits on github, quick turnaround on issues). Be skeptical of any developer who wants to roll their own tool when a battle-tested alternative exists.
For more niche scenarios, the right answer may very well be to go with the paid library. These niche areas can sometimes lack open source attention or be incredibly fragmented. In these niche areas, companies that charge money for a library tend to have good documentation, better interfaces with less boilerplate, and humans to help you fix particularly nasty implementation issues. Who knew charging for a product could result in that product getting better?!
If a paid library offers more functionality, is easier to implement, and jives with your engineering culture (besides the fact that it is not free and open source), you'd probably be better off using the paid library. You might even be able to use it for free for a time. If there is a legitimate technical reason for using a more complicated open source library, have at it. If you can save developer time by paying for a library and having it implemented now instead of next week, you'd be wise to consider paying for the library.
Outsourcing the various departments of your startup can be tempting as well. Should you outsource things like marketing, sales, product development, legal, accounting, etc? Again, it goes back to how important they are to your startup. Legal, accounting, and HR can almost certainly be outsourced to someone else. These things don't really vary that much from company to company. You might want to find firms that are used to working with startups, but this shouldn't be a huge deal.
Outsourcing your marketing can probably go either way. I'd highly recommend that you do it yourself before trying to outsource it. Ideally, you'll find something that works well and then, if you even need to, have a third party firm just execute a larger version of what worked. I don't think any of the marketing firms that I've seen used have been worth the money the startup paid to them. I do think it can work, but so far, I've yet to see this proven to be true.
Outsourcing sales probably never really makes sense, unless you don't have a product that requires a sales force. You might be able to partner with companies selling complimentary products to yours, but as an early stage startup you'll likely have trouble convincing anyone useful to do this. Learning how to sell your product is very important knowledge and developing that knowledge in-house, preferably as a founder, will be beneficial when you start ramping up sales.
The one thing you should never outsource if you are building something that you hope people will want is product development. There is an interesting dynamic that comes into play when you try and outsource your product development: the people you outsource it to just flat out don't care as much about the product as you do. A sense of ownership is often times what motivates developers to build something that is not just "good enough," but is instead fucking awesome. Outsourcing the product development can also cause you to be less passionate about the product. I've seen it happen.
If you are having to choose between outsourcing the product development and not building it at all, I would seriously question whether your team has any business starting that company in the first place. If one of your founders isn't technical, how are you even going to know if the people you hire to build it aren't pulling a fast one on you, are making good decisions, or if the code has a shot at being maintained into the future?
Often times, the sub-$40/hour rates you can find for overseas developers are very hard to resist, but I can assure you that it will likely end up costing just as much, if not more than if you were to do it in-house. Doing product development in-house has the unique quality of aligning the interests of the people building the product with those of the company and this is very much needed if you want to build a world-class product.
It's not that overseas developers are worse than those you can hire here in the ole' US of A, but that is definitely sometimes the case. The great developers don't need to work for these overseas development shops. This means you are usually left with the uninitiated developers trying to bill enough hours to make up for the low cost. You might also get stuck with someone who you are paying to learn a new technology and very little guarantee that you will be able to keep them around with that newly acquired knowledge.
The long distance relationship and the fact that they are supporting (or will be) other projects leaves you with a developer who isn't fully focused on the product. The communications break downs that inevitably occur as a result will bring product development to crawl.
Communications break downs and misunderstandings seem to happen much more often when you are working with outsourced developers. These problems can be caused by language barriers or just poor communications skills. An outsourced developer probably doesn't truly understand your company's mission, values, and culture and this hinders their decision making ability hugely. This causes more questions and feedback. When you bring product development in-house you can hire for good communication skills and for people who fit into your company's value system and culture.
Waiting for approvals and feedback seems innocent enough, after all, they can start working on the next feature right? This might be the case, but the effects, while subtle, can be incredibly damaging to your business's velocity.
Every time a developer has to wait for feedback, get approval, or get a question answered requires two context switches, one to switch away and one to switch back. Context switches are probably the single biggest killer of developer productivity and outsourcing basically guarantees more of them. If you were to do product development in house and you hire developers who can think for themselves and empower them, they can likely just get something into place and working by taking some educated guesses and then come back and fill in the details later. Maybe even after the first version of that feature has shipped.
There will inevitably be questions that require interruption, but when you're outsourcing, getting these question answered and figured out usually takes much longer than if you were doing it in-house. This is sometimes caused by different timezones, that they are hesitant to ask, or sometimes because the outsourced developer wants to batch up a lot of smaller questions so they don't waste you're time. While this is a good thought, likely product development speed is one of the most important parts to a startup success and all these little delays add up in a big way. Being able to grab someone when an issue pops up and have a face to face conversation about how to solve the problem works wonders.
I'm a big fan of having the product development team work together, in-person as much as possible. I didn't used to think this was as important as I do now. After seeing the results in action, I don't think I would ever advocate for a remote team, especially in an early stage company. The loss of fidelity that occurs in a remote work environment is hard to overcome and you need every advantage you can muster as a company in its infancy. Being able to work remotely part of the time is worthwhile, but you should still have a, preferably private, place to all meet regularly. I'm especially a fan of work from home Wednesdays.
As a (business) founder or product manager, you should be removing as many speed bumps as possible between the people building the product and getting something released into production. The critical path in a software company, especially early stage ones, is almost always product development and you should do whatever you can to reduce the overhead from the related bottlenecks. In software, the features you have not yet shipped are your work-in-process inventory, and running as close to zero inventory as possible is a wise move in any business. Just because its made of bits doesn't mean your inventory can't go bad or be faulty from the beginning. Whether it is a feature that missed the mark with users or a feature where your competitor beat you to the punch. Releasing it is usually the simplest way to know whether a feature is faulty or not. Every hour, day, or week that it is not in your users hands is a lost learning experience that you could be using now.
This reality can sometimes cause situations that do not seem very efficient on the face of them. Things like potentially interrupting another developer on your team to help solve a problem, asking them to review your code when they have a free moment, or going directly to the CEO with a question about a feature or task. Working in an environment like this requires good judgement and a respect for other people's time, but you must also recognize that shipping is one of the most important things that a software startup does.
Building a proper software company that can produce world-class products is hard and has its own array of challenges, like building an engineering culture, recruiting developers, and splitting large features into smaller tasks and prioritizing them. You will certainly learn a lot by making mistakes. Shipping often and attention to detail are two ways to make up for your inevitable mistakes with your users, but you should do everything you can to minimize the surface area in which your mistakes can hurt the startup. Using other services to outsource areas of your business that are not core to your product, but are core to the product of the businesses to whom you outsource to will allow you to move faster and focus on what matters, your product.