Insourcing Nightmares: Insourcing vs Outsourcing Software Work.
Perhaps you’ve fallen into the same trap I have. You have an idea for a new digital product, and you think you can build it internally. Maybe you have a well-known offline brand, but you don’t yet have a successful mobile app. And perhaps you have a guy in IT who is a talented Java developer. Why not let him take a crack at it (insourcing)?
You may want to read Which Is Better for Software Development? Outsourcing or In-House?
This is a mighty tempting option, particularly for large and medium-sized companies. Why? There are two main reasons:
Cost: If we can work with internal resources who are already being paid, then the product is basically free, right? So, isn’t that a better option than paying an outside firm?
Managing Expectations: Executives hate to admit this, but managing expectations is a key ingredient in corporate survival. It is potentially suicidal for a CTO (or any other senior exec) to tell the CEO there is a potential goldmine in the digital marketplace, because the CEO will expect the gold! And if the product fails, the CTO could lose their job or even their career. Consequently, senior executives aren’t going to want to stick their necks out unless they have an assurance of success.
Because of the aforementioned reasons, established companies are often reticent to hire outside development firms. The strategy that they tend to employ is, “Let’s try to build something internally, and see how it does.” Then they either: a) develop a basic app, nobody downloads it, and then the company forgets about it, or b) the internal team never actually launches the app, and then the company forgets about it.
Does any of this sound familiar? I’ve been in companies that have made this mistake more than once. And I’ve seen it happen in other big companies too many times to count. So perhaps it’s time to try something new? Or, in the words of motivational speaker Les Brown, "You must be willing to do the things today others won't do, in order to have the things tomorrow others won't have."
If you’re willing to at least entertain the idea of trying a new approach to bringing a new digital product to market, please contact us. Not only do we have a software engineering team that builds a top-notch product, but we also know how to work with you to ensure your initiatives will be supported internally. As our existing clients can tell you, we help their careers soar.
Continuing with the status quo may seem like the safe choice today, but where will it get you five or even three years from now? Eventually, someone will create a digital product in your marketplace that will be wildly successful. Why can’t that someone be you?
As Pliny the Elder famously said in 79 AD, “fortune favors the bold.”
CodeStringers
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
In House vs Outsourcing Software Development: The Real Trade-Offs (article)
Software Development Team Structure: The Roles, Models, and Right Size (article)
Insourcing means building a digital product with people already employed by the company, often staff whose main job is something else, such as IT operations. It differs from hiring a dedicated in-house product team, which is a deliberate investment with its own budget. The article's point is that insourcing is usually chosen because it looks free, not because it is the best way to build.
Staff time pulled from their real jobs, delays while people learn skills they do not have, missing roles such as QA, design and product management, and the opportunity cost of a product that never launches. Add the ongoing cost of maintaining what gets built. None of these appear in a budget line, which is why the internal option seems cheaper than it is.
When software is the core of the business and you intend to keep investing in a product team over years, when the domain knowledge needed is so specific that outsiders would struggle to learn it, or when you already have a complete team with the right skills. For a first product from a company whose expertise lies elsewhere, those conditions rarely hold.
Yes, and it is often the best structure. An outside team builds the first version with its own product management and QA, while internal staff learn the system, own the business decisions and gradually take over maintenance or extensions. The handover needs to be planned from the start, with documentation and access that let the internal team operate independently.
Frame it as risk management rather than cost. Show the full cost of the internal option including lost time and the chance of never launching, compare it with a fixed scope and estimate from an outside team, and propose a small first phase with a clear success measure. Executives who fear a failed product respond to a plan that limits their exposure.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.