The hidden work when launching a SaaS

I’ve built and sold software for the Mac and iOS. Those products all had simple billing systems. On the Mac, I just plugged in a framework eSellerate and added a couple of hooks in my software to integrate. eSellerate handled all of the billing, taxes and so forth. This let me focus 100% on my product, and then tack the part that allowed customers to pay me. For the service they charged around 10 or 12%.

On iOS (and later on the Mac) it was further simplified by Apple handling everything via the AppStore. This was a huge benefit because no work is required by the developer. They can focus 100% on the app, at least as far as payments are concerned, and it costs 30% of the app price. However, they lose the ability to communicate with their customers, unless they build out forms in their app to collect that information.

Both of these cases are all one-time sale purchases. Send an email on purchase and you’re finished. Using something like eSellerate or the AppStore and it’s all done for you.

With a SaaS, you need to handle all of that yourself. You need to handle payments, and invoices and everything inbetween.

And that’s when I realized we hadn’t addressed that part of the application yet. We had built in a Sign Up screen to create accounts, but not the 90% required to make it usable by actual customers. It’s easy to forget all of this extra work exists until you start thinking through:

a. What are the next actions you want a customer to perform (i.e. Sign Up) b. If you were a customer who just performed an action (Signed up) what sort of communications might you expect and when might you expect them c. What kinds of documents might you need to procure to pay for the app e.g. an invoice to send to your boss to authorize the credit card payment

Some of the “hidden”work, work outside of our main app, we needed to complete was as follows:

  • Create an account and start a trial with our payment provider when customer account created
  • Charge sales tax for users in Texas
    • Which means we needed to knowwhereour customer lives, so building out a form, database table, and workflow to allows users to display and edit their address
    • Synced with our payment provider and update sales tax accordingly
  • As Kwoosh licensed per-user, sync their subscription when a user is added or removed
  • Display a list of invoices
  • Create a view to display a single invoice
    • Pull in event information e.g. when was this invoice created, when was it paid, and display it.
    • Make sure the breadcrumbs make sense for the context
  • Welcome Email drafting, screenshot production, and coding

While it didn’t seem like a lot at first glance the amount of work on a non-core feature to make it right is quite large. While I’m happy with the backend, our invoice display needs a bit more work. As this is our workshop, our place for show and tell, I present you with our Work in Progress Invoice screen.

The first version of the Kwoosh invoice.