

Don't build your house on someone else's platform.  - squiggy22
http://www.webdistortion.com/2012/06/11/dont-build-your-house-on-someone-elses-platform/

======
netcan
In a sense articles like this are useful because making a bold sweeping
statement and trying to back it up is a good way of getting strong arguments.
On their other hand they're treacherous because they encourage us to think in
these kinds of terms. You don't want to be thinking of something as high level
as "building on someone else's platform" in terms of good or bad.

The (boring) truth is, as usual, somewhere in the middle. Like any big
decision there are pros and cons. Opportunities and risks.

Zynga's Facebook strategy opened up a huge market to them. There are other
ways to catch fish of course, they could have built their own social network
for example, but you can't say they're not risky. The Facebook bet paid off
(so far). Zynga got huge. They still carry a lot of that risk. But now that
they're huge they can like the blog mentions try to mitigate it. Maybe they
can even turn the tables.

Microsoft is the ultimate counter-example. In the first few years, they built
on IBM's platform and IBM could have ditched them. But they turned the table.

There are no rules. There is no risk free path. It's good to know the risks,
but riks are not rules.

~~~
netcan
The counter-counter example is Apple. No dependencies on anything (relatively
speaking). More control over design & production of hardware than hardware
companies. Software runs on their own hardware. iOS & OSX devices are complete
& useful products out of the box without a need for 3rd party applications.
Application markets are controlled and no one application (except maybe MS
office) can really affect them. They prefer the internet to the web. Anything
else.

The examples people are going to think of are mostly going to be building
businesses on/in app markets and/or social networks. These are both young
spaces. in 5-10 years we're going to have seen spectacular successes &
failures. Every one of their stories is going to have the "somebody else's
platform" parading as a main character. Sometimes it'll be the hero. Sometimes
the villain.

~~~
jt2190
> The counter-counter example is Apple.

I disagree that Apple is a good counter-counter example. They started on the
CP/M platform, which was proprietary. They were eventually able to develop
their own operating system, thanks to the resources that success had given
them.

~~~
masklinn
> They started on the CP/M platform

Uh? Aren't you confusing Apple and Microsoft? Apple started with the Apple I,
a fully wired circuit board custom-built by Woz. The Apple II was much the
same, although it _could_ run CP/M via a dedicated Z-80 expansion card _from
third parties_.

On the other hand, Microsoft got started when Allen and Gates wrote a BASIC
for the MITS Altair 8800 (not CP/M) then built MS-DOS on top of a CP/M clone
(again not CP/M) for the IBM PC contract.

~~~
jt2190
I should have quoted the parent more fully:

> No dependencies on anything (relatively speaking). More control over design
> & production of hardware than hardware companies. Software runs on their own
> hardware.

It's the argument that Apple (in the beginning) had full control of their
hardware when they had few/no resources that makes Apple (today) a poor
example of how to "do it right" when you're starting a new product. Apple,
too, had to navigate in a high-risk market full of established players.

------
mootothemax
I know the owner of a Facebook application development firm here in Poland.
Based on the brand-new Maserati and Ferrari sitting on his driveway, he's done
pretty well from developing for FB's platform. His house isn't bad either.

It might not last forever, but why not make hay whilst the sun shines?
Frankly, I'm just jealous of the guy's ability to do business!

~~~
jerf
A Facebook _development firm_ isn't necessarily as tied to Facebook as its
clients are. It has long been the case that the winners of the gold rush are
the ones selling the shovels.

------
henrikschroder
So my company is providing a Platform-as-a-service for mainly Flash game
developers, where we provide storage, hosting, multiplayer, and payment
services.

We have lots of customers who are happily building games on top of our
platform, because they do not have the skills required to make their own.
They're small companies who can't afford to hire a bunch of guys to make
scalable storage services or payment integrations or whatever they need. So if
not for us, the games they've made and are making quite a lot of money on,
would never have been made in the first place. They make money, we make money,
everyone's happy!

Of course, if we fail, our customers will fail. They're tied to us, but that's
the risk that comes with the benefit of getting our services cheap.

And on the flipside, we in turn use other PaaS solutions, we use Amazon S3 for
a lot of things, we use a bunch of different CDN providers, and we rent
dedicated hardware instead of buying and running our own datacenter. We stand
on the shoulders of others, our service could not exist without them. And our
customers stand on our shoulders, their products could not exist without us.
And that's ok. There are risks, but there's also opportunity. Building your
own platform and owning the entire stack is _also_ risky.

------
gcp
This is easier said and done, but there are huge, closed vertical platform
stacks appearing, and those same vendors are making it really hard or
forbidding it to get "portable" apps (in the widest sense of the word) working
on their platforms.

You can make your house outside these stacks, but your business isn't going to
run far without any passerby's.

------
bane
This is more than just advocacy to develop a healthy NIH syndrome (not
invented here), but a call to arms that you have to organically develop your
own user-base from the ground up.

I think balancing these three things successfully (your code/design, your
platform, your potential user pool) is probably something that's going to be
written about in some depth over the coming years.

The key thing to remember is that short-term gains don't always translate into
long-term gains with any of those three things -- Zynga is a particularly
useful example: not really their design, not their platform, and not their
user pool. Yet during their meteoric rise, we were virtually swimming in
articles talking about how they used psychology and reward feedback loops blah
blah to hook users onto their software. This translated into lots of users and
therefore lots of revenue. Missing from all of the writeup at the time was the
inevitable fact that _users get used to your gimmicks/novelty wears off_.

This translated into a general loss of players, loss of revenue and investors
who were itching to move to the actual owners of the platform and user pool
rather than the derivative company working with hand-me-downs.

So relying on all three things from somebody else doesn't appear to be a good
path to go down.

It's easy to criticize, but practically speaking, startups can't really
develop all three things on their own. We have to leverage previous work where
we can to get started. Ideally that's your code/design, IP _is_ valuable
stuff. But for efficiency we all leverage other libraries, open source
projects, etc. That's just modern coding practice these days anyways. We're
basically just finding neat ways to put the legos together to get a spaceship
or a race car. Finding a balance between your code and your leveraged
components, in a way that builds value for your company is not trivial.
Sometimes the glue between components really is worth a hell of a lot.

Platforms are tricky, again, if you are small, you end up running on somebody
else's platform. Infrastructure is hard, expensive and often requires specific
skill sets to get running smoothly at scale. EC2 may be the closest thing
there is to a good balance that would let companies migrate to their own
infrastructure if they wanted to. But infrastructure is also commoditized at
this point, and an acquiring company may look at all that hardware sitting in
a rack as a liability more than a value. However, there have been some
successful infrastructure startups (Heroku). But if you are using somebody
else's, be careful that you can move off onto your own eventually (or between,
or back and forth). Regardless, the more of somebody else's platform you are
using the less value you've developed for your company on the code side which
leaves...

Users. This is what it's really about right? Companies really buy other
companies for their users. The code/design is a nice to have in most cases,
but it's really just a vehicle to get eyeballs to engage with your product.
Sure there's some high-end particularly valuable code out there that's
patented and doing something special that's worth millions. But users are
really where it's at. Some questions to ask, are you sharecropping somebody
else's user pool? Zynga is. It's up for debate if that's a successful
strategy. Short term is appears to work, long term it appears not to. You need
to at least rent-to-own, and Zynga simply didn't have a way of dipping into
Facebook's pool, engaging the users, and then migrating out of FB and into
Zynga's own pool. At the end of the day, by simply stopping using Zynga's
products, the users fell back into their default state which was to be FB's
users, not Zynga's.

------
nodata
So should I design my own hardware, write my own compiler, design my own
programming language and distribute my own version of HTML to the world, which
requires my particular browser?

~~~
delinka
Continuing your sarcasm... What? And expect the _world_ to build its houses
our _your_ platform?

I agreed that the sweeping generalization backed up by a single example and
barely any data is absurd. You have you build your "house" on _something_ so
build it wherever is profitable, not always where the plain is wide, the
weather is perfect (for you), and the neighbors are easy to please. If
anything, such places are lightly tread and you're not likely to get much
business in them.

------
damoncali
I think this misses the point. You build on someone else's platform because
they provide _distribution_. Without their platform, you don't get their
distribution. So what does that get you?

This is akin to saying, "don't sell at Walmart." Yeah, I risk Walmart taking
my profits away and risking my business - the very profits and business that
Walmart's distribution has provided.

Distribution is king. Live with it.

------
mark_l_watson
I partly agree in the sense that if you are using Twitter, Facebook, Yahoo,
Google, etc. for login/authentication then you stand a chance of losing users.
You can encourage users to setup multiple login mechanisms, but I bet not many
people would take the trouble.

However I thought that Facebook apps can also be standalone web apps with some
extra work. Also, It seems safe to use web services for things like MongoDB
(mongohq.com), CouchDB (cloudant.com, iriscouch.com), RDF (dydra.com), etc. to
power backend services because you can always switch to running this stuff
yourself. So, data store platform services seem safe enough, assuming that you
trust the vendor.

I am not an entrepreneur (just a happy consultant) but if I did want to start
my own business I might use the FB platform, but try to allow alternative
access to my business.

------
ma2xd
I totally agree. Build your own app/platform based on good and well tested
frameworks. Use the big companies's API's to add value and content to your
app/platform. And if your idea is good, business model is good and you believe
in what you do, you will succeed.

------
webjoe
I think Shayan Zadeh (co-founder Zoosk) gave a great presentation on this
topic a while ago:

Part 1: <http://www.youtube.com/watch?v=ZPLtR38-xVY>

Part 2: <http://www.youtube.com/watch?v=MbhmvXGQehg>

Part 3: <http://www.youtube.com/watch?v=MbLpbzWsi4U>

TLDR; Leverage platform, take advantage of what you're given, but don't become
dependent on it.

------
chrischen
Summary: don't build on shaky platforms. Instead, use them as scaffolding to
build out your own platform.

------
junto
Does this theory apply to platforms such as Parse?

------
clintjhill
Soon we will be talking about "exit strategies" in the platform sense, not in
the buyout sense.

------
eevilspock
"You’ll notice striking similarities between the peaks and troughs in the
graph below."

Correlation does not imply causation. On the micro level most stocks go up and
down together simply because overall market sentiment is a factor on all stock
prices. It would have helped if the chart had included the S&P 500 Index.

------
its_so_on
isn't the basic question here how much money it takes to build your own and
whether you have that expertise and time and appetite for risk in that market,
desire to play in that market?

for a lot of people who made money in the iOS garden, for example, it was do
that or not play, they weren't even developers before, some of them, and
certainly weren't releasing apps. Same for some Facebook games.

Basically, it's like web hosting: if you run your own servers (when you're
small), then whatever business you're 'really' in, you're now also in the IT
business. Per the article, whatever business you're really in, you're now also
trying to make it in the social networking business. Which is hard.

Not everyone wants to do that. For others, who do, the business they enter
incidentally turns out to be their big cash cow. (example: large companies
that build distribution systems and then monetize them or spin off a division;
amazon monetizing what must have originally been its own cloud.)

Basically, it's not so easy to say: for anything you do, roll your own with a
division that could be a company in its own right.

Not everyone should or can make a nationwide distribution network, or get a
physical hardware device into millions of people's pockets or... (list goes on
and on.)

Often it makes sense to what you're good at and can be competitive in, even if
this was made possible by a bigger fish letting you play in their pond. You
can get your own when you're bigger. (if it makes sense and you feel you'll be
successful doing it, even though it's outside your core competency.)

