
Hidden work when launching a SaaS - mijustin
https://workshop.kwoosh.com/post/the-hidden-work-when-launching-a-saas.html
======
mrkurt
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.

~~~
encoderer
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](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.

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

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

~~~
Klathmon
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!

~~~
jamesvandyne
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?

~~~
Klathmon
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](https://sentry.io)

~~~
gm-conspiracy
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.

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

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

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

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

~~~
tinodb
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!

------
mijustin
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://spark.laravel.com/)

[https://bullettrain.co/](https://bullettrain.co/)

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

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

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

~~~
homero
Hey same here. The portal feature is incredible

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

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

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

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

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

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

------
symisc_devel
> 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](https://pixlab.io)

[2]: [https://paddle.com](https://paddle.com)

~~~
256cats
I second this, we use Paddle on
[https://gimmeproxy.com](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.

~~~
brazzledazzle
Is GimmeProxy intended for blocking proxies or utilizing them?

~~~
256cats
It's for utilizing proxies. For blocking you can use something like
[https://ip-api.io](https://ip-api.io)

------
homero
I use [https://www.chargebee.com](https://www.chargebee.com), they've been
incredible

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

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

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

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

~~~
baxtr
Do they also do revenue recognition for you?

~~~
aidos
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](https://www.chargebee.com/docs/revenue-recognition.html)

~~~
baxtr
Awesome! Thx

------
marcusbrown
These are exactly the pain points that Taylor Otwell (creator of Laravel, a
PHP framework) tried to solve with Spark
([https://spark.laravel.com/](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](https://workstack.io)

BrandOn [https://brandon.video](https://brandon.video)

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

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

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

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

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

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

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

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

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

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

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

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

------
TomGullen
Did this for our new product Construct 3:
[https://www.construct.net](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.

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

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

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

~~~
Silhouette
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).

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

~~~
warent
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

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

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

~~~
jamesvandyne
Did you view our marketing site at [https://kwoosh.com/](https://kwoosh.com/)
?

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

~~~
protomikron
> Did you view our marketing site at
> [https://kwoosh.com/](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.

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

