Hidden work when launching a SaaS | Hacker News Reader

Hidden work when launching a SaaS

workshop.kwoosh.com

260 pointsmijustin118 comments

This is hidden work for running a function SaaS, not launching one.

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.

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.

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.

You beat me to this comment by a minute!

I've run engineering teams in SFBA for years and have, with a friend, built Cronitor. I've come to believe the most valuable "soft" skill in an engineer is just a relentless drive to ship, to know how to be both tactical and strategic in avoiding over-engineering.

With Cronitor, we call it the JIT Mindset: Don't actually write code until you have to, and focus on solving most impactful problems first. My co-founder wrote more about it here -- https://blog.cronitor.io/the-jit-startup-bb1a13381b0

In one sentence it's simply: Over-engineering something can be hard which can trick you into thinking it's real valuable work -- it's not. It's a trap.

I totally agree. I just today shipped code that lets clients off board, nearly two years after launch.

It is really hard as an engineer not to complete a feature, but for a small scrappy saas product that's exactly what you have to do.

I liken it to building a bridge while your clients are walking across it. You want to be fair enough ahead that they don't fall in, but not so far you take them the wrong direction or build paths they don't go down.

author here. I agree with what you're saying in broad terms. And yes, you're right that handling sales tax perfectly at launch won't kill your product.

What's the killer is all of the work _surrounding_ that small task.

Actually charging sales tax didn't long. More or less

if address.region in TAXABLE_REGIONS: subscription.sync()

What took the longest was developing and deciding how the screens surrounding will work. Answering things like:

- Which fields do we want to capture for an address? - How do we want to store states (or provinces, or prefectures) in a standardized way? - Is there a library that will let me select countries and prefectures? (Answer yes, pycountry is pretty great) - How do I integrate this library into my backend / front end?

In my mind it's just fit and finish. Like making the motherboard and inside of the case as beautiful as the outside. If I try and half-ass it or skip it, I'm just going to have to double back and make it right.

I do appreciate your final sentence. I'll keep that in mind going forward. :-)

It seems making a project into a product is 80% of the work, when factoring in marketing, support, sign up, billing, and all of the other necessary evils, while the initial product can often shrink to 20% of the work during launch.

There's also a benefit to integrating as many off the shelf systems to handle the product launch (stripe, paddle, etc), and slowly refactoring the ones away that may be beneficial.

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.

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.

Soft-deletes are highly expensive technical debt until properly wrapped with an API. Until that happens, every developer/consumer needs to remember to check for archived=false.

One solution I’ve sometimes used is to move deleted records into a separate NoSQL database at delete-time. Keeps data around if you want to implement “see trashed/archived” later, can be migrated back in under an archived flag once you have that API, but in the meantime everyone else (including, crucially, the analytics team) can pretend that everything in the database is live. A kludge, to be sure, but sometimes a necessary one.

Create a view and have everyone use the view. Name the original table something like "table_with_deleted_records" to make it stupidly clear what is going on.

+1 on the soft deletes. It potentially adds a corner case to everything you do with that record. It's a permanent tax on your productivity.

If you can get away with it, its much better to just delete it out, perhaps moving it into some archive table incase you change your mind later.

author here. You’ve hit the nail on the head.

We actually have soft delete in Kwoosh. We’re using Django on the backend. The way we went about implementing it was with a flag on our core data-type (Apps, Screens, Discussions, Tasks etc... all share a common parent class). Then we used an custom Manager class (Django’s name for the bit that lets you set default filters for models) that sets the default filter to only show active items.

If we want to query all objects including archived items (like for viewing them as read-only) we just change our code from Task.objects.filter() to Task.all_objects.filter().

We also have another flag for controlling visibility directly. This makes it manageable to remove a parent task, hide the children tasks, and restore into the expected states.

I should write a more in depth post on this for workshop. Maybe someone would find it helpful.

I usually use a date as a soft delete. If it's non-null, its deleted, and, you get to record the actual date of deletion.

I've never found it to be a problem. In fact, I find it's more of a problem to physically delete. You just have to design that way from the get go. Not added on after you've realized ppl leave.

Yeah, I find the sentiment that this is hard to implement without it being YOOGE tech debt odd. There are so many ways to get it out of the way, including just querying through a view if you can't come up with an app-side solution.

The technical debt might be proportional to how many ad-hoc queries you have buried in various modules before you realize that some things do need to be deleted as of a particular date. But as you indicate, with a real DBMS, naive queries can just be pointed at a view.

Also, how to deal with down the road queries wrt; churn when you have deleted the data. I'm calling self inflicted technical debt because of shortsightedness or, dare I say it, lack of acumen. :D

Another point I didn't see mentioned was "support and documentation" (not necessarily SaaS specific, but still applicable)

I was the lead developer of a greenfield new b2b web application that took several months to develop the MVP for, then another almost 2 years to develop support tooling and systems for.

We would get calls that it didn't work with no other information, calls that it didn't work with "my older samsung", emails with pictures taken with another phone of the login screen with no other information, users that didn't know the name of the company they worked for, or even their username in the application.

We found suprisingly that there was a subset of our users that couldn't even tell you if they were on iOS or android! But quickly we learned that it's not their job to care about that, it's ours. We spent the next almost 2 years writing in debugging code, shipping logs back to our servers, writing code to send errors back to us to avoid having to ask the user on the phone to "please read out exactly what the error message says" only to find out that it happened to them last week and they don't remember... We wrote code to be able to "playback" what a user is doing in the app before they have a problem so we could identify UX issues, and redesigned UIs to include important information so when users sent us screenshots or pictures of the device we could get useful information from it from anywhere in the app (like app version, os version, username, company, etc...). We wrote documentation for how to enable camera permissions that they may have inadvertently denied for several android versions and flavors and iOS versions because we found that some users would be confused if the images and names were slightly different.

If you asked me today what makes our app better than all of our competitors, i'll tell you that it's hands down the "support" capability of the application, and that if a user has a problem, we can track down what they were doing when it happened and figure out a fix (either procedural or technical) sometimes before they even call the problem in!

Also, it's a sure fire way to deflate the ego of the hotshot lead developer that thinks he's made the best thing since sliced bread when the most important part of the application is a glorified log shipper!

Spot on. That's something that's next on my roadmap: building out a help and documentation site/portal. There is so much more that goes into building and launching a SaaS app than just the app itself.

I'd to love to hear more about how you identified UX issues from pure logging data. Do y'all write anything up about this online anywhere?

No, we haven't really written anything up. I've always wanted to start writing about stuff like this, but never get the time (because I spend it all writing stupidly long comments on websites like this!)

But one example of how we use logging info to clean up our UX was just kind of "watching" what the users were doing by just following absurd amounts of logging (logs like "clicked x button" are short and cheap, as long as you can filter them out when needed, they are immensely valuable). Our application does a lot of barcode scanning, and we noticed just from browsing around individual paths in our log-shipping system that if some users had an error with the camera (lowend android cameras are a lot buggier than i would have imagined!), they would go into the settings, select the option to change the scanner to a wireless laser attachment, then change it back to the camera version before going back to what they were doing.

Overall the process took them a good 15-20 seconds, and when they should be scanning about 1 carton a second in the app, that added up in both time wasted and in user frustration. We added a "retry" button to the error screen, and instantly the long workaround stopped happening. Then we took it a step further and would attempt to re-grab the camera in the background before showing the error to the users, which cut down on the number of those dialogs significantly.

It was a matter of getting an alert that this "camera not readable" error was happening commonly enough to trigger an alert, and from there was about 10 minutes of browsing the "breadcrumbs" for a few users to see the pattern, maybe an hour of adding the "retry" button in the dialog box (and testing), and another hour to do the auto-retry a few days later.

3 hours of work when it's all said and done (of course, after the timesink of developing it all), and the product is better off. And that's something that i'm almost 100% confident that we would have never found out about without this kind of logging and reporting.

We use sentry.io [0] for a lot of this error logging, and we have found it incredible at being able to "walk in the user's shoes" for things like this.

[0] https://sentry.io

I really appreciate your comment.

I have been pushing hard for our team to implement sentry.

I have implemented JS logging for all of our AJAX interactions, but having sentry 'coalesce' everything into a single view, as you know, is immensely useful and actionable.

Well if it helps, sentry is incredibly easy to implement on a basic level, and the free tier is more than enough to play around with for quite a while before you need to step up to something more.

For us the process started with just including the script and getting a few crashes or exceptions here and there, and once most of us were comfortable that some time investment here would pay off, we really wired it in and the benefits just skyrocketed.

Now we even have it running on our server side code in one case because it's just such a damn good tool.

I will say that the downsides are that the search is fairly poor unless you self host and have access to the database, and forget about using it for any kind of reporting over time periods (it's actually really hard to see things like "number of times this error happened in the last week").

But overall it's a very easy system to layer on top of just about anything. I know nothing about your company or product, but see if you can get the approval to spend an hour or 2 to just try it out. As long as you don't have any PII its a pretty risk-free thing to try.

I had a similar issue just yesterday - my app can produce xls files with links back to the app. However, if the stars don't align correctly when user clicks the link, the browser won't send user's cookies so they are always just shown the login screen. You can implement a server workaround to refresh="0" and when the refresh happens cookies are sent again

https://stackoverflow.com/questions/2653626/why-are-cookies-...

Brilliant. Thank you for this response.

Please tell me you are evaluating saas tools like zendesk and intercom. Depending on your app and your user sophistication, these can be great solutions. (If your username is expecting code examples, I'd look elsewhere.)

They have startup pricing and we've used both. It wasn't great to pay a monthly fee, but it was far cheaper than anything I could have put together myself.

soft delete aka flag delete is a very common thing in databases. If it's a customer account that is being deleted then just set a flag on the record or change the user's status. The last thing you want is to try to resolve a dispute where all the details have been removed from a database.

safety first. record everything.

Using a framework like laravel makes soft deletes easy. Great for prototyping.

-> user invites, user profiles

Not needed

-> transactional emails

Most transaction email services offer same old SMTP interface.

These really depend on the product. Kwoosh, the product in the article, is a team based project management tool and so requires a way to add other team members.

As for transactional emails, we have found that its the planning, writing, designing, producing content for them that takes time and not the actual sending process.

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..."

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.

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').

To counter; we did the billing system after, when we needed it. In fact, the first Saas sale, my business partner phoned up excitedly and said, "I've just sold a licence! Any chance you could hack together a page to securely take this guys details through Stripe", which is just what we did.

We winged it for quite a while with that. It was only after the billing side started to take too much time that we needed to switch to Chargebee to take away all the pain. Sure, it's manual work doing the invoices etc through Xero, but it's not impossible. It's pretty manual with enterprise customers anyway as the billing process is going to involve a bunch of back and forth with purchase orders etc.

I applaud what you did, because you are essentially being honest here with how you went about it. The only way to accommodate shoe horning in a billing system in that amount of time is, as you said, to 'hack' a rudimentary system together, and to do some of it manually. That is perfectly understandable. You would also be aware of the technical debt that you built up by doing it this way - debt that will have to be paid off later with either a complete redesign, or else major functionality addition to keep pace with all your customer requirements.

My issue was with those who intimate that they deliberately left off any form of payment functionality, then managed to get a fully working engine up and running perfectly in a couple of weeks.

It depends a little on how deep the integration goes, but certainly, building a billing system from scratch is a load of work (I've done it a couple of times myself), and you'll do a rubbish job of it.

The sort of billing engine that you need to fully handle saas requirements, and especially enterprise as you say, is definitely not the sort of thing you knock up in a couple of weeks. Just ask the guys and Chargebee to find out how much work it really is. You probably couldn't even build the coupon component of it in a couple of weeks.

Having said that, integrating something like Chargebee's offering into your own product shouldn't take that long and I'd argue that if you're building a company, there are plenty of more important things to focus on before you need to even look at billing systems — Xero will get you a long way.

I set up the payment page of my app in under a day with Stripe Elements and just didn't worry about invoices. If someone needs them I just send them thru the Stripe UI. I have been getting more requests for them recently, but I think it's going to be a while before it's worth building myself.

Most consumers would be happy with just the Stripe payment receipt as proof, but Enterprise level businesses want a formal invoice. Australian businesses for example, would want a formal "Tax Invoice" with GST (Goods and Services Tax) breakdown, plus our ABN (Australian Business Number) quoted on it to meet legal requirements. Other countries have similar legal requirements for the actual invoice document.

My point was specifically for B2B SaaS companies (especially those that operate internationally), as opposed to B2C where the requirements are a lot less stringent.

Our experience is quite the opposite. With B2B you have less customers, and especially enterprises have a designate email address where they want the invoice to go. They don’t care about any of that in-app. And for us with just under a 100 customers it’s easy enough to generate them through our accounting software and send with mailmerge or something like that (don’t know what our financial guy uses :). We talked about building invoicing to make things less time consuming, turned out that a better overview of the plans and usage was enough for now!

I setup Stripe using their API not the Checkout widget and it only took a weekend including receipts. Yes, there's a long tail of work needed for cancellations, refunds, non-credit card providers, multiple subscription plans, multiple billing periods, automated periodic auditing, etc. However, I totally believe a lot of devs can setup stripe in their MVP in a day especially if they only use Checkout and Webhook Events.

This part is so true:

"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."

Edit - both Spark (Laravel) and Bullet Train (Rails) will help with a bunch of this stuff:

https://spark.laravel.com/

https://bullettrain.co/

> You need to handle payments, and invoices and everything inbetween

Isn't this pretty much why companies like Stripe exist?

It does a lot of the heavy lifting for credit cards, but is nowhere near a full billing system for SaaS. It’s why things like Churnbuster and BareMetrics exist. About 20% of our customers need to pay with something other than a CC, which complicates billing even further.

Yes, but they require integration, which is no small feat. You'll have to wrap their fairly low-level payment processing services into your own business logic.

So, it's far from flipping a switch. There is Webhook integration, state management, notifying users, etc.

Stripe just does the processing. But for SaaS, you really need something like https://bullettrain.co/. It does pricing pages, subscription and user management (which is what takes most of the time to implement).

Don’t forget the topic of revenue recognition in SaaS. Basically, you need to allocate your revenues per month if you accept yearly payments. Also, you need to consider up/cross-sells and cancellations, that drive up complexity. I have seen SaaS companies using excel for this...

This looks really interesting. Are there alternatives that are built on other frameworks?

Unless you have a low cost SaaS product (monthly credit card billing) Stripe is a pain. If you have anything resembling an enterprise sales process juggling dozens of invoices, discounts, payment terms, etc., becomes a hassle.

Is there an Enterprise Sales ready billing / invoicing solution? We're using Quickbooks - it leaves much to be desired.

Chargebee. It does pretty much everything you can think of and bunch of stuff you can’t ... but will suddenly need one day.

We use ChargeBee for our SaaS product. Really great offering! They give you a customer portal where the customer can cancel, update, upgrade, ... his subscription. We have a custom checkout page where all options are listed. Then one API call and the user is forwarded and can fill out billing address, payment information, etc. on a ChargeBee page. They will handle taxes, issue invoice and everything else for you.

They have also an extensive API and webhooks.

Hey same here. The portal feature is incredible

same here....went from rolling our own to Chargebee...so glad we did

Yep but if you want to support other payment types, such as paypal then you need to deal with that too.

Suddenly you need to write payment abstractions on your back-end to handle both and most pre-written libraries that try to do this fail because they don't handle cases you may need.

That only handles the mechanics of accepting a payment too.

Thank you @foxylion and @homero for mentioning Chargebee.

Krish, Cofounder of Chargebee here. A lot of our customers use Stripe + Chargebee combination as we complement them by leveraging the best features of Stripe. We like the way Stripe.Js, radar and auto card updater etc is beautifully built. (ex: you can pass Stripe token to create a subscription in Chargebee). We continue to build in a way that we let you use those features while providing a full fledged billing system that integrates all the way from CRM, helpdesk /intercom to accounting. Your finance or sales can collect non card, PayPal payments without any changes to the code. Enabling those business users post implementation with support is our core value prop, so that developers don't have to worry about giving internal solutions afterwards.

Give it a spin and for the idea launch stage we have a freemium tier for first $50k usd. If you have any feedback please write to me at Krish at Chargebee.

Thank you, Krish! Chargbee has been an awesome experience all round for us and one of my most recommended products.

The team have always been ready to jump on a call to deal with the murkier migrations over the years — I'm looking at you, merging our single currency sites into a single multi-currency site...

It's nice to see you guys getting a lot of love in all the threads about billing on HN these days. You absolutely deserve it.

Thank you, Aiden. I am very happy to see our longtime customers like yourself recommending us in HN. We know there is so much more to do to make things easier and better. I look at Shopify for inspiration to see how long it has taken for them to get their product right by polishing every aspect, feature-by-feature. :)

I am sharing this thread with the team. They will be thrilled to read the feedback. Cheers.

I'm in the process of building a SaaS and looked briefly at Chargebee. Right now I'm trying to stay as lean as possible so I quickly wrote of Chargebee as something that would cost money.

The fact that you have a freemium tier completely changes my perspective on that. Guess I didn't spend enough time looking :)

I'll check it out!

We use Stripe, and it's been great. But now we need to start providing invoices and charging different tax rates for different countries ... and suddenly the low-level processing of Stripe just isn't enough.

(I work at Stripe) We're actually beta testing a new product for invoicing. Shoot me a note (tara@stripe.com) if you're interested and I can get you into the beta.

That is not Enterprise saas in my experience. That is someone signing up for a 20-100 dollar a month service. A 40k a year contract is a bit different

If you sell 40k a year contracts, can't you just have a sales assistant maintain the custom terms&conditions&discounts and draft personalized invoices manually until you have many such contracts and automation starts to make sense?

Thanks for updating with these SaaS providers. We are on the Microsoft stack and have been using AspNet Zero[1]. It would be interesting to see a more comprehensive list on here of SaaS providers and which languages they are built-on.

[1] https://aspnetzero.com/

Looks really interesting! Will definitely keep it in my mind for the next app... It seems it's a bit more expensive (and does more) than Laravel. Can you talk about your experience with it?

They recently hiked up their prices b/c now it includes a Xamarin mobile app but their back-end and middle-tier is free & open source[1]. We opted for the paid version because our team is small and we are building a new multi-tenant SaaS.

It's going well but the primary challenges we have are porting our existing data into their data model which right now uses SQL Server and some Redis. The paid version comes with descent support via their premium forum[2] but they have their own tag on StackOverflow[3]

[1] https://github.com/aspnetboilerplate/aspnetboilerplate

[2] https://forum.aspnetboilerplate.com/viewforum.php?f=5

[3] https://stackoverflow.com/questions/tagged/aspnetboilerplate...

thanks!

This is really cool. Do you know if there's something similar for Python/Django?

Any recommendations for a Django alternative to Spark?

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.

Good. It's about time start-ups started taking that responsibility seriously.

I sort of agree? I think it's important that people take data privacy and security seriously. I don't think someone, however, needs a nuanced understanding of what constitutes legitimate interest for data processing, or needs to have an attorney from every country or region they do business in on standby.

The issue is that vendors (CRM, marketing automation, etc.) are trying to offload too much of the risk and accountability to their own end users, which leaves startups piecing together tech stacks that are sometimes not even legally compliant in their default settings. Not OK.

That's definitely true, but I'm not too worried about it. It will be a short-term headache, but I think eventually processes will be refined and new models of responsibility will evolve.

It's not about responsibility, it's about the unnecessary red-tape.

I'll be honest, I've been selling EU wide for a while now (~2 years), only abiding by UK laws for the LTD, and before that with a Belgian BVBA. There's all the laws which I never thought about, and no one ever said anything about it. Sure, it's not sustainable long term, but now I can fix all of it because I actually have a profit.

So, you can either be afraid and dump a lot of your money into "doing everything right" or start right away and fix shit later. I'd say don't be discouraged by the seemingly spooky EU laws.

It sounds like you're saying that users that care about their privacy/pii should be wary of startups?

I actually think it's in most cases not that bad for new projects, since you can from the beginning design it accordingly. Tracking down all the details, making sure existing vendors are compliant (and having to swap out those that don't) and finding replacements for processes you maybe wouldn't do like that now in an existing application sounds harder than minimizing exposure in the first place. keyword "privacy-first design"

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.

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.

having said all of that, chargebee is pretty awesome.

> You need to handle payments, and invoices and everything inbetween

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.

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.

[1]: https://pixlab.io

[2]: https://paddle.com

I can second the recommendation for paddle. I use it for https://presskithero.com, which has customers around the world, and we are a german company, so we have to handle very complicated european vat rules...which paddle does for us!!

how are refunds handled - I mean does paddle handle it ?

yes they handle it. when a customer requests a refund via email, I login to my paddle account, search the invoice, and simply click "refund".

Also, Paddle costs more per transaction. Stripe charges fixed 20 cents / transaction and Paddle 50 cents.

I second this, we use Paddle on https://gimmeproxy.com . It's really nice they handle VAT automatically on your behalf (EU VAT law for online is complicated) and setup was pretty easy.

Gimmeproxy is exactly what I was looking for. No need to search now!

Is GimmeProxy intended for blocking proxies or utilizing them?

It's for utilizing proxies. For blocking you can use something like https://ip-api.io

I use https://www.chargebee.com, they've been incredible

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.

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 poof! everything is magical.

> 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.

I feel like this might become a burden later on when you have to support multiple versions of a codebase in the wild.

You could half-ass it like many (most?) vendors seem to do. You can always tell they've shoehorned their on-prem product into a SaaS offering when they ask you to port forward on your firewall to your LDAP server and don't support SAML/OAuth/OIDC. Bonus points when they can't give you a dedicated per-costumer IP or range to whitelist. More bonus points if they can't give you any to whitelist at all without a bunch of internal communication/work (shared or not).

Are there any SaaS that do all these things for SaaS?

Especially for Germany/Europe?

If not, why not? Sounds like a good business opportunity.

Yes, as mentioned in my other post, ChargeBee does this really well. We, as a German company, use it for our SaaS offering.

Do they also do revenue recognition for you?

Revenue recognition isn’t something I know anything about (see my comment above about chargebee doing a bunch of stuff I don’t even know I need) but here’s their page on it

https://www.chargebee.com/docs/revenue-recognition.html

Awesome! Thx

We (SaaS, https://geocoder.opencagedata.com/) use https://quaderno.io/ plus their Stripe connector which handles inter-european VAT well. It takes care of invoice PDF generation, UI for users to change their billing details, list of past invoices etc.

These are exactly the pain points that Taylor Otwell (creator of Laravel, a PHP framework) tried to solve with Spark (https://spark.laravel.com/). It was actually just updated to v6.0 yesterday so it's definitely a good time for considering it.

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!

Workstack https://workstack.io

BrandOn https://brandon.video

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 the most 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.

Shoehorning Shopify to your SaaS is probably quite straightforward. There are plugins for accounting stuff, too. [0]

[0] https://apps.shopify.com/featured/accounting

Excel can be your tax template, but people would still rather use dedicated software.

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. http://amzn.to/2H8isRI).

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.

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.

I'm using Laravel Spark for the SaaS I'm building. It's fantastic, I highly recommend it. The one caveat is that if you're doing some odd billing scheme (e.g. aside from just one or more tiers at set prices), it might take a little extra work.

These SaaS stories are scaring me a little. Is there a non-BS guide that addresses these “hidden” issues associated with billing, tax etc?

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.

But maybe not? What am I missing here.

You need to think about the tax implications which depends on whether you're selling to businesses or individuals and which countries you and they are in, amongst other things. I'm basically banging the Chargebee drum on here because they'll take care of all that for you.

Taking the money is (relatively) easy. Plenty of payment processing services will help you with the mechanics of that these days. As many of them enthusiastically demonstrate, the basic charging mechanism often requires just a bit of information to sign up and then a few lines of code (or a simple plugin for WP) to implement. You're probably right about putting that together without too much trouble.

Unfortunately, then you get the other 90% of the job, because you're a business and charging money, and that comes with all sorts of legal, accounting, tax and regulatory obligations that will vary depending on the place(s) you do business and the place(s) you find your customers. This is the stuff the flashy "Take your first payment in five minutes" demos on the homepages of all the payment services don't tell you about, but if you're lucky your accountant might. (If you're less lucky, you might need a more experienced accountant but won't know it, and you might wind up making expensive mistakes. Doing a lot of reading online about the rules that apply in your specific location, for example if your government's tax department offers any guides for new businesses about what they generally need to do, is the only reasonably effective solution I know to this problem.)

In practice, these things almost always come down to

(a) identifying the relevant tax rules based on your location and your customer's

(b) calculating the correct tax on sales, as well as on any payment processing fees, etc.

(d) filing the necessary tax returns and/or providing the records to your accountant so they can do the serious business financial paperwork

(e) paying your taxes properly.

None of it is rocket science, it's just that it's often a big, complicated system that you have to work within, and it's full of little details like generating sequential numbering for invoices, or knowing how to handle the tax if you've issued a refund before/after the end of the tax reporting period containing the original sale, or being able to record two non-conflicting pieces of evidence to confirm which country your customer is in. It can be time-consuming and error-prone, and taking enough professional advice to understand your obligations and how to do everything correctly can be a significant expense by start-up standards.

Finally, depending on your market, you may at some (possibly quite early) point want to accept payments through more than one channel: purchase orders and payments to bank accounts, online credit cards, the various direct debit schemes or national card schemes, PayPal, and so on. If you're in that position, the "front line" payment processing services like Stripe or PayPal are unlikely to be sufficient, because it's a level above what they're designed to do. So probably you will either need to use one of the next-layer-up services such as those mentioned elsewhere in today's discussion to co-ordinate things, or you will need to do some substantial programming and database work of your own to do something intelligent about combining the functionality and record-keeping for each service.

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.

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!

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.

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.

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: https://www.construct.net

It was difficult, but built some good features that do give us a lot of flexibility:

  * 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

Difficulties amongst many many others are:

  * 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

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.

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.

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!

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.

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!

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.

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!

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!

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.

FYI your construct.net link is missing an 's' :)

Fixed cheers!

How do you deal with region based pricing knowing that anyone on the internet can pretend to be anywhere ? For example using a VPN

It’s not too much of a concern, businesses and edu are generally honest. Issues come from b2c sales but it’s a mintority. We will have systems in place soon that will warn and suspend service if we suspect abuse - asking customer to provide proof of residence. When paying for something the processor often gives some evidence as to their country.

For a lot of customers even b2c a properly issued invoice is important so that does narrow down abuse.

Requiring billing address is a good catch especially for card verification although there’s a constant friction between the frictionless checkout and anti-fraud/region verification.

Main struggle we’ve had is businesses buying the wrong package - (cheaper of course)! Best way to catch this is to only issue simple receipts to the plans aimed at b2c and tell them to email invoice address if they’d like a full invoice issued.

A lot of people seem to be uncomfortable with region pricing based on abuse - however it’s important to bear in mind it doesn’t have to be 100% effective to be a net benefit. If your product is truly worldwide region pricing can be an absolute essential. As can region based billing cycles where in some cultures monthly payments are culturally the norm and annual can be hard to swallow.

Every dimension of global saas payment systems is complex. I’m tempted to say there’s startup opportunity here but it feels like there will always be a lot of glue needed and a huge amount of flexibility between customers needs so I’m not sure how plausible it will be.

Edit: worth mentioning is that EVERY saas company needs some region pricing - most simply you need to respect trade embargoes and deny all sales to specific regions as best as possible.

A lot of payment services can now provide much more useful verification of a customer's location, e.g., checking the country where a card was issued or knowing the country where a certain payment method works or a bank account is located.

This is becoming a necessity since various places, notably the entire EU, now require multi-point proof of customer location for tax compliance for at least some types of sale.

It's easy to pretend you're somewhere else until you need to pay for something. Then you have the entire financial sector's anti-fraud systems to deal with, and a VPN isn't going to fool them for a moment.

Iirc VAT laws require 3 sources of proof of country - that’s what we tried to do (IP, billing address and processor reported address) although often it’s only possible to get 2.

For the electronic B2C stuff in the EU, the requirement is two non-conflicting sources. Something like geolocation and card billing address should suffice in most cases (assuming you have access to the customer's IP address and they're paying by card, which is surely a fairly common situation for a SaaS).

Isn't there a front and back end software to deal with this kind of stuff easily ? Like magento https://magento.com/

Good point but have you tried using Magento? It's a beast into itself and typically requires an expert that knows how to configure and use it

Then what is the competition for Magento ? I would like to launch a SaaS in the future and I really don't want to spend my life building a client database, stripe stuff and support platform...

What about the unhidden work, like "Describe your SaaS, i.e. what is kwoosh?".

Sry, that was snarky, but you really should describe your service, as I could not find out what it does.

Did you view our marketing site at https://kwoosh.com/ ?

Good point though, we could update the footer on workshop to be a bit more specific.

> Did you view our marketing site at https://kwoosh.com/ ?

Yes, that's what I am referring to, the workshop-link goes to some kind of blog, but it seems to be more about tech and entrepreneurship in general.

Some kind of "About" section with screenshots would be nice.

Thank you for the feedback.

Yes - more screenshots / a properly filled out marketing site are on the list of things to do. Good idea about an "About" section. Workshop is the name of our blog where we show / discuss Kwoosh as we build it.

Reply on news.ycombinator.com