Stitching Together A SaaS of SaaS (and never owning a server)

http://www.zoho.com is the one I have been using recently, but unfortunately I don't have much experience with Salesforce to make a proper comparison.

Re: Stitching Together A SaaS of SaaS (and never owning a server)

#6

Post by dugmartin » Tue, Jan 14, 2014, 3:14 PM UTC

zgohr wrote: post #3

Opinion on a good CRM that isn't Salesforce?

I've heard good things about this service (haven't used it though): https://getbase.com/

Re: Stitching Together A SaaS of SaaS (and never owning a server)

#7

Post by manishsharan » Tue, Jan 14, 2014, 3:16 PM UTC

Lets think this through !

The more moving parts you add to a system , the more points of failure and latency you will add to your system. Not to mention their impact on your marginal costs.

Some specialized services are not only essential but also replicating them in-house is beyond the expertise of a normal start-up. I would put Stripe, AWS/Heroku/Google, Github in this list.

Others are neither essential (mission critical ) nor rocket science to implement in-house. The start-up has to figure out if the impact of these non-essential services on the marginal costs is justified or not. And how long can you get away without spending money on nice-to-have services ?

Re: Stitching Together A SaaS of SaaS (and never owning a server)

#8

Post by derickbailey » Tue, Jan 14, 2014, 3:20 PM UTC

manishsharan wrote: post #7

Lets think this through ! The more moving parts you add to a system , the more points of failure and latency you will add to your system. Not to mention their impact on your marginal costs. Some specialized services are not only essential but also replicating them in-house is beyond the expertise of a normal start-up. I would put Stripe, AWS/Heroku/Google, Github in this list. Others are neither essential (mission cr…

good points that need to be considered in building your startup! it's a balancing act, i think, and that balance will change over time. for me, with an early stage of my service, being able to focus on my system's features and functionality is more important than the performance and customization that i would get out of writing some of these services myself. i imagine that later on in the lifecycle of this system, i will remove some of the 3rd party services in favor of my own code. but right now, being able to get features done quickly is more important than the monthly subscription costs. i don't expect everyone's situation to be the same, but i think it's a good place to start when you are bootstrapping your own apps / services

Re: Stitching Together A SaaS of SaaS (and never owning a server)

#9

Post by jdiez17 » Tue, Jan 14, 2014, 3:23 PM UTC

I'm not fundamentally against SaaS, but I think it's not necessarily a good thing for every use case possible. I mean, it's a good thing that anyone can provision infrastructure with an API call, but there are two things I'm worried about:

- vendor lock-in: by integrating whoever's API in your code and making it part of your application you make it hard to switch to a similar service offered by someone else. Example: say you're writing a service that has to scale automatically. Cool, you can do this with EC2's APIs, so you integrate that in your application. When the threshold of request per second crosses a certain value, you spin up a new VM. If it's deeply integrated with Amazon's APIs (i.e you're using it to its full potential, tracking spot instances, whatever) it's very hard to switch to DigitalOcean, because they might have different concepts, and I'm not talking about just nomenclature.

- black box syndrome: you stop knowing how things work. This is convenient at first, but if you forget how to configure things "from the ground up", you stop being in control of your infrastructure/data, and ultimately, of your service.

Re: Stitching Together A SaaS of SaaS (and never owning a server)

#10

Post by derickbailey » Tue, Jan 14, 2014, 3:28 PM UTC

jdiez17 wrote: post #9

I'm not fundamentally against SaaS, but I think it's not necessarily a good thing for every use case possible. I mean, it's a good thing that anyone can provision infrastructure with an API call, but there are two things I'm worried about: - vendor lock-in: by integrating whoever's API in your code and making it part of your application you make it hard to switch to a similar service offered by someone else. Example:…

definitely things that need to be considered - vendor lock in being the worst, IME. i'm less worried about API call integration, as i tend to isolate 3rd party APIs from my code... but that doesn't prevent all vendor lock-in.

for me, being able to focus on features is more important than these concerns, right now. i expect that over time i will take some of these tasks in and write the code myself, but at the moment i'm more concerned with feature growth.