Como NÃO se tornar uma empresa de software

How NOT to become a software company

Many companies are considering creating an in-house “software company” that builds products to sell. However, this proposition may not be as easy as it seems.

Imagem em destaque

If you peek at the list of strategic imperatives for companies across industries and geographies, you're most likely to find initiatives related to building an internal “software company” that produces software that can be sold to the company's customers.

The justification for this is quite straightforward. In a world of tight supply chains and uncertainty, software can represent a consistent recurring revenue stream that is not limited by parts or labor shortages. While upfront costs are high, it costs Microsoft or Spotify virtually nothing to add another subscriber to their platform, and instead of wondering whether semiconductors or plastics from a distant supplier will arrive in time, the new customer can be provisioned instantly.

Many IT departments have gained a new respect and even a degree of arrogance after moving workforces to remote work, launching new collaboration platforms in record time, and perhaps even creating and releasing several in-house software tools.

It may seem logical and perhaps even easy to shift focus to the external market and assume that you already have all the necessary pieces to launch a commercial-grade software company with little investment or additional resources.

However, it is not that simple to become a software company. Here are some typical approaches that are likely to lead to failure:

Going to the market early

Many companies with interesting internal applications may assume that they just need to clean up some internal references and put a price tag on the application and customers will start knocking on their door. This effect may be even more apparent if the software has been provided to some external customers and they voluntarily adopt it.

This approach assumes that the external market will behave the same way as your internal users or as a limited set of external customers who can use your software as a complement to a broader relationship. Your employees may “love” your internal app, but they also haven’t been given a choice of commercial alternatives .

To avoid falling into this trap, spend time researching the market and determining whether customers are willing to pay for your software and what they expect. You may be surprised that the external market demands a very different level of support, security and service levels or emphasizes features that are not as relevant to your internal user community.

This research can be daunting, as you may quickly conclude that taking your internal app to market is a little more complex than you think. But it's best to come to this conclusion before launching prematurely and failing quickly.

Using your internal IT

Your in-house technical team is likely made up of diligent and capable individuals. However, they are unlikely to be a commercial-grade product development team . This is not to suggest that they are inadequate or substandard. To develop commercial software products requires a different set of capabilities than typical work performed by an in-house IT team.

Suppose your company builds and sells physical products. If so, you'll quickly discover that commercial software development is more like physical product development than in-house IT. IT also has different metrics, goals, and organizational structures than an effective product team, which will hinder their ability to create software products, even if they have deep software engineering experience.

Just as you wouldn't assume that a great salesperson would be a great marketer, don't assume that a high-performing IT department would immediately transition into an effective business software development team.

If you want to launch a commercial-grade team quickly, consider augmenting your team with external resources. Just like physical products, you can “outsource” everything from production to testing and support. Follow the same process of evaluating internal capabilities and determining what's worth bringing in-house as you would with any other business function.

Skip the marketing

That software tool you developed that your employees love might make you assume that bringing it to market will result in a flood of sales. However, your company isn't the only one that sees value in releasing software . The market is full of half a dozen software solutions for even the most esoteric problems.

Likewise, you can assume that placing your tool on a popular marketplace will result in quick market traction. Or you might think that your existing sales team will be able to sell software quickly alongside the products and services they are used to. These assumptions are often false as the software requires dedicated marketing and sales support like any other product.

However, the magic of recurring revenue and low incremental costs typically requires a different approach to sales and marketing. Unless you are selling a highly specialized and extremely expensive application, you will likely need a lower-cost approach to marketing and sales that is different from your existing field sales force.

The same considerations apply to your after-sales team. Paying customers will demand and expect a different level of product support than internal users or customers who use your software as part of a broader relationship.

Like any venture, if you find that your strategic plan seems too good to be true and you are anticipating a flood of revenue simply by repackaging an in-house software tool and releasing it to market, you are setting yourself up for failure.

Launching a software business is as challenging as creating a new product or service category and must be undertaken with the same diligence and risk analysis. Just because you have a competent technology department and have had some success with existing tools does not indicate almost certain success. Take the time to assess the market, understand your customers' desires, and set up your software company with the right resources and structure.

Related Content

Back to blog

Leave a comment

Please note, comments need to be approved before they are published.