The Pitfalls of Trying to Create Custom Software In-House

Whether it’s a backend system for tracking orders, a simple web integration, or a complex piece of business automation software, companies that develop software may be tempted to create these tools in-house.

We get it; you need advanced, custom software developed for your own use, and you already have advanced development talent on your payroll, ready to do the job.

But using your own developers to write your internal systems can become a costly mistake for three critical reasons.

1. Consistently delivering quality custom software projects on time and on budget is a specific and unique skill. And nobody has more expertise at launching these projects than custom software developers who do it for a living every day.
2. Companies create value from their own, customer-facing software, and anything that takes their developers away from customer-facing projects is a distraction.
3. The most important risks you’ll avoid by assigning this work to a software development contractor may be hidden risks to your company culture.

Get Better Systems:

They may be experts in YOUR product, but that doesn’t make your developers experts in writing the kinds of custom applications you might need. Even if you have great development talent, they are likely inexperienced with the kind of work your custom applications will require, and they will face a steep learning curve to gain competency.

This means added friction and likely mistakes, as your team learns for themselves, lessons already known by a team with experience in the specific types of applications you need. And in a bad case (but realistic) scenario, early mistakes will lead to delays, and errors will get consolidated into your code as the team tries to catch up to a timeline they already know they’ll miss.

In the end, there’s no substitute for experience, and you’ll likely get a better end-product in less time and with less friction by using an outsourced expert in building the exact types of applications you need.

External teams already have institutional knowledge about building interfaces that incorporate best practices for platforms, functionality and user experience. Many will also have have significant code-base assets they can apply, to shorten development and troubleshooting timelines for significant parts of your requirements.

Get More from Your Developers:

This is really an issue of opportunity costs. The opportunity costs of taking your own developers off of developing your product can be deceptively expensive.

Even if your teams seem to be idle, what else could they be doing to add value for your customers? Could the development time they spend working on an internally-facing project be better spent adding features, improving documentation, or addressing NPS weaknesses in your existing product line?

And because they will be working outside their areas of greatest expertise, uncertainty increases. What started as a 2-week project might quickly stretch to 6 or 8 weeks, stretching your implementation timeline and inflating your costs.

With an outside team, you have contractual controls over their costs and timelines. Your costs can be predicted and controlled, and you’re not stealing away resources from the products that make you money.

Protect your Company Culture:

Depending on the purpose of the custom software you need, and the culture in your company, you may also risk internal divisions.

If not managed carefully, your internal software development project could end up frustrating the internal teams that need new systems, the development teams you assign to do the work, or both. It just depends on the power structure in your organization.

Power structures in companies are seldom truly balanced. And if you decide to assign your own developers to work on internal projects, you have to ask yourself two questions:

1. Who holds the power among internal stakeholders?
2. What messages are management sending through this choice?

In engineering-driven companies, power may lie with the developers.

They can exert undue influence in how the project progresses and what benchmarks need to be met to consider it a success. By allowing your developers to control the process, your internal stakeholders may feel like they don’t have enough control to define the product they’ll be expected to use.

Your internal customer might be unempowered to make the project an objective success, and this can lead to disenchantment with the whole project and a loss of engagement from these stakeholders.

In this kind of environment, the decision to use an internal team may be seen as a message to end users that management doesn’t trust them to define their own requirements and manage their own choices.

In Marketing-driven or Accounting-driven companies, the opposite might be true.

Your developers could be treated as expendable commodities and their inputs undervalued. End-users can drive changing priorities or uncontrolled scope-creep, where costs and timeliness skyrocket, regardless of the quality and timeliness of the developers’ work.

In this kind of environment, the development team may see their assignment to an internal project as a sign that management sees them only as a commodity. They may decide that management doesn’t value their unique skills if they’re put on projects that could reasonably be hired out on the open market.

To Be Avoided

If either of these cases bears out, this simple development project could create long
-term damage that goes beyond simple monetary costs. Failures, disagreements, and frustration can lead to long-term friction. And this can lead to damaged team morale, fractured team unity, and long-term, negative impacts on company culture.

Add to this the financial risks of increased expenditure on your development efforts and the opportunity costs of pulling your own developers away from their core areas of responsibility, and you can see why using your own developers for that internal project can be a costly mistake.