You Can’t License Your Way to Innovation

p>In making web applications for the better part of 25 years, for both corporate enterprises and startup customers, I've often run into the same mistake being made over and over. That mistake is thinking that there's a way to license a solution and modify it into an innovative experience.

These days, there is a software package for almost everything. And the people that sell software are very good at it. They promise the world to almost every customer. Unfortunately, software off the shelf is meant to serve a large population, even when it's a niche product or industry. This alone disqualifies licensed software from even being part of a truly innovative project. Despite this, people continue trying to build their once-in-a-generation ideas off the backbone of other people's software.

In this week's post, I'll discuss why you should avoid even contemplating licensing other people’s software to reach your objectives. 

You Can’t Create Something New Via Licensing

The most frustrating thing about watching clients attempt to license and build something unique is that software being licensed already exists to fix a large part of the problem at hand. The innovation was already conceived by the person who built what you are licensing! There isn’t any innovation in just using something a little bit differently than it was intended, nor in heavily customizing something to suit your objectives.

Obviously, licensing software makes sense if you're conducting or operating a business that utilizes standard use cases. I'm never one who recommends rebuilding something if it already exists in a way that makes sense. The point of this post, however, is to discourage people from licensing their way to developing a new innovative idea. It can't be done by renting someone else's idea and flipping a few switches.

To craft something new, you need to have the skill and patience to define the application properly, determine what parts (code, frameworks, etc.) to use, build a specification, and ultimately build the application. That's how innovation works: by using ingenuity, planning, and taking a little risk to build something unlike anything else that's available today. If you're trying to build something new that no one has done before, it sounds pretty silly to think you can license something from someone else to accomplish that task, doesn't it?

You Have No Protection

Let's say that by some miracle, you actually can craft something new, something unique, using other people's software. In this fantasy world where that can be accomplished, you'd still be in a somewhat dangerous position. This is because if you can build a solution this way, anyone else can, too, and they can do it quickly. There's no way to seek legal protections, such as patents, when all you're doing is making a cocktail of other people's tools to accomplish your task.

Innovation doesn’t come by using products but by using parts to build products. When you build something from the ground up, you're building protections from day one. The first protection is that it takes effort, and most people are afraid of a little effort. The second protection is that building unique tools gives you legal avenues to explore. The third protection is that if this is truly a unique idea, and you're able to produce it, you'll have a head start on anyone else attempting to do it. For all these reasons, it's simply good business practice to build a concept properly rather than borrow it. 

You Can (and Should) License a Component

Licensing definitely has advantages in certain places. Whenever we're looking to build a large-scale project, we like to think in terms of components. If a component is available that is somewhat common and can be integrated without becoming a foundational piece that limits future flexibility, it's not unusual that we would recommend licensing it, especially if the savings of time and cost are significant.

However, as I mentioned, it's essential that this piece does not become the centerpiece of your project in such a way that it can't be easily replaced later. If that happens, then the uniqueness of your solution is questionable at best, and all sorts of other concerns come into play. What happens if the licensed solution goes out of business? What happens if they change the way the software works, rendering your integration no longer feasible? These are concerns that need to be considered, and that is why we always lean towards redundancy when choosing licensed solutions. This provides our clients with the most control in the future.

You Have Created Zero Value

I'm spoiled to be working in the digital industry. Our startup costs are low, even when developing complicated software. Recently, I was speaking with someone who opened a restaurant. They leased space on a five-year lease and then spent over half a million dollars configuring the space for their needs. I thought to myself that this is an incredible amount of risk to take and an awful lot to spend improving someone else's building. God forbid, if the business doesn't succeed, the landlord is going to end up owning everything.

This, for me, is the number one reason why people should build custom software - it creates a valuable asset. There is simply no value in licensing software, no matter the amount of modifications that you make to it. Building will always give you an asset at the end of the day, whereas licensing can oftentimes take just as much time and effort, yielding less desirable results and leaving you with nothing of value. This means even if your business is somewhat successful, the premium on the sale of the business will not exist.

You Are Not Important to the Provider

Another reason to stay away from licensed software as the centerpiece of your project is that licensed software is in use by many people, which may limit how much the provider cares about their relationship with you. This could make working with them difficult, both during the initial implementation and in the future during the support phase. If the company has an outage, they probably will be impossible to get in touch with, for example.

This is yet another reason why we like flexibility with licensed software. It should never happen that a piece of licensed software can limit your business’s ability to function in a reliable, inconsistent way.

Why Do People Consider this Approach?

As I mentioned before, those who sell software are very good at their jobs. They are not in the business of saying no for a living. It's always easier to sign on the dotted line when it's a licensing arrangement versus engaging with an expert to build out a full-scale project. Many startups still have a layer of risk aversion, which leads them to try the most cost-effective solution to prove concept. I have always said I'd rather design a non-functioning prototype than try to build something off the shelf by modifying licensed software or using these new no-code solutions. Software companies spend millions and millions of dollars on marketing for a reason, And that succeeds in muddying the waters.

What Would be a Decent Alternative?

Much of my post is focused on the idea of people using large-scale web applications as a backbone for building their unique ideas. There is, however, a way to license even if your business model is unique. It's a little bit more complicated and would still require effort, though it could cut down on initial costs and introduce lower risk for an entrepreneur.

The idea is to license the software of someone who's running the same business as you in a non-competitive geography. So, let's say that you know there's a business somewhere in the European Union doing the same thing as you. Rather than having them just serve as inspiration, it may be worth reaching out and attempting to work on top of what they've already done in exchange for some sort of license arrangement. We've seen this work, and it has many benefits and less of the negatives that we've discussed above.

The one key thought here is to make sure you continue to have control over your situation. In these one-off types of licensing agreements, it's not uncommon to run the software on your own hosting environment or in a place that you control or even get access to code to evolve the platform. As I said, it still requires some work, and potentially, you need to engage a development team. But you'd be dealing with less headache, and the people you would be dealing with would not only be receptive to your suggestions but also serve as an interesting resource, seeing how they're in a similar business to you.

Of course, if you decide to build your platform, the option to be the licensor exists, too, which we cover in this blog post.

Conclusion

I looked back over ten years of blogging and was shocked. I had never written a post like this before. This issue is something that I see at least every other month in running a software development firm. I don't think it'll ever go away; in fact, it's worse than it's ever been. My goal is to remind prospective clients that developers and code frameworks exist for a reason. It's because that's where the innovation actually happens.