Is force.com from Salesforce replacing five layers of tech that startups struggle with?

MaxBlox/Founder Institute Director, Chennai Area at The Founder Institute

March 1st, 2015

As a tech startup just a few years ago, you needed to deal various layers in the development stack: data center, hardware, connectivity, security, operating system, database, language to build an application that can be delivered over the web.

You needed the tech expertise and attendant problems, resources, money and tiime to make this happen, including operations staff.

Today you can replace all of that from Force.com. In addition you can get a solid installed base to market to.

My question: have startups switched to considering such platforms rather than the old model?

Richard Vann Founder at Cloud Haven

March 1st, 2015

I was responsible for development of a Patient Relationship Management system on SalesForce. A decision to use SalesForce as the development platform can kill a company for several reasons: 1) SalesForce may arbitrarily refuse to "approve" the required security review for the application, or may take many months to complete the security review (you can't sell your product until you pass review) 2) SalesForce is a giant monolith of proprietary technology, 3) it is is "org"-based (like having closed, on-premise systems in the cloud) - "orgs" don't play well with other "orgs", 4) you are limited to whatever their platform supports which can be extremely limiting depending upon what you are trying to do, 5) difficulty integrating with other systems (or if you do forget about the security review!) Today there are more modern, well-accepted technology stacks hosted platforms like AWS, Joyent, Heroku, etc. which provide many of the benefits of the SalesForce platform without the many disadvantages serious drawbacks which at best may cripple your development efforts and at worst will kill your product before it even gets started. And it is very expensive. SalesForce sales people are ruthless and you are totally at their mercy

Michael Brill Technology startup exec focused on AI-driven products

March 3rd, 2015

We're heading back to a world of vendor lock-in whether we like it or not. Let's say you went all-in with AWS (http://aws.amazon.com/products/)... and then you want to switch providers. Good luck. And with higher and higher level services (e.g., machine learning, cognitive computing), you're going to have to pick your poison or be at a competitive disadvantage because you have to cobble together your own bits.

Vijay MD Founder Chefalytics, Co-owner Bite Catering Couture, Independent consultant (ex-McKinsey)

March 1st, 2015

Is your comment generally on PAAS or on the Force platform specifically?

We use heroku (owned by Salesforce).

don't know much about Force specifically but time to figure out the proprietary Apex language and generally poor quality of tech support make me less interested in switching over vs using a API from heroku.

Would love to hear about any specific benefits Of the Force platform specifically valuable.

Michael Brill Technology startup exec focused on AI-driven products

March 1st, 2015

I think pretty much no startup uses the "old model." Also, I seriously doubt that any startup would buy into force.com unless they were committed to salesforce.com add-ons. This is precisely why salesforce.com bought Heroku.

Gopi, do you a scenario where force.com is a good platform for a non-salesforce.com oriented startup?

Karl Schulmeisters CTO ClearRoadmap

March 1st, 2015

Windows Azure PaaS has been around for years. It offers all of these in a vetted form.

Our solution https://ClearRoadmap.com runs 100% on Azure.... We do not manage ANY VM images. none. We use a PaaS compute instances, blob and SQL store, LDAP, Authentication, GraphAPi, Connectivity and sendmail integrated via the Marketplace SaaS interface

Anil Sharma Founder at Trillo.io

March 1st, 2015

As Michael said, unless you are building something around fource.com services, consider a platform based on open technology stack. In PaaS world, consider Heroku (Saleforce) or Cloud Foundry (IBM/ Pivotal). It is not uncommon to assemble your own managed package for cloud. I can comment on a Java based stack, use mysql/ postgres for RDBM, Cassandra for NoSQL, Spring/ Tomcat for web+app tier. For a WEB UI, Query, Backbone, Bootstrap for UI (which you will have to use irrespective of PaaS or own stack). Heroku is a better choice if you want to stick to Ruby, PHP or Scala. Cloud Foundry is as complicated as assembling your own stack. Using your own stack gives a choice of running on a cheaper IaaS (linode, digital ocean). Use Nginx for web server.

Karl Schulmeisters CTO ClearRoadmap

March 2nd, 2015

Why Heroku and not the MSFT platform itself?

MaxBlox/Founder Institute Director, Chennai Area at The Founder Institute

March 2nd, 2015

+Vijay Goel. It is about PaaS in general, but using Force.com as the most prominent example.
I am not pitching Force.com. We found it was too expensive to use for our SMB customers. Though the pricing works better for Enterprise.
We do use salesforce.com as our CRM (not Force.com), and as part of our solutions we integrate with salesforce.com ( also MS Dynamics CRM and SugarCRM).

+Michael Brill. I see Force.com as a very good platform for some specific scenarios. If you are targeting mid-to-large enterprises and you dont have a strong go-to-market strategy. Force.com will reduce dev time and increase quality as well as take you to market rapidly. But i would also seriously consider +Richard Vann's comments above. There is much good and bad in these decisions.

John McMahon CEO at Starter Inc.

March 3rd, 2015

Two words: Vendor Lockin

This is not a vague, philosophical reason, as others have noted: being locked into any monolithic platform can result in unilateral decisions by the platform vendor killing your product.

All it takes is an API change, a non-approval, or even a competing offering from the platform vendor to destroy months or years of work, and take your business out.

At Starter, we are passionate about building platforms and tools based upon open source standards, open source, and portable platforms.

IF there is a need to integrate with a proprietary service like Facebook, SalesForce, or iTunes, it is done as a connector/plugin... the core server runs on Linux/Tomcat/Java with various front-end clients written in HTML/JS, WordPress, Swift, Java, C#, or whatever makes sense for a responsive front end experience.

With a portable java/linux based backend, you can move the core app to various Cloud providers such as Azure, AWS, Backspace, AppEngine, and even your own data center -- preferably a hybrid of these with some failover capability.

In this day and age, there is a huge trend towards consolidation -- don't be a victim of the whims of a giant vendor, choose portability and open source and you will win.

http://starter.io/starter-ignite/

Eric Lannert Program Director at Digital Youth Network, DePaul University

March 3rd, 2015

The need for open is even more important if your solution is about integration.

We just did an internal ops project that integrated freshbooks, salesforce, bill.com and ultimately xero. We used our lamp stack and a cloud integration provider (itduzzit.com) as the controller and data hub for all the reasons in this thread.

If you had come to me with the same solution we just built, and it was on force.com it would have worked. But I probably would not have gone with you because it removes my ability to change out a part of our architecture in the future.

The question of whether we are trending open or closed is an interesting one. I am optimistic (naive?) that api changes will slow down and that access to our data will increase. The primary reason is that because we have integrated, we are effectively 'locked in' as long as they don't change. No competitor to bill.com / sf / xero will have any chance because the switching costs are too high. Now that all changes the moment any of them do something that trends toward closed/lock in - because that creates the work that opens up a moment to re-evaluate - e.g. if we have to make this upgrade/change anyway should we use this moment to look at other options?

I think they get this. We haven't seen a single api change that required any maintenance costs on our end for salesforce in 5 years. By being open and api friendly, they achieve lock in by their customer's choice, not by force.