Since ScreenshotOne was launched in 2022, the authentication process hasn’t changed much except for the migration from Go to TypeScript and, as a consequence, using Next.js and NextAuth.js for the dashboard authentication instead of Go and raw HTML with CSS.
The authentication flow just worked, but accumulated a lot of feature requests and UI/UX issues.
I decided to fix most of them at once and share with you the results and the reasoning behind of the decisions.
By the way, you can try the new flow at the dashboard sign-in page. Any feedback is much appreciated, feel free to email support@screenshotone.com.
Migrated from NextAuth.js (v4) to Better Auth
NextAuth.js (v4) and its successor Auth.js are great libraries. I had been using NextAuth.js (v4) and it was time to upgrade to Auth.js. While researching all available authentication libraries for Next.js, I discovered Better Auth.
The main reasons why I chose Better Auth and went with it:
- It supports email and password authentication out of the box, which I planned to add anyway.
- Change email flow is also supported out of the box.
- It has feature parity with NextAuth.js (v4) and provides a simple migration path—there was nothing to lose.
- It is in active development and has a lot of potential.
I even managed to made a tiny contribution to it:
Email and password
It was a few lines of code to add it with Better Auth:
That type of authentication was requested by many users. But I didn’t hurry to implement it. I was weighing upsides and downsides of adding it. Plus, NextAuth.js (v4) didn’t support it out of the box.
Today, after seeing email providers having outages, I think it is worth adding it. At least users who already signed up, will be able to sign in the case if emailing is not working.
Change email flow
Once a year, a ScreenshotOne user requests to change their email. I didn’t implement it from the start and often did manually when I received support tickets.
But, luckily, Better Auth has a built-in flow for that:
It took me a few hours to implement, test and deploy the new change email flow.
Email verification is always required
I made email verification a required step for the new sign-up flow, except if the email was already verified by third-party providers like Google or GitHub.
It might reduce the number of successful sign-ups, especially if due to some reasons verification emails are going to spam.
But I want to make sure that all users have a real verified email address. For an API product like ScreenshotOne it is a must, because if something happens with integrations, billing, or quota limits are reached, users must be notified and able to react.
Otherwise, one of their critical integrations might fail and they will not be able to know about it and react.
In case, if it was a casual SaaS product or not a critical component for businesses, I would consider, not requiring email verification.
Check your inbox
Once a verification email is sent, instead of showing a successful “toaster” message:
Now, you will be redirected to a dedicated page:
It will reduce the frustration and support tickets. Since not everyone notice that the email was sent and often request to send it again.
GitHub
ScreenshotOne is not only, but mostly a product for developers and most of them have a GitHub account. Adding GitHub authentication as an option should simplify the sign-up process.
And indeed, the hypothesis was correct. Only a few days after launching GitHub authentication, there were already users signing up with it.
Closed authentication for authenticated users
One of the NextAuth.js (v4) features is linking accounts for signed-in users. It led to creating one user with the primary email and then many linked accounts with different emails.
It also led to users having multiple accounts with the same email address if they signed up later with a non-primary email.
All of that caused more confusion and support tickets, so I closed it.
But with Better Auth, it should be irrelevant altogether since it links accounts by email. Anyway, it is still better to close the authentication flow for authenticated users.
Improved error rendering
Before the update, the error rendering was not very user-friendly. The toast message was used to display the error.
But did users see the error?
To make sure that users always see the error and can react to it, the error message is now displayed clearly right in the form:
That way, users will never miss it.
Last used method
Often users forget which method they used last time to sign in. In general, it is not a problem, since ScreenshotOne will link verified accounts automatically.
For example, if your GitHub email differs from the Google email you used to sign up for ScreenshotOne, this might lead to creating an additional unnecessary account.
For such cases, it is better to know which method was used last time. There is nothing to lose in UX/UI, but only gain for users who return and sign in often.
Added legal links
Added terms of service and privacy policy links to the sign-up and sign-in pages.
In case if potential customers have any doubts or questions, they can read the terms of service and privacy policy and be able to figure out what they sign up for.
Improved email sending
Migrated to Resend
I migrated to Resend and subscribed to a paid plan even though I don’t need to.
One of the important features of the product for me is that its makers do take care of it.
When I got a transactional authentication email from Resend, I replied to it to check if they respond and how much time it will take.
They not only responded but helped me troubleshoot some other issues.
The same applies when I mentioned minor UX/UI issues—their founder replied that they will take care of it:
Also, DX of Resend is one of the best in the market, and it seems it will be cheaper for my needs than Mailgun long term.
Configured a different domain
It is a good practice to use subdomains for emails instead of the main domain to avoid losing sender reputation in case something goes wrong.
I configured a different domain for email sending to make it more recognizable and avoid being marked as spam—notifications.screenshotone.com.
I will send transactional emails only from this domain, using the team@notifications.screenshotone.com address.
Changed the HTML template
I installed the React Email library to render emails with React and created a custom template instead of using the one provided by the NextAuth.js (v4) library.
Before:
After:
Improved validation
No disposable emails allowed
There is no drawback to blocking disposable emails.
Seriously oriented customers who see the value of the product and know why they are signing up never use disposable emails anyway and sign up with their work emails.
ScreenshotOne will not allow disposable emails when signing up anymore. In the majority of cases, they were used to sign up for the free plan and exhaust its credits.
Normalization of emails
However, users will still be able to sign up with email aliases.
While I haven’t seen paying customers signing up with aliases, or if it was very rare, I decided to allow using email aliases.
Organization-related improvements
Allowed more members
One of the organizations reached their max member count of 10, and I had to increase it to 50 to forget about it for a while. 50 members seems to be a good number for most organizations and it is way out of the typical pattern ScreenshotOne currently has.
An average organization as an entity in ScreenshotOne has 2-5 members, even when represent really large companies.
A few thoughts and ideas
If you have any suggestions or questions, please feel free to contact at support@screenshotone.com.