Build your IP portfolio or build someone elses
Intellectual property is a part of your asset portfolio that many businesses overlook. Whether it is software, images, branding, or products, IP is something you can't afford to ignore.
Some Background
Building a successful business requires an extreme amount of focus and dedication. Every revenue stream needs to be built, monitored, and then leveraged so the business can continue to function and grow. Today I want to focus on a revenue stream that many businesses, especially small businesses, overlook entirely; Intellectual Property.
For most of my life, businesses have relied on computers. Starting when I was in high school learning how to run *NIX or Windows systems was a part of every class and curriculum. I was fortunate to live in an area where technology flourished, with companies like WordPerfect, Novell, Omniture, and others were founded. Having access to these kinds of programs was part of what gave me such a great love for technology. It also helped me get amazing grades when I would print out my reports on my friend's work laser printer instead of the dot-matrix printers at the school.
I started programming when I was 12 years old, on an old TRS-80 Color Computer II. It had 16kb of RAM and no storage medium, so anything I wrote was destroyed when I turned the computer off. But from the first time I typed "RUN", I was hooked. I started building programs to draw images on the screen (in 8 colors) and ever wrote a couple of games. I did this for the fun of doing it, never thinking I could one day make money with my skill, let alone with my programs.
Fast forward to 2005 and I was just starting to build online applications with PHP. I had just started my own business, called Strudelhosen, and was selling web sites with a custom-built CMS backend (this is before WordPress or other CMSs became popular. The product I built was copyrighted, so only I or my customers could use it. In the end I retired the product in favor of other platforms, but it served me really well.
That may be true for a software company like mine was, but what about other kinds of companies?
Buy It or Build It
Let's look at a couple examples I have experienced in some of my roles. One place where I see a lot of companies spending money on development is on intranets for their employees. Most use an out of the box solution that meets some of their needs, but rarely find one that does what they need, or they find the other extreme; solutions that do far more than they need.
Some companies I worked for have decided that they want to have something built that exactly meets their needs. They spend time finding a company that can develop what they need, making sure that they own the code when they are done. Another company's solution was to look internally for people who, although not in their job description, wrote code for fun or for themselves. They gave these employees the challenge and opportunity to be great and build a solution, giving them some ownership in the final solution.
Benefits of Buy It
The biggest benefit of an off-the-shelf solution is that you can get something up and running quickly, even if it doesn't exactly fit what you are trying to do. These kinds of solutions work really well for smaller enterprises that are trying to address a problem with a process or a business need. This is why we have standard programs, like word processors, that address specific business needs and we don't see people rolling out their own solutions to these programs until there is a pain point in the existing solutions (price, licensing requirements, etc.)that drives people to find an alternative. Using the word processor example, when Linux users needed a decent office suite and Microsoft wasn't a viable options, OpenOffice became an option. When OpenOffice started changing their licensing, LibreOffice was launched.
Another benefit of buying a solution is that you get the benefits of a lot of developer hours to build the solution, without having to pay for all of those hours yourself. The cost is distributed across all the customers that purchase the product. Developer hours are expensive, to be sure, but when millions of people want to pay for your solution, the cost to the each of those users can be greatly reduced because you are sharing those costs with all the other users.
Drawbacks of Buy It
I should preface this with a disclaimer:
These are just my opinions, and you are free to disagree. I can only base these off of my experience building software and managing software-based projects and products.
The biggest drawback, in my experience, is that you are at the mercy of someone else's development cycle. I saw this recently where a company I worked for needed new mobile apps and an online services portal. I had built a development team and we had these items on our roadmap, but a decision was made to instead to use products developed by one of our SaaS partners whose products we had already been using. The in-house project was scrapped, and we instead waited for the partner to roll out their solutions. I have not been with this company for some time, but I can see easily enough that the partner had a very different timeline for delivery than what was originally expected as the company still has the same mobile apps and web experience.
The same is true when it comes to dealing with bug fixes, and feature requests. You are not in charge; you are just one of many voices ringing in the ears of the company that owns the software. Want the software to do something specific to your business needs? Are there other companies that also want this? If not, good luck getting them to add it to their core software roadmap. Having said that, there are a lot (most in my experience) of vendors that would love to charge you to implement specific features that only you want. I saw this with a product we installed that was hosted on a SaaS partner's cloud. We discovered that there was no way for us to restrict access to the site to only users inside our network. We had to wait for the provider to decide that was a big enough need for all their customers before we could even hope to resolve the issue.
Finally, you own nothing at the end of the process. If something happens to the company that is providing you this software and they go out of business? Well, that is just too bad. Maybe the product will get sold to another company that will try and make a go with it, maybe it will just go away. I saw this happen with a product that I loved, WordPerfect. WordPerfect was, arguably, the best commercial word processor, but it was ultimately destroyed (unfairly and illegally) by Microsoft. It was subsequently sold to Novell (a whole different story there), who then sold it to Corel. It still exists, but you won't be seeing anyone asking for WordPerfect on a job posting.
Benefits of Build It
Take all of the drawbacks of buying a solution, and you have the benefits of building a solution. You control the cadence of the software builds, and you determine the features that will be most beneficial to your company, department, or role. In the previous example, we would have delivered the mobile apps and web portal well before now, because we were making something specific to our company, and not every company even remotely similar to ours. We were also leveraging an Agile mindset and scrum methodology, so we would be able to deliver our MVP very quickly and then iterate on that consistently to deliver a high-quality product to our customers.
The biggest benefit, to my mind, is that of ownership and control. When all is said and done, you own a product. It is yours to use, sell, or shelve. There are many businesses that are fine with outsourcing control to SaaS partners, which works very well for general business solutions, but can still benefit from specific, targeted in-house development efforts. I tend to be very pragmatic in my approach to management in general, so it should be no surprise that I am the same way with software. Use the best tool, not the most convenient or cheapest, the best.
Drawbacks of Build It
Now we come to the end of things, and yes, there are drawbacks to building your own solutions. The biggest is you need someone that can build the solution for you. This means either an in-house dev, QA, and DevOps team (or just one person who is in over their head most of the time!) or finding an offshore or nearshore group that can develop the solution for you, but lets you retain ownership. This means spending money, but there are few ways to run a business without spending money. This means you need to weigh the benefits of the custom solution against the drawbacks of using the off the shelf solutions. Do the features you need make enough difference to your business' bottom line to justify the expense of a custom solution?
Another drawback is that you have the expense of maintaining the software. Fixing bugs requires more than just opening a ticket with Microsoft, Adobe, or Google; you have to find it and fix it. This is a process that can be sent to an offshore team as well, but that means a delay in how quickly bugs get fixed.
Final Thoughts
I hope I have given you something to think about with this article. I feel that owning software and solutions is a large part of doing business in the digital age, and we will be seeing more and more tools and frameworks to make custom development faster and easier.
If you are interested in leveraging a partner in your software development efforts, may I recommend Atomic-32 [LinkedIn] [website]. They have some amazing engineers and project managers that would love to help you navigate the sometimes treacherous waters of software development. I have worked with them in the past with amazing results.
Finally, I am putting a video on this posting that was built at one of my previous employers (Allbee Green) that always makes me laugh and has some bearing on this discussion.
Follow on LinkedIn Follow me on Instagram