Trying Out The “Serverless” Thing While Bootstrapping My New Company

I can’t stand lock-in of any kind, so I decided to knit together a collection of services and functions in the cloud.

I just created a new business called Big Machine. I’ll be writing books, doing videos, and creating (hopefully) useful free online tutorial stuff. This is my 4th time setting up a business and I’m trying something a bit different.

I decided to avoid lock-in at all costs, retaining as much control as I can. So far it seems to be working. It’s still very much a plan in progress, but I like what I have so far and I thought I would share it with you.

My Current Setup

I think this is kind of funny. Check it out:

  • The main site (bigmachine.io) is a static site, generated by Middleman.
  • All reporting and analytics (ecommerce, user, etc) are handled by Google Analytics. I have no custom reports of my own.
  • The site is hosted at Firebase for free, which offers free SSL and a realtime database. I’ll probably end up paying them $20/month or so, at some point, as soon as I plugin the database.
  • Transactions and ecommerce are handled by Shopify and their Buy Button. This is working well, but soon I’ll be moving to my own thing (more on that below)
  • Downloads and delivery are (currently) handled by SendOwl. Once again, I’ll probably take control of this in the coming months.
  • Customer notifications, fulfillment, and management (and general CRM) are handled by Drip. I love this service.
  • Archival of the transaction data is handled by an AWS Lambda function, served up by AWS API Gateway, which pushes data into a hosted PostgreSQL database.
  • Knitting this all together is Zapier.

I left a few things out, but this is basically the structure. When an order comes in, Shopify sends a web hook to SendOwl which triggers the fulfillment. They also send a web hook to my archiver, which jams the entire order as JSONB into my PostgreSQL database.

This is where Zapier comes in. Their service is quite useful — they string together disparate APIs so you can make things happen given certain triggers. So, when an order is triggered by SendOwl, Zapier takes that information and hands it to Drip, which sends the fulfillment email and tracks the event on the customer record.

Why am I doing it that way? Drip is, at its core, a mail list service. It’s also a whole lot more. You can tie events, tags, and other things to individual customers (and prospective ones too). It makes good sense that I should track the delivery email — whether it bounced, if it was opened, and so on.

Believe it or not: this is working very, very well. It did take me a while to get here. If you’ve bought anything from me in the last few months you know I went through some pain with the delivery service.

That’s one of the things that drove me to set things up this way. Let me try and explain a bit more.

I Need Control

When you start a business, your focus tends to be “get to market, fast”. There is a great amount of truth in this notion. If your product won’t sell, building the machinery to sell it is pointless. If it does sell, however, you need to focus rather quickly on making sure the bits are in place for you to execute.

What bits? In short order:

  • Solid, reliable customer data. This includes acquisition (how they found you), behavioral (what they did on your site, etc) and finally conversion (when and how they pulled the trigger).
  • Complete transactional information. How they paid, what time of day, in what timezone as well as what country.
  • The ability to control, completely, the look and feel of your site. You’ll need to change your sales approach at the drop of a hat, at times. This should be easy to do.
  • The ability to change something when everything goes wrong.

Of all the points above, the last is the most critical. It allows you to refocus your efforts quickly so you can get back to producing things of value when a 3rd party service (or framework) lets you down. Which they will, eventually.

Let’s come back to earth, now, and I’ll share with you how I ended up where I am, and where I hope to be in a few months.

Rob’s Rule: They Will Let You Down

This rule has held true for me consistently:

The longer you stay with a PaaS, SaaS, or framework, the closer you come to the day they let you down.

It just happens. It happened to me quite a few times, just a few months ago.

I started selling The Imposter’s Handbook back in August, and I used Gumroad (intentional non-link there) to do it. I used Wordpress with some nifty plugins and plugged in the Gumroad transaction engine. It worked OK, until:

  • I realized they were setting up billing agreements for all of my PayPal customers instead of doing a one-off transaction. This is, essentially, a subscription and was setup between Gumroad and my customer. That’s slimy.
  • They throttle the PayPal transactions. If you run too much money through PayPal at once, they will block you until you prove who you are. It’s one of their fraud checks and is annoying as hell. To get around this, Gumroad has some kind of messed up algorithm; if too many sales are happening at any given time, the PayPal checkout disappears. How’s that for hacky?
  • They have hidden fees. You’re charged $25 per month, per 1000 sales. You can’t see this fee until you’ve created an account and upgraded it. This is bullshit. Over the course of 5 years you might have tens of thousands of customers — you’ll pay for that, every month. Isn’t that neat?

After 30 days I left Gumroad as quick as I could. The data they “allowed” me to export was pitifully incomplete as well, but I had (thankfully) Google all setup, so reporting was unaffected.

The point? I need control and I gave it over to Gumroad in the name of getting to market quickly, which was a bad decision. The good news is that it didn’t effect my main site because I hosted that independently with Wordpress.

Shopify has been fine, for the most part, but one day they decided to randomly send out a fulfillment email to every customer with the wrong file attached to it. I asked them what happened, they said “oops, sorry we don’t know. Maybe don’t use that app”. Yeah thanks.

SendOwl has been fine, again, for the most part but half their emails get blocked by spam catchers (domain conflicts) and their Dropbox integration times out consistently… and there’s no way to disable it. I feel like I’ve gotten to know their support team quite well by now, as numerous little nit-picky problems seem to crop up consistently.

These things happen. I can tolerate them as my business gets off the ground… but not for very long. As customers come in I need to be sure they’re taken care of and have a great experience.

That means I need to have more control over everything.

Taking Control

I’m in the middle of rolling away from “get to market fast!!!” to controlling my own destiny. To that end, the plan is:

  • Building a transactional API that I control, which uses Stripe and PayPal directly.
  • Creating a fulfillment API which uses AWS/S3 for file downloads.

I’ll probably end up with a hosted machine somewhere because I want to use Elixir to build this stuff, but there are options if I don’t want to do that. Specifically:

  • AWS Lambda/API Gateway, orchestrated by the serverless framework (which I’m using now). The nice thing about this is that the framework just handles AWS for me, not my code, which is just Node!
  • Webtask.io, created by Auth0. Same kind of thing, really, but a whole lot easier to use. Little JavaScript functions in the sky, tied to a URL.
  • More Zapier. I love what they do and, more importantly, I love that they give you a full rundown of what task fired, with what data, when. This allows you to quickly remove one service for the next, which is essential.

I don’t want to sound too negative on 3rd party services, sometimes they just work. Zapier is one of those services, as is Drip. I know that one of these days I might move away from them both; until then I have to say: I’m quite happy.

Summary

I have a feeling that I’ll get some stick for this post, which is fine. One of the very nice things about the way I’m setting things up right now is that it’s flexible. If it doesn’t work out, I still have my data (all of it) sitting happily in a PostgreSQL database. Of all the things in my development career — all the languages, frameworks, toolsets, etc — PostgreSQL has never let me down. Not even once.

As long as I have all my data sitting there, I’m good to go.

I’ll keep writing about my experiences as time goes along. I’m fully aware that I might regret all of this! I sure hope not.