The Business of SaaS
stripe.com
stripe.com
> Businesses and investors love SaaS because the economics
> of SaaS are impossibly attractive relative to selling
> software licenses.
I would be careful and not over-generalize. The statement above is opposite of what many late stage investors think of SaaS companies. Their gross margins tend to be horrible. Some are basically in the business of being an intermediary mailbox for transferring money from their customers to AWS.Sure, if you can charge, say $1 for processing one Kb of data, you'll love being in the business of selling SaaS subscriptions. But it's not always the case: for many SaaS companies selling more and more subscriptions means constantly re-writing (AKA "scaling") their codebase, maintaining a large and expensive ops team and dealing with ever-growing AWS bill. Some SaaS companies only have ~10% of their R&D allocated to evolving the product, the rest are struggling keeping it running and it's not cheap.
Compare that to selling a recurring subscription to a downloadable license file. Stripe is a great fit for SaaS, but TWLO will have to face a much tougher reality than MSFT had.
SaaS can be awesome, or can be hell, take it from a co-founder of Mailgun.com
Stock market seems to agree: the 1st wave of software explosion produced lots of highly valued tech giants: MSFT, ORCL, etc. The current crop of public SaaS companies pale in comparison, the new giants don't sell SaaS, they sell ads.
P.S. The billing model is very loosely related to how a software is delivered. Look at Adobe who're happily selling monthly billing plans for good old photoshop.
But yes, I recently read that games make more money in general than even movies, books and music and most of them don't have subscriptions but one time payments.
Instead of paying $45 one time, you might spend $120 over the course of a few years.
They also basically converted a big chunk of their subscribers to pure mtx players with that move further muddying the signal.
Moreover, if you're smart & lucky and you manage to find a large niche with good margins running SaaS on AWS, Amazon will launch it as a service. Mr. Bezos is around & watching you :)
[EDIT] Besos -> Bezos :)
Mr. Kisses sounds even more ominous!
I had to look it up, but Twilio gross margins are healthy -- 55%. AWS expenses are not really a problem for a company like Twilio, their well publicized arrangement of relying on other large tech companies is a bigger threat.
Where does it end? Will these companies ever be profitable? I'm invested in several public SaaS companies, just following the trend...
Any other insight into your experiences/troubles? How you decided on pricing, whether it had any impact on sales/sales efforts, what you had to do to support such a model?
Thanks very much for your time!
I was on a non-software forum last week where a dev was gathering pain-point information because he intended to produce software for that niche. The main feedback I remember was "just let me buy it. No f'ing subscriptions."
It makes sense in theory, but businesses don't grow to infinite size so fixed costs do matter. Ignorance of this fact drives the lower than anticipated gross margins of many SaaS businesses.
It's intentional. Great margins don't matter if you don't have customers, and no VC is going to get excited about a few extra margin points on OpEx when should be focusing on growing.
Personally I think companies still continue to overspend in sales in marketing and with SaaS they use a blended average of CAC which includes their organically acquired customers so that the blended CAC looks extremely low. But the reality is you are paying 10x more for "paid" customers than organic and adding an only incremental amount of growth (5-10%). I think that's where the real profitability of SaaS companies lies.
Paid I would consider traditional forms of advertising and marketing such as TV, FB, Google, ads, etc.
Organic or community driven advertising has it's costs as well but I would separate that out to a different section. This would include budgets like meetups, some conferences (though many I would actually lump into traditional ad spend), t-shirts, stickers, credits to customers, community expenses and so forth.
Then for non-tracked customers I would assume that percentages work well. Meaning if 25% of my customers come from community, then 25% of my non-tracked organic customers are from community. If 5% are from paid, I would say 5% of my organic non tracked are paid.
If you do the break out this way you will see that old-gaurd paid advertising is 80% of the cost of the entire sales and marketing function, but brings in an overall 5-10% of net new sales.
Now if you are profitable, or near profitability go for it, but if you are losing a sizable portion of yearly revenue, say 50% or more due to sales and marketing and you see it broken out this way you will immediately realize how false this spend is.
Just because something is done a certain way and accepted, doesn't mean that it's correct.
But one exception doesn't make a rule.
Set it up on real hardware with 2-3 good admins and you'll save 6x per year. AWS has its place, but it's unlikely that place is anywhere near 100% of everything. This truth has practically become a heresy, which means you can make good money by having the gumption to take advantage of it.
> Some are basically in the business of being an intermediary mailbox for transferring money from their customers to AWS.
Does this mean that you can win just by hiring one of the few people who can accomplish the terrifying task of, GULP, setting up a server without dragging around little blocks in a web GUI? :P
A SAAS client of mine's operational costs are like 1% of our revenue. Ok, they're at Series A/B funding sort of size. they've started to go international and we could also quite easily do an instance per country if we wanted, though I don't know what sort of pain that might cause.
Running ASP.Net/C#/Azure. Azure's a bit of a nightmare, would be running much better/cheaper on a dedicated server in my professional opinion (shock, horror, yes, I said it, cloud is a bit of a con).
I've spent 2-3 weeks per year "scaling" the code, which was written by other people who in some ways didn't know what they were doing and were trying to make it too much like a SPA which resulted in lots of ridiculous, excessive dupe calls for data and over-complicated code. After my last round of optimisation I doubt they'll need to scale up for a couple of years now, the CPU was basically sitting less than 20% and DB was about 40% even in the crazy Xmas rush, and we were on standard tiers (compared to the year I started where they had to turn up to premium a couple of times with 10x less users).
A few things jumped out to me as off:
> Conversion rates of low-touch SaaS trials with credit card not required:
> 2%+: extremely good
Really? 2% seems awful. If a company signs up for your trial, they must have a problem they're trying to solve. If you don't solve 98% of peoples' problems, it seems like you have a problem getting people engaged with your product.
Our (bootstrapped low-touch B2B SaaS's) trial -> paid conversion is closer to 8%. This doesn't feel "extremely good". I think we can do much better.
> Virtually no low-touch SaaS business achieves net negative churn; their churn rates are too high to outrun.
What about Intercom and Front? Are they just outliers?
I would guess that this is actually true, but only because most low-touch SaaS business don't have scaling pricing - they have fixed plans. If you have pricing that scales with usage/value, you'll make much more each month from expansion revenue.
Overall I loved the article, and wish I could have read it a year ago before we launched our SaaS company. Thanks patio11 and Stripe.
Nah, great products are about focus. You definitely don't want to scope your focus as "98% of peoples' problems."
All too often someone at the company is getting their problem solved (possibly by the free/trial plan), but they aren't at a position where they are able to drive any purchases whatsoever for that company.
- The landing page gets about 30-70 hits per day (excepting the occasional spike) -- how many of those are bots and crawlers, I wonder?
- I've had a grand total of FIVE (5) trial sign ups.
- No buyers yet
- My linode bill is currently about ~$120/month.
- Still within the free tier on S3 and Mailgun.
- You know, when I'm the only one using the app, I don't place much stress on the infrastructure.
Now, I can't really say one way or another if I'm getting to that 2% because I'm just not getting enough trial sign-ups :)
EDIT: Oh, yea, link for the curious: https://www.contabulo.com
Bah, I've posted it here before.
2. Postgres (Master)
3. Postgres (Standby)
4. Elasticsearch server (yea, only one right now, you know, few users)
5. One linode running RabbitMQ
6. The linode running NGINX that sits in front of the app server and does all of the reverse proxying
Also,
7. The linode running the marketing site (wordpress).
I know, I know, I'm a nerd and just couldn't help myself with the architecture. Hey, at least it should be fairly scalable.
You also don't need the linode running nginx, with so few users put it on one server.
Finally wordpress should be $5/month or less.
Right there you could drop at least $15 / month.
Kind of not even worth thinking about when you're a developer and should be internally billing yourself for $100/hour+.
Also when you're starting something you can't bill yourself anything mentally. Else you'd go out and be billing someone else, you'd likely make more money. In part cutting costs is important because it's actual savings, i.e. imagning billing yourself doesn't produce real money.
Better to save money and expand if and when a paying customer shows up.
For running a successful business, I think you should try to always have the others in mind when you work on one, because that’s how you can find product/market fit (otherwise it’s mostly luck, and/or you had perfect hindsight of your market).
If he gets a ton of customers, he'll need to expand anyway and will waste even more time setting things back up.
- Maintenance costs will be a limitation on how many different experiments you can keep running at the same time. If you consolidate everything on the same machine, and still has 98% of the machine for the next experiment, you will keep your first one running even if it has low profitability. If you need $120/month just to keep it running, you will be tempted to close it down after any new idea appear.
- You are assuming that the OP lives in a developed country and has a well paying job there. You are also assuming he has no risk of being unemployed for a couple of months.
- All that is probably dwarfed by taking a couple of hours a day for reading HN. So I should go back to my project and stop thinking about unasked advice :)
And I'm in the US and not going to run out of money assuming I can keep my day job :)
If you're going to dockerize, at least spread things over a two node swarm so you find these issues early.
The free trial is fairly prominent on your home page. On your pricing page, all of the free trial links are below the fold for me: https://imgur.com/a/4qsaf
You might want to move the free trial buttons higher, maybe right below "How much does Contabulo cost?"
Also, you can put cost in lowercase.
(That goes for anyone reading this -- happy to see if I can help, to test out my own idea. Not ready for a bigger announcement, but ping me via the site or travis@leadnexus.co if you want to give it a shot.)
Link - https://www.leadnexus.co
Might want to fix this passage:
> We use an emphasis on optionality, machine learning, and a dedicate to results to get you more users and leads. We don't want you to pay us for unless we improve your results.
Maybe "Stop employee brain drain"? That would at least be relatable to people who have heard the phrase brain drain before.
It uses cards, so I suppose it superficially resembles Trello and similar agile board-esque tools, but it definitely has a different feel to it.
I actually got the idea for the basic layout from Pintrest (I originally had a masonry-like layout to the cards, but switched to CSS grid -- makes sorting/searching/scanning for something specific easier, IMO).
I'm not entirely sure from a brief scan - is it team wiki software? Is it sorta like trello cards but for archival/searchable org information?
As someone who is actually looking at team wiki software for a couple startups and nonprofits I'm helping I can tell you that my threshhold for signing up for a trial (even no CC required) is pretty high so don't let that discourage you.
That's basically it. The idea came to me after I had become frustrated with enterprise wiki/KM software. At the time I was being forced to use Liferay, though I've also had to use Confluence, MediaWiki, and Sharepoint (the worst thing in the universe) in a corporate setting, none of which I particularly liked.
Perhaps a screencast/animation showing the product in action could demonstrate its not-a-Trello-clone-ness better than still screenshots.
This is purely my opinion, so please take it with a large grain of salt. I'm not a fan of videos and won't last long enough on a site to sit through them unless I've arrived there from a referral (there is too much software out there that does the same thing, so time is at a premium). I'm more of a fan of descriptive workflow/image showing what the software does and keeps the value prop simple.
As an example, this marketing site impressed me greatly and I actually took the time to read through the different features as it was easy to follow and I didn't feel flustered by each of the feature explanations: https://www.contactually.com/how-it-works
My only gripe, there is no cohesive single blurb explaining how all these features fit together in a complete package. Their tagline at the top is weak, but visually they've nailed it.
Also, having to sign up for a demo kind of sucks and slows down the process of me getting to try out your product to evaluate if it meets my needs. I'd love for our industry to move towards a "here is a sandbox, have fun for a few minutes" model which would be completely painless for folks evaluating the tool. After a couple of minutes it could nudge you to sign up for a full trial account.
e.g. Maybe replace $29.99 for 10 users with $2.99 per user (with a minimum sign up of 10 users)?
I know Jira, for example, has a low rate package for the first 10 users (basically like a paid trial), and then the pricing switches to per-user and it ramps up quickly.
Good luck with the service!
LOL, that could be a problem. I could at least draw attention to the fact that these are packages and NOT per user pricing in a more obvious way.
- Get listed in any/every saas (esp b2b) directory I can find (haven't done producthunt yet, though).
- Send out cold emails (not a lot so far). I'd start making cold phone calls if I wasn't sitting at a day job during business hours every weekday. I could try postcards..?
- Post to online formus - kind of like I'm doing here :)
I'm really trying to avoid resorting to PPC ads, but it might be time to do that.
I'm also thinking of making it free for academic use, just to get some folks using the product and talking about it.
Also, the thought to find a partner who knows bizdev/marketing/sales has occurred to me.
I think paid ads is a pretty good approach to validate the product and copy, even if it's not a viable strategy in the long run.
Making it free for academic use makes sense in more than that sense. If you're lucky you might get a .edu backlink from it, which is valuable for seo.
Here are some things that went through my head:
- I don’t like the graphic design
- evaluating if this is good will take us more than a month
- I’m worried about lock-in. If, after a few months I discover this isn’t for us, do I need to keep paying not to lose my data?
Of the landing page or the product itself? The landing page is an easier fix :)
> - evaluating if this is good will take us more than a month
That's quite possibly true. Wikis take time to populate and only become useful if people commit to doing so. The problem is how to balance:
- Giving users time to evaluate the product
- Revenue
> - I’m worried about lock-in. If, after a few months I discover this isn’t for us, do I need to keep paying not to lose my data?
Valid point. I do plan to add a data export feature at some point. I'm wondering what the most useful format for such a thing might be. CSV? XML? JSON? SQL?
Conversely, I still haven't thought of a sane way to allow for a mass data import... but I'd like to.
I'm personally not a fan of time limited trials -- I think feature or usage limits are better, especially when you don't have any users yet, and you need people to use the app and give feedback...
However, just between you, me, and the internet, I actually haven't enabled the logic to lock trial accounts out at 30 days. Because I'm still unsure about it.
Maybe there's just so much variance that it's impossible to give a good benchmark, but even still, 2% seems low.
I also suspect that marketing has a lot to do with it. A company that's much better at marketing than product will be better at getting someone to sign up for a trial and worse at converting them, so maybe their numbers would be down in the 2% range. I feel like I'm the opposite (bad at marketing, but pretty good at product)
Also, the idea that a company is “better at marketing than at converting” isn’t really the correct way to look at it. Basically the math says that you want to keep increasing the width of the net you cast as long as it is profitable. In some cases, you will find a profitable group to market to, but the reasonable conversion rate for that market (i.e., people who end up loving or product) is just naturally lower than your high-conversion group.
As a simple example, someone may have a very technical finance newsletter that they sell to finance professionals, and they covert that group at a high rate (and a high price). This newsletter can probably also target HNW individual investors profitably, but they will not likely have the same conversion rate.
Also think about how many of those signups are for "products" that never get delivered. Some side project that is thinking about charging and the dev never bothers implementing, some startup is thinking of switching from per-client contracts to a self-service model and either doesn't make the switch or dies/gets acquired before they manage it. None of those situations are Stripe not meeting someone's needs, and a single developer can create an arbitrary number of those trials throughout a year.
> 2%+: extremely good
I think that is the percentage of website visitors who eventually become paying subscribers. Eg. 10% of visitors sign up for a trial and 20% of those trial users pay for a subscription at the end of their trial period.
Patrick - can you confirm this?
Coincidentally, Indie Hackers was acquired by Stripe via patio11.
Feel free to get in touch if you want a sounding board. As I get older I'm more concerned with being useful, so I'd be happy to be a sounding board/alpha tester.
https://www.udemy.com/the-build-a-saas-app-with-flask-course...
I found it very well made and you might ship a simple SaaS within a week, including Stripe subscription. You'd also learn about Docker deployment there. Themeable using Twitter's Bootstrap as well.
Now just get an idea for a profitable offering and you are golden! ;-)
Maybe there are clear loop-holes.
I'd really appreciate it.
Edit: I see you updated it. Thanks!
Course author here. Thanks a lot for posting this (and for signing up).
But, it's worth noting that if you buy the course on my platform at https://buildasaasappwithflask.com/ there are additional perks you won't get on Udemy.
For example I'm in the process of adding a new bonus section to the course that goes over building RESTful APIs with Flask. I've already released the source code and 1 video for it on my own platform but this will never make its way over to Udemy.
I'm going to be adding some front-end related bonuses too (only on my platform). Plus you get better support and I'm even thinking about doing things like recorded office hours.
If you don't want the bonuses / updates and only care about the cheapest price possible, please use my Udemy link[0] below for $10.99 because otherwise Udemy takes 50%. I don't want to sound like a complainer, but yeah, it took me 4 months of real life time and years of experience to create this course. I can't afford to keep making courses on Udemy when I see $3-5 per sale.
It's also worth mentioning those Udemy "discount tricks" are out of my control. I can set the price to anything within reason, but ultimately Udemy pushes courses out for $11 all the time. It's partly why I'm looking to remove all of my content from there in the future, but building my own audience is a long process. :)
In either case, any support is much appreciated. Thank you in advance for anyone who signs up.
[0]: https://www.udemy.com/the-build-a-saas-app-with-flask-course...
It's going to be tricky to find a good balance (the bare-bones Udemy version still needs to have high value), but it's doable.
I have a lot of ideas this year for new content and I'm going to experiment with paid courses, free courses and even not putting some courses on Udemy just to see what happens.
Also interesting to hear a creators side of Udemy. I've used Pluralsight before where you have a set fee for everything. I wonder if something like that might work better for you as someone authoring these courses?
Pluralsight is ok but they are only interested in very short courses in a tech space that isn't already crowded with content. That makes sense because they are a membership site where the perceived value of individual sales isn't that important. Where as on Udemy, longer courses are considered "better" because each course is an individual transaction and a course with more content is perceived as more valuable (even though I don't technically agree with that, that's what their data shows).
This Flask course is about 10 hours of video for reference. Some of my other courses are in the 3-5 hour range.
I'm thinking I could do 10 hours as an hour or two a day over a few weeks. I need to decide if it's the tooling holding me back or the MVP. Easy to focus on technology, pitting this against that when really, anything up and working is key!
Maybe that's something they are pushing for moving forward.
For something like this Flask course, I've had people tell me they cranked through it in 1 day at 1.5x speed, and others have taken it multiple times over the course of a few months and still reference it a year later.
I think it really depends on your level of experience. I'm a big fan of "doing" and while the course does have a lot of watching, there are self guided homework assignments to make modifications to the code base (they are presented as real life feature requests).
If you did all of the assignments, there's probably 40 hours worth of content to go through, but those assignments are really your chance to get your hands dirty and start practicing what you learn.
A lot of people also build up their own app side by side while watching, which is a great way to follow along if you already have an idea. It takes longer, but IMO the goal here is to become a solid developer, not rush through it and do the minimum.
Thanks again for your comments and you discount link!
However, this comes to mind: https://elsyms.com/the-art-of-over-engineering-your-side-pro...
This was followed by a discussion on HN which a lot of people enjoy over-engineering side projects because they use it as a sandbox to learn or test different things, and I relate, so I was looking for as much material on including as many buzzwords as possible on a saas app/business/tool set(microservices, kubernetes, docker, UI frameworks, mobile app, graphQL, whatever else is out there), I'm pretty sure I could get each piece from different sources, but is there someone who covers overblowing everything? Or maybe one could build a curriculum out of several different online courses?
In your case, I think you're best off learning each of those things from separate courses / learning material. Mobile app development and Kubernetes are simply not related at all.
This Flask course focuses on building a classic web app using server side templates. It happens to use Postgres and Redis while also performing background jobs with Celery.
To me that's the bare minimum for building a web app with Ruby or Python. Web app + DB + background worker + sprinkles of JS on the front-end. We use Docker Compose to get it all running because the alternative is rolling your own Python environment from scratch which is IMO more time consuming than using Docker.
That's also a good article you linked and I agree with pretty much everything they wrote.
I think it's more important to ship your app than try to incorporate every buzz word for the sake of doing it. I'll admit, sometimes learning new things is highly motivating but at the end of the day, the tech wins REALLY need to be there for it to make sense.
For example I choose not to use Kubernetes in production because 1 server deploys with Docker Compose is very easy to reason about and it works well, even for decently high traffic. I treat ops like I do code refactoring. It's important to get something working, and if you ever get to the point where it becomes a problem, then refactor.
The interesting thing there with ops is, if you have a SAAS app running with 800 customers and 50 of them are on concurrently, do you really need a self healing auto scaling Kubernetes cluster on multiple regions?
Probably not. Those 800 customers might be generating you $49 / month each or $39,200 per month in revenue and something like that could be running on a single $40-80 / month server with a Flask set up (or even Rails for that matter).
In my mind, I'd rather spend my time figuring out how to grow from 800 customers to 8,000 and even then you could probably vertically scale your server, but at this point you're rolling in so much cash that it's all irrelevant. You could just pay someone $100,000 to fix your scaling problems over the course of a few months (without outages) and continue growing your business.
Basically, front load your time in making your product really cool and successful, then invest the time (or money) into scaling when you need it.
I agree 100%. ~premature optimization is the root of all evil~
However what I meant is, what if building and iterating is the goal, not the means to the product? When you're building a SaaS app you have to worry about market fit, sales(as the article talks a lot about), if you're not concerned about finding users and growing, a side project app can be a great way to learn and show knowledge.
Perhaps the classic web app with server-side templates is the quickest way to launch an MVP, but what I want is a way to build something integrating as many different things as possible, a lot of companies will want to see your GitHub, if you can present a largely-complex yet well-designed application where you can showcase front-end development, backend APIs, containers and what not you're one step ahead.
I want a sort of sandbox to play with, not an actual product, would be interesting as a multi-part series course(start with simple web app, keep iterating, separate web app from server code, remove bootstrap or other UI kits in favor of self created styles, incorporate mobile, watch app, whatever you can think of. This could be a good exercise in writing maintainable applications.
Purchasing this for a saas idea of mine.
Funny i was meaning to learn flask the right way
I'm a B2B guy - so I never build anything until I have ~1M~2M/year in soft commitments. Then as I build it, I try to get the soft commitments to sign-off on early purchases (at a discount).
Usually - where it gets hard - is customer support if the "B"s you are selling into have a lot of employees that need a lot of handholding. That is a 24x7 hell that you don't want to deal with (but that I don't know how to avoid).
I'll not be in the position of getting anywhere near those figures you shoot for and considering this will be my first, I'm keeping my feet firmly on the ground. I've just spent all my career to date (15 years +) building products for other people that I feel I know enough to do my own. Again, it all comes down to finding that need. This is where physical networking and schmoozing pay off, sadly not my forte!
I found one. They didn't get it. I ended up quitting: "Fine - I will do it myself".
I remember the first meetings I had a 6.30am or 7.00am at breakfast places with VCs... They would listen and then (essentially) pat me on my head and say: "You're a nice boy. Go back to being an engineering cube-monkey".
It was so frustrating. I did not know what I was doing. I was a fairly competent engineer - but I did not know the code-words for the VC-world or the business-world (and there is definitely a tribal language).
Finally - mostly by luck - I found a guy to partner with. We ended up raising $100M, before we got caught in the back-wash of the dot-com implosion (we weren't a dot-com, but it didn't matter).
Now - I know how to speak their language to them. But I will say: It's hard. The only way to learn is to get into it. Go try to sell. Fail. Get dirty. You'll figure it out.
I believe in you! :-)
EDIT: I do remember this. This was the 90s, but I remember that I pitched customer-types and investor-types about 2000 times in about 350 days (a year). I am an engineer, not a sales-type, so this was uncomfortable. But I updated my/our pitch deck after every meeting. You do get better with practice. It sounds cold, but I would say: "Hit The Road".
Really is good to hear your words of encouragement.
IF I knew then, what I know now - I would be too afraid to start. But all progress is made by people who are not too afraid to start. I wish you all the luck and fortune in the world.
I found that it was like a fraternity, though. I only learned it by hanging out with them. Kind of like how doctors call bruises 'hematoma's. They all know what it means, but it wouldn't occur to us normies to call it that.
If that book doesn't exist, maybe somebody should write it!
edit: My details are also in my bio if you want to shoot me an email.
We ship first and then announce dates because down the other path lies disaster, but LLCs are a great way to incorporate many tech businesses, and Atlas aims to incorporate most tech businesses.
Great blog, but part of me finds it sad that such an intelligent person spends a huge chunk of his life working on creating Bingo Cards.
In 2011, while deeply ingrained in converting justin.tv -> twitch.tv, the same sort of decision came up: should we build our analytics or should we buy it (mixpanel in this case). This time it was obvious: buy it.
In the time from that first decision and the later decision at Twitch I was able to fully appreciate why you buy, and Patrick nails it in the first few sentences:
> Unfortunately, many entrepreneurs discover this body of practice the hard way, by making mistakes that have been made before, rather than by spending their mistake budget on newer, better mistakes.
also:
> Customers love SaaS because it “just works.” There is typically nothing to install to access it. Hardware failures and operational errors, which are extraordinarily common among machines which are not maintained by professionals, do not result in meaningful data loss.
I've often retaught these points to folks: "Our job is to deliver a product to our users, they don't care about the ancillary product we use to deliver them our primary product. Buying Saas is like hiring pro's to do a job at the fraction of the cost of hiring pro's to do that job".
Or as Matt Brezina (Xobni & Sincerely) likes to say: Hire via API ( http://www.mattbrezina.com/blog/2011/08/hiring-via-api/ )
I'd like to underline two points, in case anyone reading this is thinking about starting their own bootstrapped SaaS (I guess many HN readers are):
* The long slow SaaS ramp of death is true. SaaS businesses, especially bootstrapped (and cash-starved) ones do not grow quickly. It takes years, as in more than one, and possibly several years.
* Apart from product-market fit, the biggest problem is marketing. Contrary to what one might expect, it is extremely difficult to get one's product in front of customers.
So, set your expectations accordingly.
RethinkDB is used for two reasons:
1. It's the only database that provides changefeeds that I need to implement real-time updates for users. Complete changefeeds, as in: get an initial state and then updates.
2. I wanted to easily solve replication, fault-tolerance and scalability, RethinkDB gets all of them right, at least for the levels of scalability that I require.
https://www.cncf.io/blog/2017/02/06/cncf-purchases-rethinkdb...
"There are, broadly speaking, two ways to sell SaaS. The selling model dictates almost everything else about the SaaS company and the product, to a degree which is shocking to first-time entrepreneurs. One of the classic mistakes in SaaS, which can take years to correct, is a mismatch between a product or market and the selected model to sell it on."
From helping build a SaaS company for the last couple of years, I can tell you that knowing which kind of "touch" your product is very very important. Really important.
There are a lot of SaaS markets where the customer needs high touch but can only pay low touch prices. That's not a fun place to live, though it can be a good place to start and then move upmarket. I remember seeing that grid of high/low touch and high/low ACV outlined somewhere, but I don't remember where.
This just seems like a really bad place to start. Do you have an example where it worked?
The reason why it might be a good place to start is because you can find enthusiastic customers that are ill served.
ONE example that I think applies and is Interesting: domain name registration. The entire business model at GoDaddy around domains is the hope that they would be registered and left unused. At such a low price point ($1/month billed annually) the cost of cancelling was often not worth it. But if even a fraction of those domain registers decided to need a website or email...Jenny bar the door. The support required to walk clients through DNS updates and MX records would flip the business on its head. GD has invested a ton to making these processes more seamless but it wasn't long ago that if you didn't know how to use FTP or cPanel (as example) you had to get help from an actual person.
This runs into some tricky ground. Consider the fact that many customers who do not churn may also have not used the product, at all, in a given month. Given the difference between "existential risk" and "profitable enterprise" is a 5% change in churn rate, these customers may make all the difference!
How does a company balance reducing churn with ensuring that customers who (perhaps temporarily) have dis-engaged can easily turn off the software? For example, how long of a period of inactivity should a company wait before asking a customer if they would like to unsubscribe? Do any companies actually do this? Should we expect them to do this given that doing so may kill their entire business?
In the US almost everything is membership-based, so a paying member who doesn't show up is free money until they cancel.
But there are other places where it's more flexible, for example my gym has monthly passes, dailies, and 10x or 20x passes. The 20x is the best deal if you miss a few days a month due to travel.
None of this has any recurring billing.
I'm sure even that gym has a bump in monthlies in January and May/June but with their setup it seems much more in their interest to have everyone actually coming to work out, else they might just not bother to buy that next monthly.
Good luck trying to get a one-week pass to Equinox without pretending to be a local who's interested in joining.
OTOH I know an awesome gym in LA that is perfectly happy to sell you a week pass if you're visiting. (Maybe that's a film-industry thing.)
That's exactly how it works.
> How does a company balance reducing churn with ensuring that customers who (perhaps temporarily) have dis-engaged can easily turn off the software?
The ideal model in my opinion (but that one is obviously not going to maximize profits/revenues) is to stop billing if the customer has not used the product in 30 days.
That way there is a balance between payment and performance, maybe at some point we'll see laws to enforce such a setup.
And those providers will be punished by consumers for it.
One angry customer can cause all sorts of damage.
It might be better to separate the two use cases as: "data at rest" and "data in use" like Amazon does with S3 where they charge separately for storage and transfer costs. If you do not access your data stored on S3 throughout a billing period, your invoice will only reflect those costs -- your usage costs will be stated as $0 for that month.
- It's easier to get direct and indirect (metrics) feedback that you need to actually improve their experience.
- These are the users who push your product in areas you possibly hadn't considered or prioritized and can often have sub-optimal experiences.
- Large teams using your product is one of the few viral channels available to B2B saas. People change jobs and say "you know, at my last place we used..."
- You can probably grow their ARPU.
You should definitely track people who deactivate or never log-in, but it's a hard thing to optimize.
[0] https://get.slack.help/hc/en-us/articles/218915077-Fair-Bill...
Absolutely.
Don't forget that these customers may just file a chargeback through their bank. I did this with a service called Classpass which misleadingly kept you signed up without any notice. I and my partner both filed chargebacks and overturned 6 months of subscriptions.
That sort of thing can really harm a SaaS on a number of fronts and so IMHO they should ask the customer after one billing cycle and no activity.
Chargebacks are a real dick move, and should be used as a last resort if the company gives you any trouble when cancelling. Otherwise you're literally stealing from the service, for example your patronage cost the company 15*6=$90 in just chargeback fees (Stripe) because you couldn't be bothered to cancel your plan online in a minute. I think most SaaS companies would be happy to not have you as a customer.
I would add a couple of supplementals unique to 2018 for those of us raising capital in a SAAS or looking to liquidate:
1) The "SAAS Napkin" for 2018, a survey of ~50 Series A / Series B funded companies that have shared with regard to growth / churn / etc. Links here https://www.producthunt.com/posts/saas-funding-napkin-3 and explanation here https://medium.com/point-nine-news/what-does-it-take-to-rais...
2) The fascinating rise of Private Equity companies as a liquidity / funding option outside of larger co Acquisition / VC money as observed by the founder of Pardot (~$100m exit to SalesForce) - https://davidcummings.org/2017/10/03/private-equity-as-the-s...
I've been using Stripe and Stripe Atlas since 2016, and it's helped me grow my business well. Slowly iterating. My particular tactic is to give users a full refund - every month - they give me feedback via a survey:
It's actually been super nice because people are super willing to pay after I build out the system the way they want. They then tell their friends and so on.
Then there are websites I built like:
Which only has a 3% conversion rate form registered users to paid users. Apparently, that's pretty good as well... People love it and I haven't touched the website in 18 months -_-
It's clear why SaaS is superior in that aspect, because it's 100% automated, makes money, and I don't even touch it. Updates are nearly completely automated on Easy A, and https://projectpiglet.com (being completely in development) requires a bit more, but also completely automated.
Nice, I'm gonna steal this idea!
Customers tend to blame themselves for forgetting the feedback and eventually some users are like, "Hell, this is exactly what I wanted" and they'll pay full rate.
Our largest client, Anthem (formerly known as WellPoint), represented approximately
17% of our revenues for the year ended December 31, 2016, while no other clients
represented greater than 10% of our revenue.This isn't exactly SAAS, but there's some overlap. Has anyone ever seen (or tried) a full free trial which lasts 2-3 days?
I currently just have some demo videos, but it occurs to me I might increase conversion if I just let people into the full thing, let them have a taste, and then ask them to pay if they want to keep access.
I could limit it by time or percent watched.
Design+Code is a pretty well-known course for designers that want to build iOS apps. The previous version of this course was a one-time payment of $50. For the newest version he's moved to a subscription with a 7-day free trial. However, you do have to add a credit card for the trial. https://designcode.io/
I could try maybe a week with a credit card option on the longer one. Or test a "percent complete" lock on the shorter one.
It's just downright ridiculous/shady.
Ridiculous since there's no way I'll be able to make an informed decision in 2-3 days, especially since there's no chance I'll dedicate 100% of my time to those 2-3 days. When I'm done looking at the several options available, I'll have a meeting showing my findings and running through a guess which software isn't going to have a live demo.
Shady, because I know I'm not going to get a full picture in 2-3 days, but more importantly, they know I'm not going to get a full picture in 2-3 days. My assumption will always be (and is usually correct) that on the surface things are fine, but if you try to use any of the more advanced features/integration/whatever actual use, you'll run into trouble.
If you actually have a good product, why fear letting people see how good it is? Let them try it out, integrate it into their workflows enough and see enough of an improvement that they don't want to go back.
I sell 5-24 hour long online courses. A two week trial would let someone see everything, and would leave the user with no reason to purchase.
This is why I haven't done full free trial yet. Because 2-3 days seems short. But I'm wondering if it counterintuively might be optimal, by removing friction to trying the course.
I.e. a 6 month refund window may have a lower overall refund rate than a 1 month window.
It gives users who are on the fence about the value of a product more time to see how they've gotten value out of it. It also gives people longer to forget to ask for the refund.
The only reason some companies have a "1 year" refund policy instead of "lifetime/anytime" is because of issues like credit card merchant processors being uncomfortable with the credit risk that creates.
There are still so many opportunities to reduce IT costs through SaaS. I've been in software a LONG time, and I think this is a golden age, with things like AWS and Azure and third-party horizontal services for pretty much everything. Just find your niche of companies that have issues that nobody is addressing. Help them automate tedious and time-consuming things like reporting and dataflow. Help them with regulatory compliance. Think of it as consulting where they also pay for platform services.
I also take issue with "investors love SaaS". The margins just aren't high enough to make it worth the risk. You might find an investor willing to do a deal for cash flow. But I think this is like Stripe - if your thinking VC capital, you're already off the mark. Your customers need a solution and they will be your investors.
> [SAAS..] spend less than 5~10% of their marginal revenue per customer on delivering
This is really, really not realistic. Just billing through Stripe will cost you 2-3% commission.
I was involved with a financial SaaS and I couldn't believe how many sub-services they needed just to keep the product alive
Interestingly enough in December we increased our prices by quite a lot (percentage wise, $2/month to $6/month). That month we saw an 8% churn rate, and January 6%, and this month looking like a bit less. It's going to be really interesting to see what happens in the future.
The jury is not in yet, but it feels that the voluntary churn is a lot less for the customers paying more, compared to the lower price point.
I noticed the same. Our $29.90 plan churn is 3x higher than our more expensive plans.
Bill Janeway offers a well-written deconstruction of the "impossibly" part of the author's "impossibly attractive" characterization of SaaS here:
https://wtfeconomy.com/enterprise-software-death-and-transfi...
(from 2016)
For something to be SaaS, the software has to be in the cloud.
Creative Cloud is mostly light touch product with an few large companies and agencies requiring high touch.
I've had the $10/mo Photoshop+Lightroom bundle forever. I almost never use them, and when I do it's definitely not for pro-level stuff, but I find it worth the price to have these tools available when I need them.
Adobe, on the other hand, really really wants me to get into Behance, watch this or that instructional video, take a survey, read their blog, etc.
But if I got that engaged with their ecosystem, I'd surely end up with support tickets and so on, but I doubt I'd give them any more money. I get that it's worth it to them on average, it just feels weird sometimes as I'm a dream customer at $10/mo.
Self-serve items are generally considered low-touch. Knowledge Bases, Documentation, Instructional Videos—these are all things that are created so the company doesn't have to spend time with you. Support is considered a fall-back when none of those options work.
High-touch means a Customer Success Manager is assigned to your account. Generally the CSM will try and setup monthly or quarterly check-ins to:
—Troubleshoot any problems
—Spot and address churn risks before they arise
—Inform the customer about product changes
—Handle renewals (Although this is sometimes a sales function)
If you're paying $10/mo and not sending Adobe any support tickets, it sounds like you're the perfect low-touch customer.
Right, I'm the perfect low-touch customer right now, and I get that the self-serve things are also low-touch.
So I guess burning a few hours of customer support time would not move me into the high-touch zone. Got it.
SaaS stands for Software as a Service, which means begging customers to make a one-time decision to start a predictable subscription in exchange for regular new features and bug fixes.
The alternative is begging customers to make decisions to upgrade to the latest release multiple times, even after they purchased the older software. Customers on older versions spend a lot of time downloading updates to security issues, comparing to competitors, and deciding if this is the right time to upgrade or to wait for a sale.
They basically have outsourced enterprise sales to their customers.
As someone else stated in another thread here, $100k+ deals don't happen because some employees use your product. It requires an enormous amount of sales and marketing infrastructure — and just plain old time — to rally someone else's organization around the change that adoption of your product entails.
It's also written very clearly and candidly (although admittedly it's a bit of a self-congratulatory pitch for Stripe).
For SMBs, there's a self service model that's low touch but for enterprises, the sales + customer service is very high touch and requires a lot more customization.
BI tools such as Periscope, Looker, Mode, Tableau, etc are also a bit of a hybrid. Usually starts off with an individual playing around or looking for a tool (pretty self service), but a full company deployment is much more hands on and high touch.
Following the framework that Patrick provides, odds are that any company that has "sales engineering" or "integration engineering" for a SaaS will likely be high touch (unless they're doing it wrong =D)
Trade shows, performance marketing, affiliates, content marketing, retargeting, account-based ads ... those all work well.
In a previous company, we built a SaaS platform (based on Odoo, a kind of semi-open-source web version of SAP) which allowed clients to purchase changes to any part of the application. Unlike in a typical SaaS, each client had its isolated copy of the app/database/etc (though all running on our cloud), so they could change anything. Some changed nothing, others have whole new components and business flows.
My current (consumer) startup has a churn of around 25% the first month, then dropping to almost nothing after a few months. Using a single churn number doesn't even come close to approximating real behavior.
ps: we sell project management at https://www.paymoapp.com - every time someone cancels or deletes an account we show them a form where we collect data.
- Don't position yourself how you normally would if you were going for a new job and trying to maximise your income. No "senior developer with experience in python, node, etc"
- Do position yourself as just a general "software developer". I said contractor before but I wouldn't (didn't) even make it look like that. More like a small agency. If they're completely outside of the tech industry (what you want) then they're going to be wanting someone to just give money to in exchange for solving their problem, not someone they're going to have to manage. Instead of hiring Dave by the hour, they're hiring "[town name] Premier Development" on a fixed project basis.
- Be selective with who you take on. Again, you should be positioning yourself pretty cheap to the point where if this wasn't basically an exploratory exercise for you then their project wouldn't be worth your time, so you don't want to get stuck doing work that isn't a potential SAAS for you down the line.
- You want them coming to you trying to get something done for $15k that would normally cost $100k+ to build. Then you say "hey, if you're willing to be my test dummy/case study/first customer, I'll build it and give you a licence for $10k"
Also, why work as a contractor if you already know what SaaS the company wants? And if you don't know what SaaS they want, how do you know you want to work for them to find out?
Even if that's not the case. If it's genuinely out of their price range to get built custom just for them, which it almost always will be, then they should be willing to collaborate just to get it at all.
Sorry, I guess you don't ever need to do any actual contracting at all if it's just exploratory. I was writing from experience as half of a "software development agency" so we did do custom work, I just noticed that a lot of what we were building could easily be turned in to a product.
I will say though that actually doing some work for them, basically getting carte blanche to poke around their workstations and getting rundowns from their staff on how to achieve their tasks, reveals a lot of opportunities. You come across things like them moving over to a different pc. "Oh we need to use this because it has our X on it, which we use to do Important Task. It's not made any more so we can't get a new version".