Extreme MVP; or how we got to $20k MRR without having a registration system

We've been having a good giggle in the Flow office, we've finally started making our registration system!

At $20,000 MRR this seems like an absurd situation, but it's really a side-effect of being rigorously SAASy; release early, do things that don't scale etc.

I'm proud of our approach, so wanted to talk about how we got here.

Let's talk figures

Before we get into it, we need a little context:

We have 155 users paying ~$130 / month
They have created 2,500,000 submissions and 600,000 images

I could stop here and say that 2,500,000 submissions is a better problem to solve than 155 registrations. This is true. But in the beginning we did not have this data.

How painful was registration anyhow?

Our MVP was enough to demonstrate the idea to our network. The MVP didn't have registration, if anyone was interested we registered them manually.

That "registration" was embarrassingly complex. We asked the user to fill in the email / password form, then had to do a fucktonne of manual work. It took days:

Update the codebase, commit and publish a new version of the product
Do some database plumbing
Log in as that user to see if everything worked
Then get in touch with them to let them know they were good to go
Add them to the "welcome" email campaign
Surprise! We probably messed up somewhere! So... deal with that and grovel to the customer.
Oh, and mucking around setting up billing and invoicing too. We did an awful job of that too

Surviving that ^ was only possible by nurturing great relationships with our customers. We still talk them through our workings. When we pick up the phone to chat to them, we're confident they'll be happy to talk to us!

Fast forward 2 years, and most of that list has been de-risked or automated, but there are still manual elements in place.

Prioritising Features

Picking features to work on isn't a formalised process, but it's something like this:

Discuss the problem - this could be something internal that we experience, or external that our customers experience
Consider the alternatives - what do people do instead?
Can we engineer a better solution? How long will it take?
Consider the emotional side of the problem

Let's work through an example:

Adding users takes us 6-hours per week. The feature will take 4 weeks. We're getting frustrated.
Bug X affects 20 of our users. They spend 2-hours per week on workarounds. The fix will take 3 weeks. They're not having a great experience.
Feature Y will delight 60 of our users. They spend 30-minutes per day on workarounds. The feature will take 1 week. They don't mind as they've always done things that way.

There's a pretty clear priority:

Bug X - the fix will take a while, but those customers need us!
Feature Y - the feature is quick and will add joy to the product
Adding Users - it's a complex problem, but our frustration is lessened by knowing a fix is coming soon

In reality, we have a huge list that is shifting and changing. That 3rd-place item (Adding Users! Woo!) has probably just been leapfrogged by an opportunity, idea or issue. We have to shoulder that work!

TLDR;

Understand your customers problems. Understand what you can do manually. You don't always have to engineer a solution. Be stoic about internal features. Communicate a lot!