A potential client of mine had a great idea: They were going to build the next great product (let's call it WidgetFoo), and it was going to be social for enterprise. So, we sat down to have a high level architecture discussion. How were we going to build this thing?
Before I go further, let me say for the record: No, the product's not a widget, but since they're in the middle of building it right now, I can't actually tell you its name or idea. N.D.A. One of the executives spoke up. He'd been at a conference where
Salesforce.com was pitching its development platform. This "Force.com" thing sounded like it could really help the product, he said. With the product's enterprise focus, the team already knew it was going to have to integrate with Salesforce, so why not integrate really tightly? Plus, the Force.com folks would help promote WidgetFoo through case studies and sponsorships at various trade events. Then the director of Social Media spoke up. She'd been doing some industry research, too. Since at its heart WidgetFoo was really about social, she thought maybe we should make it a Facebook app. That way it would be right there for everyone to use. This opens up an interesting can of worms:
Should you build your application on a platform that belongs to another company?
Background
Every application is ultimately built on a platform. Websites are built on the browser platform. Installed software is built on the Windows or Linux platform. Usually, we refer to these as technologies more than platforms, because ultimately we have to choose one of them. Proceeding without a baseline technology is simply not possible. There's an additional option, however. Many companies — like Salesforce.com, Facebook and
Google — offer platforms that provide additional benefits though they also impose additional constraints. For the purposes of this article, we'll call the first set
technologies, and the second set
platforms. Let's compare the two.
Technologies
- Are commonly available.
- Are a requirement to enter a market (e.g., if you want software that runs on Windows, you must use Windows).
- Generally don't require specific permission to use.
Platforms
- Are provided by a single company.
- Provide tight integration with the company's other offerings (e.g., Google Apps allow automation of Google Docs).
- Generally take a share of revenue.
- Often offer a marketplace or app store.
- Require a license or other development agreement.
- Frequently come with co-marketing opportunities.
The Lure of Platforms
Platforms — like Google Apps, Force.com or Facebook — hold a lot of appeal. They offer many potential benefits. Let's look at the main ones.
Rapid Time to Market Platforms like Force.com or Google Apps provide a lot of pre-built technology that you can simply start using. For example, a single Google App API call can create a contact or respond to a calendar invite. That's a lot easier than building an interface to each Google offering yourself. In extreme cases, some platforms can build basic applications without writing any code at all. All of the platform's offerings represent features that your team doesn't have to build, and that helps you get to market faster.
Easy Access to Many Users Using a platform gives you access to its distribution method, whether it's an app store, module market or whatever. Typically that will include credit-card processing and/or billing as well as downloading of the app itself. That's a fair amount of overhead that magically disappears when you use a platform. Without doing anything at all, your app is in front of many people. In part, the successful platforms work because they have millions of users — and that means millions of potential users for your app, instantly.
Instant Reputation Simply by being in the app store, your product has a large company's stamp of approval. It's not going to trigger security warnings when users install it, and it's not going to make potential users suspicious. Instead, it's another cool thing that's clearly safe to use because it's been approved by a big brand name.
The Downfall of Platforms
Of course, all those benefits come at a price, and that price can be pretty steep. Let's look at the dark underside of building your product on a platform.
Expensive Revenue Sharing The first cost of using a platform is simply that: the cost. Most platforms take a percentage of revenue, up to about 30 percent. That's a big chunk of each sale.
Your Product's at Another Company's Mercy Once you're committed to a platform, it's hard to change. So if the platform decides that an extra security assessment is required, you'll have to do it. If the platform removes functionality, well, I hope your app didn't need it. If the platform starts rate-limiting requests, your app will have to change to batch requests or just slow down. If the company stops supporting the platform, well, that stinks for you. In short, you're stuck on the platform roadmap, whatever it is. And not having control of your own future is a scary feeling.
Difficulty Crossing Platforms All the things that make it easy to get up and running on a platform make it harder to get off of it later. If you decide you need a second offering, you're going to have to replace or provide a lot of functionality yourself. The second implementation isn't necessarily going to be as quick or easy as the first.
Choosing to Use a Platform — and Which One to Use
Using an application development platform can be a great strategy, as long as the benefits exceed the drawbacks. Just make sure that you're making a conscious choice based on market and technical merits, not just because some sales guy wooed you. As for my potential client, they ended up deciding that neither the Facebook platform nor Force.com gave them what they needed and that building on one would make integrating with the other very difficult. So they're building a standalone Web application that integrates with Facebook and Salesforce, but doesn't use either platform. We'll have to wait and see how their choice turns out. Image: 123RF
