An often-asked question in business is: Should you outsource software development or use your own team to build a new product or overhaul an existing one?
I’ve been in software development for the majority of my career, but right in the middle of it I took 8 years off to start up a construction and remodeling company. I began with some simple tools, a rudimentary knowledge of construction techniques I had gotten from my dad (and the internet), and a dream. The enterprise ranged from a ‘guy with a truck and a dog’ kind of scenario to a multi-crew operation employing multiple subcontractors. During those years, I learned a lot of new lessons, but at the time, I didn’t consider how they might inform decisions on when to outsource software development.
Some jobs were wonderfully successful, and others were miserable failures. I learned what worked and what didn’t. I’ll spare you the details of how I learned these lessons – suffice it to say that negative numbers in QuickBooks and phone calls from angry, disappointed customers are very effective teachers!
Years later, as a Product Owner for Ascendle, I’m able to see parallels between building construction and software construction daily. From that perspective, I’d like to share with you how the building contractors that make the most money and consistently delight their customers answer the above question.
The Problem
The usual issue here is the struggle between capability and opportunity, between capacity and opportunity, or some combination of the two. You have an opportunity, but to fully capitalize on that opportunity, you lack the capability, or the capacity, or both.
In software, these struggles can present themselves in a variety of ways. For example, you may have a great idea for a new product offering, have already secured funding, and just need to get a Minimum Viable Product (MVP) together quickly to see if it will fly. Or perhaps a large potential customer is ready to sign, contingent on the addition of a new feature that requires a technology your team hasn’t had much experience with. In the startup scenario, you either don’t have a team at all, the team isn’t experienced in the necessary technology, or they are already busy delighting existing customers with your existing products and services. So, what do you do?
In the construction industry, the problem looks like this: My company mostly built custom decks, and we usually had quite a backlog each season. I had a crew of carpenters that were capable of digging a few holes and pouring deck footings and were excellent at basic framing and precision finish carpentry. They were not set up for or experienced in heavy excavation, extensive concrete work, electrical and plumbing, insulation, HVAC, drywall, painting, and roofing, and they certainly weren’t familiar with the myriad detailed codes that govern each of these. Now I’m looking at a potentially high-margin contract for a full addition to a house that requires displacing the family and opening up the house to the elements for a time, and includes everything from dirt to ridge-cap. What do I do?
In both cases, the existing team—while skilled in certain areas—lacks the knowledge or skills (capability) to capture the opportunity, or doesn’t have time due to other important obligations (capacity).
What to Consider
Three things to consider as you are making your decision to outsource software development:
- Are you experienced?
- Will you need to do this again?
- What else are you doing right now?
1. Are you experienced?
Is the required work something your team has experience with, or is it new? Software development is referred to as such because by its very nature it wouldn’t be necessary if someone had already done it. However, there are tools, techniques, and technologies that are employed that aren’t unique. These are what I’m referring to. To use the construction analogy, building a deck uses the same saws, the same nails, and the same basic framing materials each time, but the results are completely custom to the design and the needs of the homeowner. The finishes and products used, such as decking and railings, are often different, and each product requires specific installation practices and tools. Each one has its own mistakes to be made, and lessons to be learned.
Deep experience takes years to develop. The little mistakes and process errors that those with experience know how to avoid take some trial and error to learn. If your team hasn’t had those trials, consider carefully whether this is the project you want them to make the errors on. Keep in mind that people don’t always self-judge their capabilities accurately, take an unbiased look at verified performance, and don’t take chances. In my experience, VERY few surprises are of the positive variety.
2. Will you need to do this again?
Is this something you’ll need to do all the time or just a special one-time thing? Do you EVER want to be efficient at this? Is there even a market? Sometimes you may not know at first and that’s ok. As we all know, it’s better to build an MVP quickly, test it, and either fail fast or learn what you need to change in order to succeed. An MVP is really a special one-time thing since you don’t really know if it will fly. You can always convert to an internal team later once you’ve “gotten out of the building” with the MVP and have verified it has legs. Until you know for sure it’s something you want to keep doing, consider it a one-time thing.
When I first shifted my business to specialize in decks, I found my customers often needed a small patio or walkway as part of the project. At first, I would send the customer to a landscaper colleague to do these pieces, but after one or two I decided to equip my company to offer hardscaping as well. I spent over $50,000 on a machine, two trailers, and other equipment, hired an experienced foreman and some helpers, and began trying to sell hardscaping. What I quickly found was that the hardscape market was saturated in my area, the pricing was extremely low, and it simply didn’t work unless I was willing to do quick, cheap work. My business struggled for years because of that one simple decision.
Had I simply shifted to selling the landscaper’s work as part of my offering, I would have learned the same thing at the same speed (potentially faster) but kept the thousands and thousands of dollars it cost me learning it the hard way. Subcontracting the work to a partner in the initial stages allows you to fulfill the short-term need, and more importantly to test the viability of your idea or the consistency of your demand before investing in capability in a certain area.
3. What else are you doing right now?
Don’t underestimate the inefficiency of context switching. I’ve made the mistake (sadly, more than once) of thinking I could pull a couple of people off of one crew and send them to a new project because my next customer was getting impatient to get started. What I ended up with were two ineffective, frustrated crews and two unhappy customers. In addition, my time managing the projects was split, because I had to keep running between two job sites to answer questions and give guidance, or shuttle tools, equipment, and materials around. Both projects suffered and had much lower margins, quality, and customer satisfaction as a result. It simply didn’t work.
As we all know, if you don’t keep your existing customers happy, you won’t be in business for very long. But you also don’t want to turn a blind eye to opportunity. It’s very important to consider how taking on this new work with your team will impact the ongoing satisfaction of your existing customers. In many cases, it’s best to keep a jelled team focused on what they are doing and let a partner service the new demand.
If your team has the experience, you’ve already tested the product’s viability, and you have the bandwidth to support the project, then using your internal team may be the best choice. If any one of these factors is missing, strongly consider enlisting the help of a partner—at the very least for the MVP phase.
What you risk by NOT choosing to outsource software development
In my experience, both in the construction industry and in software development, I’ve found that unless you have the ideal situation described above, you may not be able to achieve the following to the degree you anticipated:
- Speed to market
- Margin
- Quality and elegance
- Schedule predictability
Speed to Market
It’s important to address a new opportunity as quickly as possible, or someone else will. In software development, this means time to market—getting that new product or feature into your customer’s hands as quickly as possible. In construction, this means the completion of the project, so you are out of your customer’s home, and they can begin using and enjoying the work you’ve done. A secondary consideration in both is: what other opportunities will you have to delay—or miss out on completely—if you miss the schedule on this one? Oftentimes, speed is a crucial determinant in if you should outsource software development.
If all the factors above check out and you have the perfect team sitting there waiting for something to do—qualified, fully trained, ramped up and ready to go—using your internal team would probably make the most sense. If you are here today reading this, my guess is that probably isn’t the case.
There are many reasons why servicing this new demand will likely take longer than you planned. You may need to hire new resources or retrain existing ones, get them all to follow the same process, get them set up on the right tools, etc. All of that takes time, and the efficiency just won’t be there right away. A good software development partner will have a proven repeatable process in place and will have a pipeline full of qualified team members vetted and ready to go. This is what they do, over and over again. In addition, even after ramp-up, the lack of experience, along with the distractions from existing products and customers, will likely ensure that your team’s delivery will lag behind that of a qualified software development partner.
An example of this that glares in my memory is from when my company first started finishing basements. It was a great product to offer in the colder northeastern months when we weren’t building decks. I had some experience hanging and finishing drywall on a smaller scale, so I thought, “I can show the guys how to do it, and we will just bang it out.” What I figured would take three or four days took about two weeks and greatly impacted the team’s morale. The lack of experience, tooling, and training, along with all the surprises and rework simply killed our productivity and destroyed the schedule—not only for this job, but for every one that came after it. We never caught up that season. In contrast, from then on, I relied on a drywall subcontractor who would have finished this work in exactly 3 days.
Margin
Margin is an important thing to consider for many projects. Your team may be great at lots of things, but unless you have an extra dream team laying around that isn’t otherwise occupied, you’ll likely find in the final analysis that your margin would have been better if you had chosen to outsource software development to a partner. This is, of course, related to time to market, as mentioned above, because time is money—you have to pay these people to do the work. The longer it takes, the more your margin suffers.
At the risk of stating the obvious, it takes longer for two reasons:
1. Inefficiency
Inefficiency will simply make the project take longer than expected at a scale that is probably an order of magnitude above what you are imagining. You are likely to be inefficient due to inexperience and context switching. Inexperience is inefficient. Someone who has built similar products has figured out through repeated trial and error how to be fast. Few people realize how much context switching destroys productivity. If you are supporting multiple customers and tending to their issues causes you to pause work on the new MVP, upon your return to the MVP, you will lose more than the time spent away from it—you’ll also lose the time it takes you to ramp back up on each project.
2. Defects and Rework
If this work doesn’t fit in your normal niche, there will be more mistakes, rework, and bug fixes. All of these things take time and impact quality, which will be discussed in more detail below. A second issue could be revealed once the product has shipped. If you’ve relied on a good partner for the work, they will guarantee their work and not charge you more to fix issues if and when they do occur, so it removes this variable. More importantly, they have an incentive to make them not happen in the first place. If bugs that make it to your end user are bad enough, it could unfortunately result in the death of your otherwise excellent idea.
The success of a construction company is heavily dependent on two things: margin and reputation. Inefficiency, exacerbated by context switching, and having to pay someone to do the same work twice (at least!) will cost you margin. Taking too long and leaving poor quality behind will cost you your reputation. Though seldom recognized, the same silent killers are present in the software development world.
In the drywall example above, I quickly realized that although the cost of the drywall contractor appeared higher initially, what it actually cost me to have my team do the work in an inefficient, repetitive way absolutely cost me far more in the long run. Luckily, in this case, I learned from my first mistake.
Quality and Elegance
When I first started building decks, I was installing pressure-treated deck boards on a project…happily screwing them down using a spacer all along their length. About halfway through working my way towards the house from the outer edge, I realized the boards were bowed significantly, and the left side was a few inches closer to the house than the right. I ended up having to cut a board into a strange wedge shape to reset everything so when I got to the house it would be parallel and straight. I wonder if they ever noticed.
I learned through this experience that pressure-treated deck boards, as opposed to synthetic boards, are thicker on the ends than in the middle and that they are not uniform in their thickness. You can’t just space them and forget them. I learned that every few boards, you have to check that you are still running parallel to the house and laying them straight. The result is a good quality deck that doesn’t have a strange wedge-shaped board halfway through.
Quality and elegance come from experience. If this is your first foray into building something using new technology, you will definitely make mistakes that aren’t easy to fix and need to be patched up. These could be user experience or architecture choices that aren’t easily reversible and could cause you countless usability and maintenance challenges down the road. They could even be bad enough to cause unhappy customers, slow adoption, and ultimately the failure of an otherwise promising product. If you contract the work to an experienced partner, they will already possess the skills and experience to build in quality and elegance right out of the gate because they’ve already learned the lessons you haven’t even realized exist yet.
Schedule Predictability
When building an MVP, you are often in a position where you have to provide an estimate to an investor of when they will see a return. If you can demonstrate that your estimate comes from a team that has built similar products using the same technologies (i.e., an “expert”) your estimate carries much more weight and is likely to grease the wheels of the funding process. Once again, the experience factor comes into play here. Experience is far better at telling you how long something will take than inexperience. Period. Experience makes you an expert.
Schedule predictability is very important when launching a new product or when upgrading an existing product, so you can coordinate with other parts of your organization. Your marketing team needs to know when to kick off the launch campaign. You may need to work with other teams and integrate with other products. You’ll also need to consider release windows, coordinate production processes, and sync up a plethora of other moving parts. If you have confidence in your schedule, you can have confidence in the whole endeavor. An estimate from a reliable, qualified partner with a proven repeatable process will give you this confidence.
Predictability is incredibly important in construction as well. Fortunately, by the time I got the addition job I described at the outset, I had learned these lessons. I was coordinating five subcontractors, my crew, two inspectors, and a dozen different suppliers. Getting done on time was important because the family was losing the use of half of their house for several months. The home would also be without a roof, risking weather damage for a period of time. It all had to work like clockwork, and it did! It would not have been possible if any one of those interdependent pieces had missed its schedule. I needed absolute confidence in each timeline estimate I was given, and for that reason, I chose to hire experts, rather than rely on my own uninformed guesses. I simply couldn’t afford to do it any other way.
In Conclusion
At first glance, it’s very easy to assume that you’ll save money and time by keeping development work internal, but in my experience, in many situations that just won’t be the case. In addition, you will likely experience predictability or quality problems, which could lead to lost customers or ultimately the failure of a good idea. As we have seen from my failures and successes, if your team doesn’t have the right experience, enough capacity without compromising your existing commitments, and hasn’t demonstrated the long-term viability of the new product or service, using your internal team will very likely cost you speed to market, margin, quality, and timeline predictability. ich could lead to lost customers or ultimately the failure of a good idea. As we have seen from my failures and successes, if your team doesn’t have the right experience, enough capacity without compromising your existing commitments, and hasn’t demonstrated the long-term viability of the new product or service, using your internal team will very likely cost you speed to market, margin, quality, and timeline predictability.
The building contractors that clear the highest margins time after time and maintain the greatest reputations have learned to recruit and entrust qualified partners and subcontractors when it makes sense to do so. The same is true in software development, and I bet the same will be true for your project!
If you’re looking to outsource your software development to a trusted team of experts who deliver real business results while keeping pace with evolving markets and eliminating uncertainty from innovation, look no further than Ascendle. Our world-class team of specialists is ready to help.
