Don't build your house on someone else's platform.(webdistortion.com)
webdistortion.com
Don't build your house on someone else's platform.
http://www.webdistortion.com/2012/06/11/dont-build-your-house-on-someone-elses-platform/
29 comments
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.
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.
I think discussions like this are generally worse off when we talk about all the outliers, even though it's really hard not too, because they're the first thing that spring to mind. IBM, Microsoft, Apple, Facebook, etc... are not like ordinary businesses.
I guess that depends on context. Some of the arguments for/against "building on someone else's platform" have to do with the potential to become an outlier.
> 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.
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.
> 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.
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.
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.
> 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.
I was muddling Apple and the other popular personal vendors of the time, many who licensed CP/M. (Commodore comes to mind.)
And CP/M was a bit of a clone of RT-11 from DEC fore the PDP 11's. Even some of the untiities where called the same name
Apple ran CP/M? in which universe? It didn't even have the right CPU without an add-on card (which was AFAIK the only way to run CP/M on Apple)
Apple I, II{,e,/GS}, III, Lisa, and Mac before OS/X all had proprietary Apple-developed operating systems (in the general sense, including bioses, stuff like Apple DOS, ProDOS, Diversi DOS and others which don't look like modern operating systems).
Applesoft basic was originally developed by Microsoft, and I'm sure other things were licensesd - but Apple had tight control of everything from 1978, with few exceptions at the time Jobs was not at the company.
Apple I, II{,e,/GS}, III, Lisa, and Mac before OS/X all had proprietary Apple-developed operating systems (in the general sense, including bioses, stuff like Apple DOS, ProDOS, Diversi DOS and others which don't look like modern operating systems).
Applesoft basic was originally developed by Microsoft, and I'm sure other things were licensesd - but Apple had tight control of everything from 1978, with few exceptions at the time Jobs was not at the company.
Indeed. I am trying to think of any software company anywhere right now that doesn't build on someone else's platform. I can't think of any. Either they are setting sail on someone's hardware platform or OS (or even kernel and utilities, as Linux distros do), or both.
I think the key issue as you say is to keep tabs of the risks and try to manage them. But I don't think it is really possible not to depend on someone else's platform to some extent, well unless you want to write your own cross-platform C compiler and then write your own kernel with it, and then write an operating system surrounding it, and then writing your app..... or give up on the cross-platform bit and just make your own chips too.....
I guess that IBM software on AIX on Power might be close to building on your own platform. I don't know if they wrote their own compilers though. But in recent decades even IBM has made noises about abandoning AIX in favor of Linux if they can meet the needs of existing AIX customers.... So maybe it doesn't even work for IBM....
I think the key issue as you say is to keep tabs of the risks and try to manage them. But I don't think it is really possible not to depend on someone else's platform to some extent, well unless you want to write your own cross-platform C compiler and then write your own kernel with it, and then write an operating system surrounding it, and then writing your app..... or give up on the cross-platform bit and just make your own chips too.....
I guess that IBM software on AIX on Power might be close to building on your own platform. I don't know if they wrote their own compilers though. But in recent decades even IBM has made noises about abandoning AIX in favor of Linux if they can meet the needs of existing AIX customers.... So maybe it doesn't even work for IBM....
I think you need to think of these things in relative terms. It's probably more correct to phrase this "don't take big platform risks."
IE, If you build on windows or linux you take the risk of either failing. But you do at least know that they're goal is to be a platform for developers to build on. The risk of sudden changes in the T&Cs turning your business on its head are small, compared to the risk on Facebook, iOS or Twitter for example.
Of course everything is built on other things. Even if the software and even hardware is independent, you're stil dependent on the economy. You need copper for your circuits and oil for your plastics and anyone know how to make tools for making tools for making drilling tools? How am I supposed to get fuel without tools for making drilling equipment? Hold on, I'll figure this out I made a flint axe...
IE, If you build on windows or linux you take the risk of either failing. But you do at least know that they're goal is to be a platform for developers to build on. The risk of sudden changes in the T&Cs turning your business on its head are small, compared to the risk on Facebook, iOS or Twitter for example.
Of course everything is built on other things. Even if the software and even hardware is independent, you're stil dependent on the economy. You need copper for your circuits and oil for your plastics and anyone know how to make tools for making tools for making drilling tools? How am I supposed to get fuel without tools for making drilling equipment? Hold on, I'll figure this out I made a flint axe...
Apple is pretty close. They have their own hardware, OS, kernel and even retail stores. They piggyback on a lot of OSS, but when your developers are all using your hardware with your IDE to make software for your closed platform, it's pretty vertically integrated.
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!
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!
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.
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.
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.
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.
You can make your house outside these stacks, but your business isn't going to run far without any passerby's.
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?
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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.
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.
Summary: don't build on shaky platforms. Instead, use them as scaffolding to build out your own platform.
Does this theory apply to platforms such as Parse?
Soon we will be talking about "exit strategies" in the platform sense, not in the buyout sense.
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.
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.
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.)
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.)
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.