The trade-offs of internal vs. external resources can be complex, and the financial aspects can be very nuanced. External software development resources are generally excellent for validating an MVP with low commitment but are outpaced by internal dev employees for investing in your long term product.
In my 10 years of experience in the software sector, I’ve worked as an engineer, manager, and executive. I’ve worked for small startups (<10 person), mid-sized companies (100s of employees), and large corporations (fortune 100). I've worked with all kinds of local teams, remote teams, domestic and foreign contractors, consultants, and vendors. I joined my current company as the engineering leader and first technical employee. Prior to my arrival, the company had built and maintained their software product entirely through external resources, including various contractors, software development firms, and vendors. I have since built a small internal team with a light but strategic reliance on external resources.
I'm glad to have spent the time over my career to learn the trade-offs of internal vs. external resources, but I hope to help you avoid the pitfalls of first-hand experience, especially if you're a non-tech business owner who can't go through the technical experiences I did.
Financial considerations of internal vs. external development resources
In my experience, I have found that employees are a big, long-term, high return investment. Externally-contracted resources are a smaller, short-term, low-to-medium return investment. External resources are generally 2x-4x as expensive per hour as full-time employees of comparable skill, but carry much lower commitment. They allow you to pause your development for a period of time, which can afford breathing room at critical times and allow you to reduce your spend dramatically. If you were to pause payroll for your employees, they would leave, and you probably wouldn't get them back. It should be noted however that many external development firms (i.e., not one-man dev contractors) require you to purchase regular support agreements with hourly minimums or face exorbitant fees for out-of-contract support. That’s not as big of a financial hit as retaining developer employees, but it does mean that a pause will not lead to a total reduction in spend.
Internal vs. external for an MVP
If your software product is small or nonexistent (e.g., still developing your prototype/MVP or still finding market fit) or you are not yet confident in it, external contractors or firms are a much better fit than employees. They are very good at small, short-term projects (<6 months), have a canned development process, and can get your product to a customer-facing state. After that, you have no obligation to continue development with them. That's a great way to do the minimum work required to validate an idea to see if it's worth long-term investment.
Think of external resources as putting development on rails that limit the risk/reward to an acceptable medium range. There's an additional hidden benefit to using external resources at this stage, too: the higher per-hour cost for external dev hours will help you resist the urge to overextend your scope, helping you keep your MVP as minimal as possible. However, if you are still using substantial amounts of purely external resources for over a year, you should reexamine your position. Are they spending time fixing costly bugs in what they built earlier in the year? That's concerning. Are they building more and more features? That's better, but not sustainable in the long run either.
Internal vs. external after market traction
Once you have traction and you are ready to make the deep investments in your product necessary to scale, you should strongly consider hiring internal employees. The lower cost per hour is helpful, but there is a much more valuable benefit: your business is their business and your customers are their customers. They are deeply incentivized to build into the success, longevity, and sustainability of your product. External resources, on the other hand, aren't as directly aligned with your goals. Your fires are not their fires. They have their own business to run, and it likely looks very different from yours. Their job is to fulfill what their customers ask for as explicitly as possible, and if that results in your product going sideways, they only stand to lose you as a customer. Your employees, however, know that a product going sideways means they are going to be out of employment and scrambling to find a new job. That mindset is much more closely aligned to your own and results in better products.
This is probably enough for one post, but let me know if you found it valuable and if you have any questions or comments about what you're going through with your external vs. internal decisions. Also let me know if you'd like to hear more about related topics, like how to vet external resources, how to make your first technical hire, and when to rewrite your prototype!