Any startup founder that has ever attempted to raise capital is likely familiar with the concept of the “barrier to entry”. This magical (but conceptual) structure is what allows you to enjoy the fruits of your labor (in the form of profits) and keeps would-be competitors from raiding your well earned near-monopoly position for a little while so you can make some money.
I’m a simple guy, and so I’ve come up with only three variations of the “barrier to entry”. Though there are possibly more, most can probably be restated in terms of a sub-variation of one of these.
The Three (And Only Three) Types Of Real Barriers To Entry In Software
- Small Body Of Clever Code: Your product contains small pieces of particularly difficult or cleverly crafted code that solves a really hard problem. Frequent examples are security software, really smart search algorithms, codecs, etc. These clever pieces of code don’t have to be large, they just have to be really hard so that your run of the mill developer can’t really easily replicate what you’ve done.
Litmus test: When you demo your product to other smart and competent developers, they don’t walk away thinking “given enough caffeine and motivation, I could rewrite this in a weekend – and still have time to catch a movie”.
- Large Body Of Non-Clever Code, Consisting Of Small Pieces, Cleverly Connected: In this instance, there’s nothing particularly tricky about any of the code that constitutes your product, but it is necessarily large and complex (because you’re solving a hard problem) and has lots of moving parts all working together, reasonably well. An example of something like this would be the early version of something like SAP. These kinds of products get big because they need to do a lot (data management, reporting, workflow, transactions, etc.). They’re not some simple AJAX-based calendar where everything fits into one nice neat little package.
As an aside, I’ve found that large bodies of non-clever code often interface with other people’s large bodies of non-clever code using proprietary protocols. This makes the entire solution “ugly” (from a programmer’s viewpoint), and is another great way to raise the barrier to entry a little bit – do stuff that is so ugly, hardly anyone wants to write that code, because it’s just not fun.
Litmus test: When you demo your product to other smart and competent developers, they don’t walk away thinking “given enough caffeine and motivation, I could rewrite this in a week or two – and still have time to write an AJAX-powered IDE for Ruby On Rails”. An even better litmus test (which we used in my first company), is to honestly ask your own development team how long it would realistically take them to “rebuild” your own product from scratch if you all left and joined a new company. If the answer isn’t at least six months, be worried. In our case, we were able to get this number to about 12-18 months (i.e. if I had the luxury of leaving the company and taking all my developers with me, it would still take me 12-18 months to recreate the technology and compete with my former self).
- Large Number Of Locked-In Customers: If you have a product that already has a big customer base, and it is expensive and/or highly painful for customers to switch to something else, you have a barrier to entry. This assumes of course that these customers are profitable for you in some way.
Litmus test: Your competitor demonstrates their product to one or more of your customers, and your customers are unwilling to switch unless the competitor sweetens the pot by providing their product almost for free and paying somehow to help migrate the customer over and promising to do a bunch of custom development at no cost. If it takes that much to steal away your customers, you probably have a barrier to entry. Though if is usually the case that you get to this kind of state of well-being by having one of the first two categories of barriers, it is not unheard of for startups to get lucky and just find themselves in this enviable position by falling into it.
That’s it. If what you have doesn’t match one of the above descriptions, then chances are you don’t have a barrier to entry. (Though technically, you might have a barrier, its only about 6 inches high and most people can step right over it – so it doesn’t really count). If you’re thinking: “What about patents?”, my response is “what about them?”. Patents are a strange kind of barrier to entry that actually requires that people acknowledge their existence and you have the resources to enforce them. For most startups, neither of these are true. How many software startup founders have you met that do an exhaustive patent check before locking themselves in a room and writing code? Not many. This doesn’t mean that patents can’t, in the future, become a barrier to entry, but they just don’t start that way. The best you can do in the early stages is file a patent anyways.
If you have a barrier that competitors can step over (or trip over), you’ve got a real problem. I kind of think of this as the difference between “obfuscation” and “encryption” in the security world. If you’re using obfuscation, you’re really not protected, because all you’ve done is made it inconvenient for an average person to get to the data you are trying to protect. This is like the grade school “secret squirrel code” algorithm where you replace each letter with a number and send cryptic messages to your friends. On the other hand, encryption goes well beyond that and is structurally designed to protect the data. When creating your barrier to entry (and you really, really need one) you need to make sure that it is not a mere ‘inconvenience” that keeps just the average competitor out, but it is so high and so strong that few would dare to even approach the wall surrounding your castle. There’s probably a Sun Tzu quote somewhere that describes this “protecting your castle” concept, but I can’t recall one right now. If those kinds of pithy sayings get you fired up, by all means, feel free to look it up and find the appropriately motivating words. I’ll wait until you’re back.
Now that you’re sufficiently motivated to erect a barrier to entry, the question is how. The answer is, if you have to ask how we’ve got a problem. The best startup founders are those that intrinsically have a preferred barrier to entry model already in their heads that comes “naturally” to them. In my case, it’s almost always #2 (i.e. large bodies of not-so-clever code, cleverly connected). Everything I have ever done falls into this category. As such, I look for opportunities that play to this particular strength (and interestingly, I tend to recruit people that are good at this same type of development). No degree of incentive or threat is going to get me to produce a brilliantly clever piece of code that a hedge fund would use to optimize their portfolio. It’s just not in me. I’m not that smart. And, though I would like to believe if such an opportunity presented itself, I could hire people that are that smart, that doesn’t really seem to work either. I haven’t quite figured out why yet, but will ponder it for a future article.
Summary of my point: Software companies take about five or so years to get to a point where exceptional profits are being generated and the “sweet spot” has been located. Without a significant barrier to entry, your startup will likely never live long enough to get to that point, because the competition will follow you, the market will get divided, and hardly anyone will make any money. Simple economics 101 working against you. What you want is a monopoly, but since you’re unlikely to get that, the next best thing is a high barrier to entry.
So, as you plot global domination, ask yourself which of the above “models” feels the most natural to you. Which one are you going to be exceptionally good at? Remember that no matter how big your target market, how “cool” your technology or how “hot” the investors think your particular sector is, it won’t amount to a bag of beans if you can’t keep competitors at bay for at least a little while.
[Authors note: I use “bag of beans” vs. the classic “hill of beans” as I’m assuming that the average bag is smaller than the average hill and a sufficiently large hill of beans might actually have some value].