8 ms·

The rise of the API-based SaaS

112 points by awwstn 11y ago

thecodemonkey 11y ago
We're in the exact same bucket at geocod.io[1]. I definitely agree with the sentiment that there is less flexibility with pricing on an API-based SaaS. We've also decided to go with the usage-based model, on the contrary it however also makes it easy to make a simple a transparent pricing model. We still have a UI-based piece with a spreadsheet upload tool, but under the hood it's more or less just a GUI on top of our API. When building out a new SaaS, I think it should be clear from the beginning whether it lends itself to an API-first approach, especially as a part of target audience research. In our case our primary target audience is developers, and the secondary is data analysts that prefer the GUI-based approach for one-off batches. [1] http://geocod.io http://geocod.io
- tomschlick 11y ago
  As someone who has a large real estate app at work I can't recommend Geocodio enough. We run geocodio queries alongside ones to google maps and geocodio results tend to be just as good for 90% of the properties we lookup at a fraction of the cost.
manyxcxi 11y ago
I see these like frameworks- you don't want to write HTTP request routing code for every single application you build so you pick a framework. At some point in the past, there was no framework or library, then people distrusted them because REAL engineers knew the ins and outs of their language and knew best how to write the code for performance, then people began to embrace them in general, now there are so many variations picking the 'right' one can lead to paralysis. The difference with these services as an extension of your codebase is that they cost a not insignificant amount of money. Typically, the frameworks and libraries we are used to cost nothing or a relatively small amount and then you're done writing checks. Algolia, though a really neat product, would become very expensive very fast if you aren't careful, and I think you're going to find a lifecycle around these that involves using something like Algolia for something relatively hard to do well (search), then you will reach a point where you have to bring it in house or find something else due to cost. Hopefully the team will have the resources to bring it in house in some fashion, but at some point, these services will not perform well enough for you or be so incredibly expensive that you have to move to something else. That being said, these services are fantastic for people like me that love to build cool stuff and focus on the hard problem that WE want to solve, instead of all the hard problems in the world that must be solved to solve ours. Raising the chickens and grinding the flour vs. going to the store when baking a cake, etc. I bring up Algolia because of my positive experience with them, they are a very nice service, quite easy to use, and just a generally pleasant piece of a tough project I had recently.
- pnachbaur 11y ago
  Out of curiosity, how do you weigh the straightforward cost of a service like Algolia vs the full TCO of bringing it in-house?
  - tomschlick 11y ago
    The way I would view it would be to outsource it until you can afford to hire someone to work on that full time. Search is a bitch. Elasticsearch makes it a bit easier, but if you're a startup and search isn't your primary business it's not a bad idea to outsource it to experts.
    - manyxcxi 11y ago
      > The way I would view it would be to outsource it until you can afford to hire someone to work on that full time. Exactly. I would outsource whatever the problem is that can be outsourced, in this case search to Algolia until we are far enough along that we can tackle it ourselves. I don't think there's a real equation for it until you get to the point you can no longer afford it, but at that point you probably waited too long (excepting the cases where you've run into stratospheric growth). I think as a team you should be looking ahead at growth estimates and making the judgement call to begin working on bringing it in house. Ideally you want the opportunity to run both side by side for a while. And, honestly, what if you architect it or don't grow enough to make the cost a pain point? As long as the service provider is doing a good job, you could use the opportunity to extend your product into various other directions. Why build search if your focus is on something else and your provider is affordable?
numbsafari 11y ago
A key factor that needs to be considered in adopting these tools is how well you can manage your risk exposure to abuse. If you are paying fees based on "usage", what prevents a bad actor (competitor, hacker, a bug in your own code) from causing you to rack up huge fees? And if these features are providing critical functionality for your own app or service, it might not be feasible for you to simply "turn it off". Another key question is whether or not the third-party you are relying on is an actual reliable business partner. Will they get acquired and/or go out of business unexpectedly (a la Parse)? Will they get hacked and create a risk exposure for you that way (PII, PCI, etc.)? What kind of internal controls do they have? And lastly... how do they integrate with devops? A lot of these tools have web-based administrative consoles that require you to log in and make changes. That sort of thing flies in the face of using tools like chef/puppet/salt/ansible--instead you've got to write detailed release notes that typically a product manager will execute, not an operations person. I agree that this is a new reality for a lot of companies/developers. But it comes with a lot of risks and issues.
- thecodemonkey 11y ago
  At geocodio we do a couple of things to combat this. From day one we've had the ability to create and delete credentials, so It's easy to roll them in case they got accidentally pushed to a public GitHub repository or something like that. The other thing is just having a common-sense approach. Humans are prone to mistakes, and we are humans too. If you accidentally geocoded 20 million wrong addresses overnight that you didn't mean to, we're just going to waive the usage. Of course this only scales to a certain point, but in most cases it's clear when something like this happens by mistake.
tomschlick 11y ago
The struggle that many people have with API based providers is that they don't abstract that functionality in their application to a driver based system. For something as crucial as mail, payments, sms, etc you absolutely need to build it as if the provider could go away at any point. Case in point: Mandrill announced two days ago that they were going to merge their product with MailChimp which included a terms of service change that banned marketing emails from Mandrill after their forced migration date in April. At work we have a commercial real estate app which lets our customers send marketing emails. We had built this functionality on top of mandrill but using a driver based system. Last night I launched a Mailgun driver and we have already started to migrate customers with their own Mandrill accounts to MG. If we hadn't used a driver based system we would be screwed for the next few weeks. Build your api integrations via drivers. Even if you only have one driver. You will be happy you did later.
- merlincorey 11y ago
  Is "driver" the new name for "adapter pattern"?
  - tomschlick 11y ago
    Adapter is probably a better word for it. Driver just tends to be common nomenclature.
    - seanp2k2 11y ago
      I guess I still just associate "driver" with an INF file that you right-click -> install to make some hardware work in Windows.
      - tomschlick 11y ago
        Same principal though. You have that driver to connect your internal code (Windows) to a third party service (Some shitty HP printer that you'll want to hit with a bat in 5 minutes).
  - 11y ago
olalonde 11y ago
Here's my pet theory. In the early 2000s and earlier, web apps used to be hard to build. No Bootstrap, WordPress, Rails, Django, Laravel, jQuery, etc. A few years later, they became much easier to build but operating them (scaling, backups, availability, etc.) was still a pain in the ass and expensive. This promoted the rise of SaaS. Now that we have a rising new generation of tools that aim to solve the operations side of things (Docker, Kubernetes, Deis, OpenShift, Mesos, etc.), it'll be interesting to see where things move up in the value chain. I could see a come back to "self hosting" big time if those new tools make it dead easy to "install and forget" your own Mandrill/Clearbit/Contentful/Twilio/etc.
- AznHisoka 11y ago
  One one hand you have APIs that help with plumbing like mandrill and twilit. Those you can replace much easier than data APIs like clearbit, moz, etc
blister 11y ago
My co-founder and I literally just started a (mostly) API-only SaaS product. I wasn't going to launch our website until this weekend, but it would be a shame to miss this opportunity to capture some email addresses. We're building a product that provides application logging as a service. We have a dead-simple API and library for most major languages that you can drop into any product and start gaining valuable insights into your customers and their data and usage patterns. Our service can also alert you via SMS, Email, HipChat/Slack whenever a log event crosses a user-defined threshold. We're super proud of what we're building and I'd love to get some people to sign up to our mailing list[0] and give me some early feedback. (Ignore the website, though. It's on my todo list for this weekend.) http://logdebug.com/signup/ http://logdebug.com/signup/
- martin_ 11y ago
  Do you have any comparison? Is it akin to loggly? splunk? rollbar? sumo logic? new relic? Looking forward to seeing the website this weekend, good luck!
  - blister 11y ago
    It's complicated. Basically, every time I build a new product of any complexity, I end up spending the first week or so cobbling together some sort of logging/debugging framework that I'll use for the entire lifecycle of the project. It ends up being different for each project (I'm a govt contractor, so each of our contracts usually has a completely different tech stack), but the core usually revolves around allowing me to quickly and easily send specific variables and values to some place where I can view them all at the same time. In a nodejs project, think of it like having a bunch of calls to console.log() littered all over the place. Then when it's time to go live, I usually run around ripping all those calls out, or your code ends up with a bunch of calls to the logger commented out. What this system does, and what I've been using it for, is flexibly let you put in calls using a really simple API to the logger and pass whatever kind of data you want. Then, since all the logging is occurring through the API to my service, you can leave all of those calls in your code when you launch or go to production. The part (to me) that is really sweet is that you can have your app deployed to production and have logging basically turned off. Then, from our web console, select a specific session that you're trying to debug and flip a toggle that turns on more granular logging. We also have customizable alerts, like I mentioned, so that if you have a critical error, you can have our system send you a text message. This could be super critical for a small business or startup, I think. It's easy to add Twilio and toss that sort of stuff into a new project if you so desire, but honestly I've gotten kind of tired of writing the same thing over and over again. What I'm trying to do is build a system that is flexible enough for power users, but simple enough to quickly drop it into a new project and be up and running. Then our design allows for multiple projects within an organization, so you can have logging on your website track people through a conversion funnel or something and then have a separate app that tracks usage on your mobile iOS app. To me, the best part is the simple libraries I've built for a bunch of different languages. Javascript would be as simple as: var LogDebug = require('logdebug'); var ld = new LogDebug('API_KEY'); ld.log('Simple log message'); ld.critical('Super important alert!'); ld.log('Simple message with complex data', { something: true }); Then if your next project is C#, you can use the same framework in C#: using LogDebug; LogDebug ld = new LogDebug('API_KEY'); ld.log('Simple log message'); ld.critical('Super important alert!'); ld.log('Simple message with complex data', SomeDictionary_or_List); It seems really useful to me, so I convinced one of my engineering friends to join me as my CTO and let me try and learn about marketing and sales. We have a lot of ideas for where we want to go in the future, but for now we're racing to get our MVP out the door with the useful stuff we already have working. Thanks for asking. :)
tracker1 11y ago
I think Twilio separates itself from the others in that it offers a clear, understandable service and value that's easily compared to more fixed non-virtualized offerings. The value that Twilio provides is much more clear to me, than say SalesForce, for example.
jondubois 11y ago
I think ultimately, there will be fragmentation in the 'as-a-service' industry. For every type of service will be lots of options for companies to choose from; each with their own specific pros and cons and price points. Each one will optimize for specific workloads or customers of various sizes. I don't think there will be any major monopolies in the space; I bet smaller aaS companies will start creating wrapper libraries and tools to make their products compatible with the offerings of larger competitors. Customers will be able to switch between services really easily. It would pose a huge security risk if all companies in the world used the same service to manage all their data. You don't want to put all your eggs in one basket... Especially if you don't have much control over that basket. I think what will happen over time is that each service will become increasingly specialized. The services which are the most 'composable' with other services will be the most popular. Being 'standardized/composable' will the one of the most valued attributes of a service; especially since as companies grow, their requirements might change and they might outgrow a specific service.
gxespino 11y ago
How would you describe a API-based SaaS company with a heavy operations factor tied into it? My co founder and I are building the API for personalized gifts and while the software part is clear, literally half of the company is figuring out the physical operations. Does anyone have any examples of API-based SaaS companies with a similar challenge? And shameless plug if anyone wants to check us out. Accepting beta users for our beta launch in early March. http://www.givemelt.io http://www.givemelt.io
- ryanworl 11y ago
  https://lob.com https://lob.com

112 points by awwstn 11y ago

We're in the exact same bucket at geocod.io[1]. I definitely agree with the sentiment that there is less flexibility with pricing on an API-based SaaS. We've also decided to go with the usage-based model, on the contrary it however also makes it easy to make a simple a transparent pricing model. We still have a UI-based piece with a spreadsheet upload tool, but under the hood it's more or less just a GUI on top of our API. When building out a new SaaS, I think it should be clear from the beginning whether it lends itself to an API-first approach, especially as a part of target audience research. In our case our primary target audience is developers, and the secondary is data analysts that prefer the GUI-based approach for one-off batches. [1] http://geocod.io http://geocod.io

tomschlick 11y ago
As someone who has a large real estate app at work I can't recommend Geocodio enough. We run geocodio queries alongside ones to google maps and geocodio results tend to be just as good for 90% of the properties we lookup at a fraction of the cost.

manyxcxi 11y ago

I see these like frameworks- you don't want to write HTTP request routing code for every single application you build so you pick a framework. At some point in the past, there was no framework or library, then people distrusted them because REAL engineers knew the ins and outs of their language and knew best how to write the code for performance, then people began to embrace them in general, now there are so many variations picking the 'right' one can lead to paralysis. The difference with these services as an extension of your codebase is that they cost a not insignificant amount of money. Typically, the frameworks and libraries we are used to cost nothing or a relatively small amount and then you're done writing checks. Algolia, though a really neat product, would become very expensive very fast if you aren't careful, and I think you're going to find a lifecycle around these that involves using something like Algolia for something relatively hard to do well (search), then you will reach a point where you have to bring it in house or find something else due to cost. Hopefully the team will have the resources to bring it in house in some fashion, but at some point, these services will not perform well enough for you or be so incredibly expensive that you have to move to something else. That being said, these services are fantastic for people like me that love to build cool stuff and focus on the hard problem that WE want to solve, instead of all the hard problems in the world that must be solved to solve ours. Raising the chickens and grinding the flour vs. going to the store when baking a cake, etc. I bring up Algolia because of my positive experience with them, they are a very nice service, quite easy to use, and just a generally pleasant piece of a tough project I had recently.

pnachbaur 11y ago
Out of curiosity, how do you weigh the straightforward cost of a service like Algolia vs the full TCO of bringing it in-house?
- tomschlick 11y ago
  The way I would view it would be to outsource it until you can afford to hire someone to work on that full time. Search is a bitch. Elasticsearch makes it a bit easier, but if you're a startup and search isn't your primary business it's not a bad idea to outsource it to experts.
  - manyxcxi 11y ago
    > The way I would view it would be to outsource it until you can afford to hire someone to work on that full time. Exactly. I would outsource whatever the problem is that can be outsourced, in this case search to Algolia until we are far enough along that we can tackle it ourselves. I don't think there's a real equation for it until you get to the point you can no longer afford it, but at that point you probably waited too long (excepting the cases where you've run into stratospheric growth). I think as a team you should be looking ahead at growth estimates and making the judgement call to begin working on bringing it in house. Ideally you want the opportunity to run both side by side for a while. And, honestly, what if you architect it or don't grow enough to make the cost a pain point? As long as the service provider is doing a good job, you could use the opportunity to extend your product into various other directions. Why build search if your focus is on something else and your provider is affordable?

numbsafari 11y ago

A key factor that needs to be considered in adopting these tools is how well you can manage your risk exposure to abuse. If you are paying fees based on "usage", what prevents a bad actor (competitor, hacker, a bug in your own code) from causing you to rack up huge fees? And if these features are providing critical functionality for your own app or service, it might not be feasible for you to simply "turn it off". Another key question is whether or not the third-party you are relying on is an actual reliable business partner. Will they get acquired and/or go out of business unexpectedly (a la Parse)? Will they get hacked and create a risk exposure for you that way (PII, PCI, etc.)? What kind of internal controls do they have? And lastly... how do they integrate with devops? A lot of these tools have web-based administrative consoles that require you to log in and make changes. That sort of thing flies in the face of using tools like chef/puppet/salt/ansible--instead you've got to write detailed release notes that typically a product manager will execute, not an operations person. I agree that this is a new reality for a lot of companies/developers. But it comes with a lot of risks and issues.

thecodemonkey 11y ago
At geocodio we do a couple of things to combat this. From day one we've had the ability to create and delete credentials, so It's easy to roll them in case they got accidentally pushed to a public GitHub repository or something like that. The other thing is just having a common-sense approach. Humans are prone to mistakes, and we are humans too. If you accidentally geocoded 20 million wrong addresses overnight that you didn't mean to, we're just going to waive the usage. Of course this only scales to a certain point, but in most cases it's clear when something like this happens by mistake.

tomschlick 11y ago

The struggle that many people have with API based providers is that they don't abstract that functionality in their application to a driver based system. For something as crucial as mail, payments, sms, etc you absolutely need to build it as if the provider could go away at any point. Case in point: Mandrill announced two days ago that they were going to merge their product with MailChimp which included a terms of service change that banned marketing emails from Mandrill after their forced migration date in April. At work we have a commercial real estate app which lets our customers send marketing emails. We had built this functionality on top of mandrill but using a driver based system. Last night I launched a Mailgun driver and we have already started to migrate customers with their own Mandrill accounts to MG. If we hadn't used a driver based system we would be screwed for the next few weeks. Build your api integrations via drivers. Even if you only have one driver. You will be happy you did later.

merlincorey 11y ago
Is "driver" the new name for "adapter pattern"?
- tomschlick 11y ago
  Adapter is probably a better word for it. Driver just tends to be common nomenclature.
  - seanp2k2 11y ago
    I guess I still just associate "driver" with an INF file that you right-click -> install to make some hardware work in Windows.
    - tomschlick 11y ago
      Same principal though. You have that driver to connect your internal code (Windows) to a third party service (Some shitty HP printer that you'll want to hit with a bat in 5 minutes).
- 11y ago

olalonde 11y ago

Here's my pet theory. In the early 2000s and earlier, web apps used to be hard to build. No Bootstrap, WordPress, Rails, Django, Laravel, jQuery, etc. A few years later, they became much easier to build but operating them (scaling, backups, availability, etc.) was still a pain in the ass and expensive. This promoted the rise of SaaS. Now that we have a rising new generation of tools that aim to solve the operations side of things (Docker, Kubernetes, Deis, OpenShift, Mesos, etc.), it'll be interesting to see where things move up in the value chain. I could see a come back to "self hosting" big time if those new tools make it dead easy to "install and forget" your own Mandrill/Clearbit/Contentful/Twilio/etc.

AznHisoka 11y ago
One one hand you have APIs that help with plumbing like mandrill and twilit. Those you can replace much easier than data APIs like clearbit, moz, etc

blister 11y ago

My co-founder and I literally just started a (mostly) API-only SaaS product. I wasn't going to launch our website until this weekend, but it would be a shame to miss this opportunity to capture some email addresses. We're building a product that provides application logging as a service. We have a dead-simple API and library for most major languages that you can drop into any product and start gaining valuable insights into your customers and their data and usage patterns. Our service can also alert you via SMS, Email, HipChat/Slack whenever a log event crosses a user-defined threshold. We're super proud of what we're building and I'd love to get some people to sign up to our mailing list[0] and give me some early feedback. (Ignore the website, though. It's on my todo list for this weekend.) http://logdebug.com/signup/ http://logdebug.com/signup/

martin_ 11y ago
Do you have any comparison? Is it akin to loggly? splunk? rollbar? sumo logic? new relic? Looking forward to seeing the website this weekend, good luck!
- blister 11y ago
  It's complicated. Basically, every time I build a new product of any complexity, I end up spending the first week or so cobbling together some sort of logging/debugging framework that I'll use for the entire lifecycle of the project. It ends up being different for each project (I'm a govt contractor, so each of our contracts usually has a completely different tech stack), but the core usually revolves around allowing me to quickly and easily send specific variables and values to some place where I can view them all at the same time. In a nodejs project, think of it like having a bunch of calls to console.log() littered all over the place. Then when it's time to go live, I usually run around ripping all those calls out, or your code ends up with a bunch of calls to the logger commented out. What this system does, and what I've been using it for, is flexibly let you put in calls using a really simple API to the logger and pass whatever kind of data you want. Then, since all the logging is occurring through the API to my service, you can leave all of those calls in your code when you launch or go to production. The part (to me) that is really sweet is that you can have your app deployed to production and have logging basically turned off. Then, from our web console, select a specific session that you're trying to debug and flip a toggle that turns on more granular logging. We also have customizable alerts, like I mentioned, so that if you have a critical error, you can have our system send you a text message. This could be super critical for a small business or startup, I think. It's easy to add Twilio and toss that sort of stuff into a new project if you so desire, but honestly I've gotten kind of tired of writing the same thing over and over again. What I'm trying to do is build a system that is flexible enough for power users, but simple enough to quickly drop it into a new project and be up and running. Then our design allows for multiple projects within an organization, so you can have logging on your website track people through a conversion funnel or something and then have a separate app that tracks usage on your mobile iOS app. To me, the best part is the simple libraries I've built for a bunch of different languages. Javascript would be as simple as: var LogDebug = require('logdebug'); var ld = new LogDebug('API_KEY'); ld.log('Simple log message'); ld.critical('Super important alert!'); ld.log('Simple message with complex data', { something: true }); Then if your next project is C#, you can use the same framework in C#: using LogDebug; LogDebug ld = new LogDebug('API_KEY'); ld.log('Simple log message'); ld.critical('Super important alert!'); ld.log('Simple message with complex data', SomeDictionary_or_List); It seems really useful to me, so I convinced one of my engineering friends to join me as my CTO and let me try and learn about marketing and sales. We have a lot of ideas for where we want to go in the future, but for now we're racing to get our MVP out the door with the useful stuff we already have working. Thanks for asking. :)

tracker1 11y ago

I think Twilio separates itself from the others in that it offers a clear, understandable service and value that's easily compared to more fixed non-virtualized offerings. The value that Twilio provides is much more clear to me, than say SalesForce, for example.

jondubois 11y ago

I think ultimately, there will be fragmentation in the 'as-a-service' industry. For every type of service will be lots of options for companies to choose from; each with their own specific pros and cons and price points. Each one will optimize for specific workloads or customers of various sizes. I don't think there will be any major monopolies in the space; I bet smaller aaS companies will start creating wrapper libraries and tools to make their products compatible with the offerings of larger competitors. Customers will be able to switch between services really easily. It would pose a huge security risk if all companies in the world used the same service to manage all their data. You don't want to put all your eggs in one basket... Especially if you don't have much control over that basket. I think what will happen over time is that each service will become increasingly specialized. The services which are the most 'composable' with other services will be the most popular. Being 'standardized/composable' will the one of the most valued attributes of a service; especially since as companies grow, their requirements might change and they might outgrow a specific service.

gxespino 11y ago

How would you describe a API-based SaaS company with a heavy operations factor tied into it? My co founder and I are building the API for personalized gifts and while the software part is clear, literally half of the company is figuring out the physical operations. Does anyone have any examples of API-based SaaS companies with a similar challenge? And shameless plug if anyone wants to check us out. Accepting beta users for our beta launch in early March. http://www.givemelt.io http://www.givemelt.io

ryanworl 11y ago
https://lob.com https://lob.com