As developers, we all have little nuggets of ideas. We want to build something people use and we want to build something people will pay for. But the path from idea to paid product is treacherous. At Zapier, we tried something just a bit different in the beginning: a paid beta.
At its core, a paid beta is just a more dynamic version of an MVP. The mechanics are incredibly simple:
- You mock out a simple product or even just a promise.
- You let people make small, flat payments (think $1 to $5) for access and in return you continue building out core product features.
- Over time, the product will grow under the proper evolutionary pressure of what users will pay for.
It’s almost like a Kickstarter except you give users to your product right away rather than when the Kickstart is done. Just like Minecraft made paid beta with incremental improvement viable for indie games, you can do it with SaaS apps. We did it at Zapier.
This pattern actually works really well for the below reasons:
You force yourself into doing the right things.
It meets two pretty crucial components of a proper early stage startup: talk to users and write code. More importantly, since users are paying you, you know they are the right types or users and you aren’t just chasing a market made of tire kickers.
The revenue is a red herring.
The minor revenue is not the prize. The fact that someone will pay you at all for some promised product is the prize. Indeed, you could win bigger fans by just giving them their money back when you deliver their feature. Revenue potential is proven, so you can basically just turn on paid plans and make money.
It is easy to understand.
As a developer, I am basically taking on work from early users at a loss to guide my product development. As a consumer, I am paying for early access to features and a chance to provide feedback to make the app even better for me (and at a crazy low rate at that).
Eventually, you figure it out.
In time, new feature requests will become increasingly unique. Once you’ve reached this point you’ll know that existing features are going to be the core of your product. It’s time to move out of beta and put real plans in place. Treat your early adopters well.
You gather a crowd.
While working with customers, you’re building relationships and fans. These fans will be hard won and vocal about you and your products, you can trust them to treat you well. Remember, you can do unscalable things in the beginning.
Some final words of wisdom: the paid beta pattern tends to work well for B2B products. If you are trying to build a giant consumer social network that relies on network effects this may not be the best approach. But if you plan on charging for your product: charge from day one where day one doesn’t mean “launch day”, it means the very first user.
There’s an elephant in the startup room, it’s that one of the defining aspects of work-life balance at an early-stage startup is that it doesn’t exist. There is more work to do in a startup than there is time to complete it, which means every second you’re not working increases your chance of failure. This [...]
I see soft-launches all the time on Hacker News and Reddit’s programming/startup communities and the feedback seems to follow a pattern. Some feedback is just plain negative (Why would anyone use this?), some feedback is strictly positive (This looks awesome!) and then, of course, some feedback meant to be encouraging masks defiance or dissappointment: This [...]
This one has been nagging at me for a while, so it was nice to finally get two it working the way I like. It ended up being really easy, you’ll need a spectacular little app called watchdog to go with gunicorn: pip install watchdog -U # now there is a command called "watchmedo", you’ll [...]
Working on a fun side project at HackComo, I needed a finite state machine. Well, this is a simple decorator for limiting when a method can be ran: def fsm(target, whence=’*', attr=’state’): """ `target` -> (str): REQUIRED should be the target state. `whence` -> (list): ‘*’ should be a *list* of states that you [...]
Let me preface this post by saying South is awesome. It greatly simplifies schema changes when working with databases with Django. However, if you’ve ever had to do a large data migration, you likely will see South bite the dust. It’s not really made for that. At that point you really need something a little [...]
Don’t feel like setting up Jenkins you lazy bum? Fine. Try this on for size: use a Github service hook to ping a Django view which runs a bash script out of process. Sound like a bad idea? Probably, but bad is a relative thing you see… here’s how: Gonna need the at command. Do [...]
SOAP is a bit foreign to me (JSON + good documentation seems so much easier), but I finally managed to authenticate DocuSign with a SOAP client in Python. The code below assumes you have a developer account all set up and have suds, the Python SOAP library, installed: from suds.client import Client class DocuSign(Client): [...]
If you use this, make sure you are PCI compliant, otherwise explore stripe.js… In case you haven’t heard, payment gateways, merchant accounts and all that jazz are now obsolete thanks to Stripe. Stripe offers a simple to set up payment service with an absolutely wonderful API. Instead of comparing and contrasting dozens of merchant accounts [...]
Call me a sucker, but I love a good server setup as much as the next guy, I just have a little trouble setting it up sometimes. So I thought I’d walk through my process for setting up all this Django goodness on what is basically a LAMP setup (where “P” stands for Python!) with [...]