Denizen: Drop-in user management and payments

Hi bootstrappers,

Since many of you are building SaaS apps, you know that building your core product is only a part of the challenge.
To actually run the business, your app needs a ton of generic stuff:

  • user registration + email verification
  • forgot-my-password emails
  • add/edit credit card
  • change plan
  • payment invoice/receipt emails
  • “your card failed, login and update so we don’t shut down your account” emails (aka “dunning”)

Frameworks like Rails have components to do pieces of this, but nothing comprehensive.
People using other languages like Go, Node.js, Clojure, or frontend-only stacks are mostly out of luck: They have to roll their own solutions.

As a bootstrapper, I don’t have the team, time, or resources to do the necessary frontend design and backend server juggling to build custom solutions all the time.
That is to say, I’ve had a lot of promising lil’ apps and side projects that I never launched because it was just too much work to put 'em online and start charging.

My friend and I have been working for the past several months to try and factor out all of this stuff and “solve it once and for all” = )
Our solution is similar to Stripe’s “checkout” button: Give folks a single snippet of JavaScript that provides fully styled, responsive forms and the necessary backend machinery.
You can see more details on our landing page:

or this 9-minute zero-to-SaaS app YouTube overview:

The basic idea is that you can either spend $10k + 2 weeks to do this boring stuff custom, or you drop in some JS that solves 95% of what you need and get on with shippin’ your core product.

I’d love to hear what ya’ll think:

  • Does this solve a problem you have?
  • Could you ship something faster by using Denizen?
  • Does Denizen let you ship a lil’ project that otherwise wouldn’t have been worth the effort?

Are there any features or use cases you’d like Denizen to support?




Just had a quick look, it looks good.

I like the user info is stored in the stripe meta fields - that’s a nice touch.

The main problem with this concept is this:
Your app goes down, my app goes down.

I have heard this idea many times before and the aforementioned issue always comes up.

The basic idea is that you can either spend $10k + 2 weeks to do this boring stuff custom

Ignoring the fact that this is not exactly true as there are a lot of available open source solutions (e.g. just googled “user management node.js”), this particular investment would be worth it. Users, their data and the ability to even login is too fundamental to outsource to a third-party, which isn’t an established company (e.g. fb, google, twitter).

To recap: Yes, it solves a problem, but the solution is too risky. I personally would never consider using third-party service to authenticate my users.

Thanks jyne131!
We didn’t want to rely on “lock in” to force people to keep using our service—putting the user info in the stripe metadata fields lets our customers easily get their users’ info and move to other products or in-house offerings if they grow beyond what Denizen can provide.

Hi Jeff,

I definitely agree—we address this specific issue directly on the landing page.

Denizen runs on autoscaling servers on EC2 behind a load balancer for zero downtime deployments and redundancy. We’re moving soon to distributing across geographically separate datacenters.

That said, if your app has high-availability requirements then it’s ultimately your responsibility and third-party services like Denizen may not be suitable.

This looks great. I have searched for and thought about building a service like this several times. I ended up using Memberful, which is working ok, but not perfect.

I have a couple questions:

  1. Do you use Stripe’s subscription feature or do you manually make the charge every month? If you are using Stripe’s subscription feature then I can use Baremetrics, which would be nice.

  2. How does your login piece fit with the rest of my site? Can I store custom data in Denizen (and have the user edit it)?

  3. One of the great things about Denizen is that it doesn’t require a server-side component. AngularJS and Firebase is my favorite architecture right now. Can I integrate Denizen login into AnguarlJS/Firebase without having to add a server?

Hi @chaddeshon, thanks!
Responses in order:

  1. Yep, Denizen leverages Stripe subscriptions directly. This means:
  • Stripe ensures the card charge succeeds before adding them to the plan
  • Your plans can have free trial periods setup automatically through Stripe
  • You can use Stripe’s dashboard or API to adjust your customers’ plans as necessary for manual overrides or other special cases
  • Stripe add-ons like Baremetrics will work just fine
  1. Right now we are not exposing an API to let your server make notes or store other data on customer objects. If you have a specific use case in mind, I’d love to hear about it via private message / email.

  2. No, Denizen currently requires that you have a server. This is because we’re modeling our API on Stripe’s, which uses a shared secret key that only your server should have.

Stripe-based billing management & reminders would definitely be of value to me (I’m deferring building any of that until I get signup volume at a higher level). To echo @jeff… I’d rather keep the user data at home and manage signup/login/password features within my app.

@coreysnipes re: keeping all of the data and managing everything within your app, do you mean that you’d rather have full code rather than use a hosted service?

E.g., the Rails SaaS starter kit: ?

The advantages/tradeoffs of that approach are very different than using a third party hosted service: On one hand, you can do whatever customizations you need and run all of the infrastructure yourself.
On the other hand, you have to run all of the infrastructure yourself, which means you’ve got to stay on top of password hashing algorithm strengths, email delivery, responsive templates for login forms, &c.

Or is there another way that a product could deliver this value beyond this hosted vs. do-it-yourself-kit split?

@lynaghk - sorry, I misspoke. I’d rather do the user management stuff myself, and use a hosted service just for the payment & subscription handling. I’m already dealing with email deliverablilty, as we generate a ton of system email for different workflow events, reports, etc. (Not to downplay it – deliverability is super important.) Password hashing algorithms falls into that bucket of stuff I consider Nice to Have, or rather Something We’ll Deal With When We Get Big.

Hi Kevin,

I like the idea. One thing comes to mind tho, I’m not a programmer so forgive me if this is a foolish question. It sounds like Denizen just does user access/management and onboarding, would that be correct? So, would be useful to control membership access to static content or apps that dont keep user’s data. What about, for example, a project management app? I imagine in the scenario of custom-building a denizen alternative, there would also be server related stuff to separate users’ data, and create new instances each time someone signs up and that kind of thing. What’s Denizen’s approach to this situation?

Again, I apologize for my layman-speak.


Hi @mmalo,

No need to apologize for “layman-speak”: One of the reasons we are building Denizen is so that folks can avoid computering-complexity and get on with shippin’ their core business = )

The primary mechanism Denizen provides is the ability to associate users with Stripe subscriptions.
For example, you can make a sign up form in one line of HTML that takes peoples credit cards and signs them up to be on, e.g., “The gold plan”.

All Denizen does is tell your server about this, and so your server is responsible for serving those people the right page.
Here’s some example code for a tiny server that controls access to static content:

(In the video linked from the README I show how to update the example to accept credit cards.)

This is how uses Denizen to sell several levels of Photoshop tutorial videos.

Does that answer your question?

Thanks for the quick response Kevin. Yes, I think that answers my question. So the way I’m understanding it is that for a full fledged web application (as opposed to just needing to serve up the right page based on the ‘subscription’) Denizen saves on some of the work but there would still be required the usual solution be built to manage the users’ data etc. on our servers.

Right now you’re going to have to have your own server, yeah.
You won’t always need to store your own data, though—in the case of the Retouchalot site, they are serving pages based on the login info provided by Denizen. There’s no database for that site, just a stateless web server.

Good idea, I like it.

I used OpenId and OAuth in a few of my projects, so I’m aware of convenience of getting rid of user management code.

I’m puzzled by the Stripe vendor lock-in though. What if FastSpring is my choice?

I understand all the good vibe about Stripe, but they are not going to stay the best provider for long; they will eventually be bought by some old ugly corporation and will start doing ugly things to their small customers.

Another puzzlement came from the pricing page. There is no charge until a user is charged. Does it mean I can use this solution for a free site forever and for free? Or, quite opposite, I cannot use this solution for a free site at all (because it requires to enter CC into Stripe)?

Thanks @rfctr!

Stripe isn’t the best for everyone, but we decided to focus on them first. If Denizen doesn’t get traction on top of Stripe, it’s probably not going to get traction on top of any other payment provider. (Though if we do get traction we’re certainly open to integrating with other provider.)

We originally started with per-user charges, but we decided it was confusing and a barrier for potential customers. In response to your question: Yes, you can use Denizen for login and if you don’t charge your users anything we won’t charge you anything. Though if your site has 100k daily visitors we might have to talk =P

Note that even for a free site, though, you’ll need to connect to a live Stripe account to get production keys.

Every time I sit down to build something I think of this. For those of us not using Rails with its Rails-kit, it makes total sense I think. An easy way to have get your SAAS app going fast.

I would do exactly what does, with its api I can track events and send emails to users. I think it would be good to still keep login and session management within my app, but I’d have an easy REST API which I could do:

User Management (profile management, CRM type stuff)

Then i’d add all the stuff included that I know have to pay each individual app for:
Billing management (chargebee, recurly etc)
Basic helpdesk (zendesk)
Drip emails (


So Im curious. How is this going? What does the market think?

I cant think why it wouldn’t work apart from security concerns? But then if you left session management within the app the dev is building and use Denizon as an extension of the user, its surely a winner!

I completely forgot about this and was thinking about building something similar myself, though the implementation would have been very different. I’d also be interested to know how this went?

The uptake has been slow: The segment we are targeting are people who want to build a SaaS app but haven’t yet implemented the user management stuff — it turns out these people are very difficult to find = )