🎯 SaaS dev challenges - #02 🗝 ️Authentication

In my previous post, I talked about how UI/UX is a challenge you face right after you start your SaaS. TLDR: Use an existing UI library like Tailwind UI, have your components documented (like this), and get inspiration from other SaaS websites, but always add your own UI/UX style.

​

TLDR:

• 1 - Why should we authenticate our users? It’s in their best interest.
• 2 - Obligatory auth pages: login, register, and forgot.
• 3 - Optional auth pages: invitation link, magic-links… (better UX 😙🤌).
• 4 - Should you build your own auth system? Yes.
• 5 - Should I use a commercial Auth/Authorization provider? No.
• 6 - Let your users test the app then ask them to register 😙🤌).
• 7 - Should I add Authorization logic? At least identify the userType.

Remember these takeaways are based on my experience.

​

1/7 - Why should we authenticate our users?

Every SaaS application’s main goal is to grow its MRR, so the easy answer would be “to charge our users” for using our app.

But really, what’s the real reason we should authenticate our users?

Imagine our previously created invoice form:

1. Our unauthenticated user 👨 creates a quote (/quote/cl2d1lgc4000909) and sends the PDF to their client 👩.

2. 3 days later, the client 👩 asks for a quote modification.

3. Our unauthenticated 👨 user realizes he closed the browser and did not write down the quote-URL (/quote/cl2d1lgc4000909). So he creates the quote again, from scratch.

Of course, you could include the quote-URL in the email, but that’d be a horrible user experience for future quotes. So it’s in their best interest to be identified on every page reload and show them all their data (even if they don’t realize it).

Authentication is on every SaaS application’s core system, so we either come to terms with it or suffer every time we’re building our next SaaS app idea.

​

2/7 - Obligatory auth pages

Every auth system needs at least a Log-in page, a Sign-up page, and a Forgot-password page.

It’s up to you to decide what to customize, for example, you could:

• Login - Add 2FA.
• Register - Send an activation email.
• Forgot - Ask for a secret question or Captcha.

But I suggest you follow these principles when signing up new users:

• Ask for as little information as you can (maybe just email and password).
• Don’t ask for a credit card, you’ll scare away a lot of leads.
• Assume your users will add ” e M a il sliKE@thisone.com ”.

​

3/7 - Optional auth pages

We’re trying to build a great user experience, these are 2 things you could add:

​

1) Let your tenants invite their members.

Your register page should be for Tenant Admins, not Tenant Users.

​

2) Make a simple referral program system.

What’s an incentive you can give to a customer to invite other users? Use your imagination but it could be: new customer subscription share, fixed $$$ pro-features…

This would expand your customer acquisition strategy, and remove the friction of asking every user to visit the /register page first.

​

4/7 - Should you build your own auth system?

Let’s get real here. You will probably build more than one SaaS application in your career, so learn the fundamentals, keep it simple, and build your own authentication system because you’ll reuse it on every one of them: /login, /register, /forgot-password, /reset-password, /invitation-link, /magic-link…

​

5/7 - Should I use a commercial Auth provider?

Of course, you could use Auth0, or Okta, but auth design/dev is not hard as it appears to be, especially in 2022. And why keep your data on a third party? You can’t control what you don’t have.

It’s better to add social account integrations for app features, not app authentication (eg: after a user signs up, let them integrate connect their Instagram account to load all of their photos).

​

When to use third-party Auth systems?

Don’t try to build your auth system from scratch when:

• You’re just testing a quick MVP.
• You’re building a B2C application where you’ll most likely need many of their supported social identity providers: Instagram, Twitter, Gmail, Facebook, Apple, Microsoft Account, LinkedIn, GitHub, Dropbox, Paypal, Basecamp, Salesforce, Shopify, Evernote, Discord, Figma, Slack… you get the point.

​

6/7 - Let your users test the app, then ask them to register

There are a lot of things a user will think about before subscribing to your SaaS. Don’t give them a reason to leave. Let them test your application before you ask them to register.

To use the invoicing app as a reference:

• Add a /create| URL to let the unauthenticated user create an Invoice.
• Warn your users that they will be asked to register when exporting the invoice PDF.
• Save the invoice to an “unauth-invoice” database table.
• Does the user want to export it as PDF? Ask them to register first.
• Did the user sign up? Transfer the invoice to the “invoice” table, where there’s a tenantId property.

But be careful, we all hate when we get deceived by a website (eg: The app lets me design something for 1 hour, but I cannot download it unless I pay $25). So let your unauthenticated users what they won’t be able to do if they don’t sign up or pay after a certain point in their application use.

​

7/7 - Should I add Authorization logic?

Start with something as simple as:

• User is an admin? Redirect to /admin
• User is a tenant? Redirect to /app
• User is a tenant and wants to access /admin? Redirect to /401

But plan for some authorization logic in your pages:

• /app/:tenant/settings/organization should be for TenantOwners only.
• /app/:tenant/settings/subscription should be for TenantAdmins only.
• /app/:tenant/contracts should be for TenantMembers only.
• /app/:tenant/public-contracts should be public (for unauthorized users).

​

Conclusion 🧑‍🔬

That’s it for this section, I hope you found it useful in some way. Remember to take with a grain of salt 🧂 every Auth post/tip out there, especially this one.

Now that we identified our users, let’s charge them to use our SaaS on a monthly/yearly basis 🤑. Stay tuned for the next 5 planned posts:

• #03 - 💸 Pricing (subscriptions, payments, cards…)
• #04 - 👩‍💼 Admin (tenants, dashboard, Helpdesk, CRM, API keys…)
• #05 - ⚙️ Settings (profile, members, permissions, dashboard, API keys…)
• #06 - 🛬 Landing (GDPR, multi-language, dark mode)
• #07 - 🦄 The Actual SaaS Application