This is hidden work for running a function SaaS, not launching one.<p>The trick to launching a SaaS is picking the right things to _not do_. Some of the fun of a SaaS is iterating on everything from product features to pricing to support tooling. It's very difficult to get pricing, trial periods, and billing model right on the first try. So usually you're better off doing less of that, and figuring it out later.<p>And you really don't need a crazy sophisticated drip email setup. Doing email marketing for existing users and new signups right is something that will get you incremental gains. If you convert 5% better when you have 1000 signups per month, you'll be happy. If you convert 5% better when you have 10 signups per month you'll never even know.<p>Silly as it sounds, if you spend more than an hour or two thinking about sales tax before launch, you're wasting time. Screwing up sales tax at launch will not kill you. _Skipping sales tax entirely_ at launch will not kill you. In fact, very little that can go wrong will kill you. You're probably going to die because you didn't make enough go right.
Yes, these are the "features" that really bog down the excitement when trying to launch -- user invites, user profiles, billing, transactional emails, password reset, file upload, PDF conversion, free trial capability, coupon code capability, shared accounts, PERMISSIONS, etc. Then you get to the next level -- search, caching, deploying.<p>Not exactly in the same vein as the others, but I've never seen soft-deletes done really well either i.e. the user can "delete" something but it still lives in the database. It's one of those features that sounds good but when it comes time to implement, it ends up being more trouble than it's worth.
This is why I always scratch my head when I hear about early stage startups say "Oh, yeah, we built our MVP and put it out there and got thousands of sign ups, then we started figuring out how to build a billing system to handle subscriptions..."<p>I call total BS on that. Trying to shoehorn even something like Stripe into an app that has existing tables for users and companies, and ensuring it WORKS (including handling webhooks for payment confirmation, invoice generation, failed payments etc.) in less than 3 or 4 weeks is setting your developers (and accounts department) up for failure.<p>If you are selling an enterprise level SaaS, then things like billing history, generation of invoices for your customer's accounts department, handling lapsed subscriptions gracefully, handling changing of credit card details, giving the option of purchase orders or using other forms of payment etc. ALL have to be factored in and built before you even sign up your first customer. (Yep, we even lost a customer during the trial once because we didn't have the ability to generate a PDF invoice for them 'in app').
This part is so true:<p><i>"I’ve built and sold software for the Mac and iOS. Those products all had simple billing systems. But with a SaaS, you need to handle all of that yourself. You need to handle payments, and invoices and everything inbetween."</i><p>Edit - both Spark (Laravel) and Bullet Train (Rails) will help with a bunch of this stuff:<p><a href="https://spark.laravel.com/" rel="nofollow">https://spark.laravel.com/</a><p><a href="https://bullettrain.co/" rel="nofollow">https://bullettrain.co/</a>
And now, if you're marketing or selling to people in the European Union, you're expected to have a deep understanding of data privacy law to negotiate GDPR, ePrivacy, and a host of other (often contradictory) regulations.
In my experience, billing/invoicing/payments integration is the easy part of launching a SaaS. It's just code, and most of the work is already done for you in the form of libraries. Getting your product 'out there' and getting people to sign up, THAT is the hidden work if you ask me.
"focus on my product"? where do you draw the line around what is your product and what isn't? if you exclude everything around it, the actual nucleus of your product had better be pretty damn amazing to standout from all the other people with an idea.<p>This is not hidden work. These are decisions. In theory every part of an offering could be 3rd partied, but they will all want to be paid. at some point you have to write something yourself either so you don't have to pay someone or to do it better than what everyone else is using.<p>having said all of that, chargebee is pretty awesome.
> You need to handle payments, and invoices and everything inbetween<p>Back to July 2017, when we launched PixLab[1], we opted for Paddle[2] since implementing billing, invoices, purchase orders, refunds, etc. was the last thing we want to code from scratch. We were a small team of C/C++ engineers and ML scientists with no clue on billings.<p>Not only Paddle did handle all the payment stack smoothly, they do also offer Paypal in the same payment modal which was a great boost for our sales since most Europeans customers prefer to use that method. One drawback is that they took 5% for each sale/subscription instead of the 2.9% that Stripe takes.<p>[1]: <a href="https://pixlab.io" rel="nofollow">https://pixlab.io</a><p>[2]: <a href="https://paddle.com" rel="nofollow">https://paddle.com</a>
This kind of thing is top of my list when I think about how little enthusiasm I have for taking our current on-premise, installed enterprise software, and trying to turn it into a SaaS. As a small company, we've barely got the horses to handle the much-lower levels of complexity involved in building and supporting a mostly monolithic application, where we can offload all of the ops and deployment and first-line support duties to our customer, once they've got it installed and running.<p>I just start checking out when the idea of creating a cloud-hosted, multi-tenant version of our product is raised. Scale, security, liability for data protection, 24/7 operations support, billing, and metrics for billing, all this stuff we don't currently worry much, if at all about, would become first-class concerns. Unfortunately some people seem to think you just wave your cloud wand at things, and <i>poof!</i> everything is magical.
Are there any SaaS that do all these things for SaaS?<p>Especially for Germany/Europe?<p>If not, why not? Sounds like a good business opportunity.
These are exactly the pain points that Taylor Otwell (creator of Laravel, a PHP framework) tried to solve with Spark (<a href="https://spark.laravel.com/" rel="nofollow">https://spark.laravel.com/</a>).
It was actually just updated to v6.0 yesterday so it's definitely a good time for considering it.<p>I personally used it for a couple of projects and I'm really happy about it. It probably saved me a few weeks or a couple of months of tedious work!<p>Workstack
<a href="https://workstack.io" rel="nofollow">https://workstack.io</a><p>BrandOn
<a href="https://brandon.video" rel="nofollow">https://brandon.video</a>
These "features" are the whole reason you're building the app--so you can collect money (I assume). At my current company, we've spent the last four months rewriting just this part (moving to a different processor) and we're still not done. Our product lineup is not even very complicated, but working with payment processors is quite hellish. Considering this is <i>the most</i> important part of the application, this should always be considered ahead of time and plenty of time budgeted for it. There's no way you can try to speed this up and still implement it properly.
Seems like a this could be a SaaS all by itself, like the backend of Stripe or something. You build the UI and this thing plugs right into it does all the nitty-gritty.
The biggest challenge for us was a bunch of small tasks that we HAD to do. It was driving us nuts until we realized we could either find a service, make it dead simple (MVP style) or just not do it until we absolutely needed to do it. We worked on being customer obsessed with the absolute list. We ended up with a great product. I can't take full credit, took a lot of advice from great blogs and Lean Startup (the summary is better if you don't have the time. <a href="http://amzn.to/2H8isRI" rel="nofollow">http://amzn.to/2H8isRI</a>).
This is exactly right and largely why I have not launched any subscription webapp on my own (b2c, b2b). I haven't yet invested enough time for an adequately starter backend infrastructure.<p>I should look into Laravel Spark tho', I hadn't heard of it before and it looks like it might be just what I need.
These SaaS stories are scaring me a little. Is there a non-BS guide that addresses these “hidden” issues associated with billing, tax etc?<p>I want to build a website with a paywall, accessible with annual subscription only. Let’s assume around 5,000 users for the first year. I assume that I can put together a WordPress website with a bunch of payment plugins - sign up, add cart, PayPal, debit card etc - would be enough.<p>But maybe not? What am I missing here.
I used Laravel Spark for telointerview.com,
I coded the base app in React so I use iframes for the spark pages. Couldn't recommend it enough, just dont be afraid to edit the vue files.
There are lots of companies offer "bridge" kind of service between Payment Facilitators like Stripe and SaaS app.<p>Since all my products are #1 in their niche and I know how dirty businesses especially competitors can play, I do not use any of these bridge services!<p>There are concerns that these services might sell your customers' data to interested parties or at least roll their own with some insight into your pricing and market dynamics.<p>We started off using WHMCS. Lots of my friends who rolled their own SaaS got stuck for months changing payment gateways but we just enabled/disabled plugins a few click and kept sailing.<p>Customers love that we use proven/cheap solution to solve this problem and focus entirely on our app.
Did this for our new product Construct 3:
<a href="https://www.construct.net" rel="nofollow">https://www.construct.net</a><p>It was difficult, but built some good features that do give us a lot of flexibility:<p><pre><code> * region based pricing
* region based billing cycles
* multiple plan options per region
* auto generated pricing based on live fx rates which ar
rounded “nicely” which is harder than it sounds
*% based discounts and account credit
* ability to modify seat counts
</code></pre>
Difficulties amongst many many others are:<p><pre><code> * VAT handling (it’s different per customer type and country!) and generally having a solid grip on business finance
* abstracting it to allow multiple payment methods (stripe and PayPal)
* generalising it enough to support multiple products
* dealing with fx changes during checkout
* handling disputes, refunds, etc and their affect on product access
* just PayPal in general god damn! When dealing with b2c not including it is tempting but not really and option. PayPal and stripe in my experience give 99%+ coverage
</code></pre>
Easy bits are the generating of invoices (prefer to do this in house) and all the other trim like emails etc. That’s just grind work.<p>I’m proud of it though and so far we’ve done 6 figures through it and is holding up well (tens of thousands of LOC and probably around 6 months dev time). We wanted it to do a lot and the design is quite sophisticated I think.<p>Second payment system with meat on it I’ve written (first cleared 7 figures but is no where nearly as well designed and mainly deals with one off payments). I enjoy making them!<p>Would definitely of bitten off more than I could chew if I was less experienced. Making it all scalable and reliable is another layer of complexity.<p>One gotcha which is hard to manage on a business level when dealing with sass accepting multiple currencies is forex rates that become very out of sync with your orginal price points. Can explain more but on phone!<p>Still to do is adding a system for accepting POS, a lot of the difficulties we face is we sell to the whole market, consumers, businesses of sizes and education. When selling to education specifically offering native currencies is a huge competitive edge especially for sass.<p>Also still to do in a more elegant way is b2b enterprise customers sometimes like paying for multiple years in advance - high value orders so another important case to cater for!<p>ALSO still to do is create accounts for resellers to buy at discounted rates. You can see how much work is involved on this sort of thing!<p>Winging it with “it works” won’t cut it imo (9/10 I’m all for it!) - that is the gooiest technical debt you can take on. Imo you need to seriously invest time into a good design from day zero.
Isn't there a front and back end software to deal with this kind of stuff easily ? Like magento <a href="https://magento.com/" rel="nofollow">https://magento.com/</a>
What about the <i>unhidden</i> work, like "Describe your SaaS, i.e. what is kwoosh?".<p>Sry, that was snarky, but you really should describe your service, as I could not find out what it does.