Startups: Did Someone Just Trip Over Your Barrier To Entry?

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Startups: Did Someone Just Trip Over Your Barrier To Entry?


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
  1. 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”.
  1. 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).
  1. 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].

Posted by Dharmesh Shah on Wed, May 10, 2006


Being in SoCal, I'm always reminded of one barrier to entry practiced religiously here: A hot celebrity on board. Perhaps relevant to software if you stretch the definition of celebrity.

posted on Wednesday, May 10, 2006 at 3:42 AM by

I agree type #2 is the most common from the three, and it is interesting to see how it plays along the general principle of releasing early. If you are able to release the first version of your product in 3-4 months of development, and you are noticed by the competition, you inherently won't have a barrier of entry to protect you.

I guess the most naive option is to decide *not* to release early, but that has many problems. Another possibility is: ship early, work like crazy on version 1.1/2.0, and at the same time try to keep under the competition's radar (but not the customers') for as long as you can. But how can one achieve that?

posted on Wednesday, May 10, 2006 at 8:14 AM by Rafael

While I agree that a barrier to entry is an important strategic factor for software startups, I don't believe that it is as important as having a sustainable competitive advantage. A barrier to entry is only one kind of competitive advantage.

For example, if a company is able to market and sell to a certain niche at lower cost than its competitors, then it can prevail over other competitors in that space despite not having any of the three barriers to entry mentioned.

As a software guy, I'm always evaluating if a certain company or product has a technical barrier to entry (since they are indeed very nice to have), but at the same time I believe it's important to keep in mind that many, many businesses have suceeded without the kinds of barriers to entry that we're most familiar with.

posted on Wednesday, May 10, 2006 at 2:10 PM by rob

Data can also be a barrier to entry.

This can be true in two seperate ways. One is a network effect, like LinkedIn.

The other way is through data mining, and usually has diminishing returns. For example, a new insurance company has to gather empirical risk data to price policies, whereas older institutions have years of historical data to leverage.

posted on Wednesday, May 10, 2006 at 4:37 PM by Adam Smith, of

I agree with your arguments here. However, I don't think the problem of "establishing a barrier to entry" should be significant to startup founders. I think Paul Graham was correct in saying that the most important thing in a start up is to "build something people want". I find this problem to be so difficult that most other start up concept issues are practically irrelevant. For example: if I had a working product that people were eager to use, would I nix it because of low barrier to entry? No. On the other hand, if I had a product that was not well recieved by people, but was protected by some technical barrier, would I still pursue it? No.
I guess my point here is that barrier to entry is more of a consequence of an idea as opposed to some new direction for the idea. You can't really do anything about barriers except acknoledge (or deny) their exsistence.

posted on Wednesday, May 10, 2006 at 6:21 PM by John

I disagree with all three.

Small Body Of Clever Code: Any piece of code can be cracked "given enough eyeballs". Tougher the problem, smarter the minds it attracts who don't mind opensourcing their solution.

Large Body Of Non-Clever Code, Consisting Of Small Pieces, Cleverly Connected: This is actually a sub setof #3 because you are locking in your customers into a platform. If you open up the api others will develop parts that fit the whole. Clients are becoming smarter and lock-in are very difficult for a startup to achieve.

Large Number Of Locked-In Customers: Lock in through data format is becoming difficult because clients look for an api before signing in a startup.

There are however some other barriers:
Barrier through identity (user login). Yhoo MSN Google logins. Remember hailstorm?

Brand barrier: Sell a life style instead of a product. Google, apple.

Barrier through habit: Yahoo thrives on it. Hard to get Yahoo mail, finance users to shift to google products.

The bottom line is existing Gorillas can choose to errect barriers, but is difficult for startups.

posted on Wednesday, May 10, 2006 at 9:52 PM by Vishi

The problem with stating that a barrier to entry is essential is that several startups prove the opposite. Several come to mind:

digg/reddit (although, these two aren't exactly "successful" at this point)

What would you say to these companies that defy your assertion?

posted on Thursday, May 11, 2006 at 6:58 PM by Dave P

As always, some excellent comments on this thread -- and in aggregate, they are more useful than the original article.

Rather try to respond to each individual comment, will plan to write a short "follow up" article with my thoughts on them.

posted on Thursday, May 11, 2006 at 7:03 PM by

At least one other barrier to entry comes to mind: Your competitors have a mental block that prevents them from understanding your business model and its appeal--even though your customers and sponsors understand it instantly and completely. Because these potential competitors can't begin to appreciate what you're doing--or why what you're doing is worthwhile-- their cluelessness is your barrier to entry: hence, for all practical purposes, you don't really have any effective competition.

Examples: Google; Yahoo Store; Rails.

posted on Thursday, May 11, 2006 at 10:00 PM by Jack H

Perhaps this view of the product as a body-of-code is a bit static. In many markets (especially my field of telecoms), it is not what you have that counts, it is how quickly you can respond to changing requirements.

The agility of your company to respond can keep sedentary or risk-averse companies from competing.

posted on Friday, May 12, 2006 at 5:14 AM by Rupert Rawnsley

In cases where there is no significant barrier to enter, "first mover advantage" & "ability to develop cult following" are of immense help IMO.

"delicious" is a recent example.


posted on Friday, May 12, 2006 at 5:47 PM by

How about the sheer quality of implementation? You might have a development team so very talented and a development process that is so rock solid that competitors can never hope to emulate the quality of your products. When customers see the two products, one is a sleek, stable software and the other is basically a kludge.

Can I implement a blogging software. Sure! Can I make it nearly as good as blogger? I don't think so!

posted on Sunday, May 14, 2006 at 4:47 AM by ARV

Comments have been closed for this article.