This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.

This will be the last edition of the SaaS Weekly newsletter.

Thank you everyone for your support, comments, thoughts, and time. If you need me, you can always reply to any of these emails.

The Best Bits

• Write more useless software.
• Some thoughts on relative dates.
• Shadcn/ui for Vue.

Finding your Happiness

As I wrote above, this will be the last edition.

I recently read The Subtle Art of Not Giving a F*ck by Mark Manson. I'm a sucker for self-help books. I love a book that'll tell me how to un-f*ck my relationship or make me tons of money. Preferably in my pajamas in the Bahamas. All at once.

But truthfully, I was looking for a way to understand the feeling I was having. This reluctance to put out more content.

What I thought I wanted for a long time was an audience. I've seen people do incredible things with their audience on Twitter, YouTube, or whatever. Once you have a large audience, you can launch products and get feedback easily.

Having a large audience is a superpower. It still is. The audience was the goal.

But growing an audience is a grind. Lots of content, solving small problems, and time. And that wasn't bringing me a lot of happiness. The content I was creating felt uninspired and a chore. I didn't relish writing. I didn't love making YouTube videos. It wasn't terrible! I enjoyed helping people. I'm proud and happy of those who I've helped. But the act of doing all the work wasn't that enjoyable. It wasn't bringing happiness.

And if the journey wasn't making me happy, the goal wasn't going to magically make me happy.

I have 4,000+ subscribers on YouTube. That's a lot more than the zero I had when I started. I'm a part of the partner program. These are fantastic accomplishments. But the 4,000 subscribers themselves didn't magically make me happy.

So what? Will I magically be happy at 10,000? 50k? 100k?

Happiness isn't magically reaching an arbitrary number.

Happiness comes from solving problems along the way and enjoying the process.

And again, I don't hate making YouTube videos or writing content. But when I tied it to my business, consulting, and audience growth, the fun of it all was weeded out. It wasn't bringing me happiness.

And it's time I'm honest with myself. To listen to the emotions telling me it's time to change. It's time I find new problems that I enjoy solving.

I want to find interesting problems that I love working on. A team I can bond with and tackle hard things together. These things I miss. It's what I want.

And I want for you, dear reader, to find what makes you happy as well. And jump in and tackle it with your passion and gusto.

So keep it up. Keep learning and trying things. Find what makes you happy. And toss aside those things that don't. Life is too short.

-- Ethan

This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.

Correction: An astute reader wrote in and pointed out that the code and output of the tech tip section didn't match. I had originally written the code for light backgrounds, but the output didn't look good on dark backgrounds. When I updated the code, I forgot to put the new version in the newsletter. Thanks, Brian! You get a ⭐️.

The Best Bits

• Going paperless.
• 300+ Tailwind components for your site.
• How Instagram scaled to 14 million users with only 3 engineers.
• An open-source micro framework for observability.

What's in a UUIDv7

UUID Version 7 (UUIDv7) is a time-based identifier that encodes a Unix timestamp with millisecond precision in its first 48 bits. Of the entire UUID structure, 6 bits signify its version and variant, while the remaining 74 bits are randomized.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           unix_ts_ms                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          unix_ts_ms           |  ver  |       rand_a          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |var|                        rand_b                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            rand_b                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Due to its time-ordered design, UUIDv7 values are essentially sequential, resolving the index locality issue prevalent in databases. This sequential nature of UUIDv7 offers better database performance compared to the random design of UUIDv4. A study from the 2nd quadrant blog demonstrated that sequential UUIDs outperform random UUIDs in both writing and reading tasks.

Importantly, UUIDv7 maintains the standard UUID structure, ensuring it's compatible with systems currently using other UUID versions. This makes transitioning from UUIDv4 to UUIDv7 in systems like Postgres straightforward.

In my applications, I've been creating primary keys with the format:

prefix_UUIDv4

Where the prefix is a ~3-character identifier that identifies the resource. This makes it very easy to see what resource a key is for just by looking at it. I often take out the dashes as well to make it easier to copy.

The downside with my strategy is that the only column that works with this is text in Postgres. I can't use serial or uuid because it's neither of those things. This can lead to the same problem mentioned above, where the sequential writes result in poor index formation.

I'm excited to try the new UUIDv7 format for primary keys gaining the advantage of a time stamp as well as the uniqueness of a UUID. I will lose out on an easy identifier in that transition. We'll see if it's worth it.

Tech Tip

Some sites will use the favicon as an icon that can change depending on the site status (such as an alert or dashboard). You can do this easily with React:

import React, { useState, useEffect } from 'react';

function FaviconChanger() {
  const [faviconState, setFaviconState] = useState('default');

  const faviconMap = {
    default: '/path-to-default-favicon.ico',
    alternate: '/path-to-alternate-favicon.ico',
    // ... you can add more states and associated favicon paths here
  };

  useEffect(() => {
    let linkElement = document.querySelector("link[rel*='icon']");

    if (!linkElement) {
      linkElement = document.createElement('link');
      linkElement.type = 'image/x-icon';
      linkElement.rel = 'shortcut icon';
      document.getElementsByTagName('head')[0].appendChild(linkElement);
    }

    linkElement.href = faviconMap[faviconState];
  }, [faviconState]);

  return (
    <div>
      <button onClick={() => setFaviconState('default')}>Set Default Favicon</button>
      <button onClick={() => setFaviconState('alternate')}>Set Alternate Favicon</button>
    </div>
  );
}

export default FaviconChanger;

You can add this logic to another component instead of making it a separate component.

Cloud Chronicles

• YouTube Subscribers: 4,205 (+131 in the last 7 days)
• Newsletter Members: 781 (+27 in the last seven days)

My contract is going well! I'm ending week three, and I feel like I have my feet under me. I'm starting to impact some change at the company, and that feels good. I've also been reading The Subtle Art of Not Giving a F*ck to see if that imparts any wisdom with my approach to running my business.

Last Byte

• Making hard things easy.
• A modern Wine wrapper for macOS to run Windows games on Mac.

This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.

Up here in the northern hemisphere, the leaves are starting to change, and the air is getting colder. We've entered the 4th quarter of the year, and there will be a lot of business done in the next three months. Go get 'em!

The Best Bits

• Site Reliability Engineering.
• Store.app, an app store just for web apps.
• Radix Themes released version 2.0 with many component improvements.
• Contentlayer makes content easier to manage in your app.
• HTTP/3 adoption is growing rapidly.

Service Level Objective

I have done an absolute ton of reading and understanding in the past two weeks. While I have done a lot of work building and running SaaS apps, I haven't done a deep dive into doing it at scale. Well, scale where people actually use your app.

When you're talking about this level of scale, you immediately need to answer questions such as:

• How much can your service be offline?
• How quickly does it need to respond to incoming requests?
• How many concurrent users does it need to handle?

The answer to these questions is nuanced and should be thoughtfully answered.

The answer will depend on your users, application, and competitors. It should not use the current state of the software as a starting point. Instead, understand what your users are expecting and meet them there.

The answer is never, "We must be up 100% of the time". With a few exceptions... antilock breaks are one of them. Otherwise, that level of availability is actively bad. Users won't notice the difference between 99.9% and 100%. The network they use is less reliable than 100%, so there is no way it will work for them all the time anyway. To achieve that level of reliability will require enormous effort and money.

It makes much more sense to pick a smaller number, often around 99%, that you want to aim for.

The difference between 100% (perfect) and 99% is your error budget. In this case, that's 1%. That's about 7 hours a month you can be unavailable.

Now that you have a budget, you can start to spend it. It's actually better to spend the budget than to try and shoot for perfect. Remember, the SLO represents what the user finds acceptable. That means it's okay to be down for an hour here or there. But when your budget is all spent, you can no longer risk being down.

This attitude shifts how you think about risk. Instead of defaulting to "I can't do anything risky," you can shift the team to consider doing risky events when you have the budget to spend. When your budget is tight, work on tasks that will improve reliability.

This gentle back and forth will prioritize the work for you. Features when you can be risky, stability when you need to be careful.

And it all comes from the SLO.

Tech Tip

Colorizing console logs can enhance debugging in web development.

Or not. But it can look cool!

By using different colors, developers can categorize, prioritize, and quickly scan through logs, identifying relevant information at a glance. This not only makes the console more visually appealing but also aids in faster identification of issues or important events.

The browser's console allows the styling of log messages with CSS properties, offering a versatile tool to customize log output.

// Simple colored text
console.log('%c Light Blue text', 'color: #87CEEB;');

// Bold text with a subtle background color
console.log('%c Important log', 'color: #FFD700; background-color: #555; font-weight: bold;');

// Using multiple styles in one log
console.log('%c Error: ', 'color: #FF6347; font-weight: bold;', 'Something went wrong.');

// Text with a shadow
console.log('%c Glowing text', 'color: #32CD32; text-shadow: 0px 0px 5px #7FFF00;');

// Mixed styles in a single statement
console.log('This is %cStyled Text%c and this is not.', 'color: #FFC0CB; font-style: italic;', 'color: #B0C4DE; font-style: normal;');

Cloud Chronicles

• YouTube Subscribers: 4,074 (+129 in the last 7 days)
• Newsletter Members: 754 (+24 in the last 7 days)

Another week of being super busy with my new contract. I think the insanity is slowing down though, so my evenings are a little freer. I need to figure out a new schedule for content and then execute it.

Last Byte

• An interactive intro to CRDTs.
• Goodbye integers, hello UUIDv7.
• Tamagui is a UI framework for the web and React Native.

This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.

Starting anything new is both exhilarating and daunting. There is so much promise and uncertainty, a tantalizing promise of what might be and if you will be able to achieve it. Only one way to find out.

The Best Bits

• Kagi is a paid search engine that is better than Google. They now offer unlimited searches for $10 a month.
• ChatGPT can now understand images, listen, and speak. Integrate this with your SaaS for impressive features.
• Postgres can be used as a queue (Like SQS, Kafka, or RabbitMQ). And it's not even bad at it!
• Subdomain Center, A SaaS that finds all the subdomains of a given domain.

How I learn when joining a new team

I recently started a new contract with a midsized software company. This company makes over $100 million a year in software revenue and has a large (200-ish) software development team.

My job is to help them increase their observability throughout their infrastructure and application stacks.

It's taken me about 24 hours (spread over 4 days) to understand everything I need to understand to accomplish that job. I've worked about 6 hours a day.

At this point, I understand:

• How they organize their projects, write feature requests, review pull requests, and organize their Git projects.
• How their build pipeline works, where the shared libraries are, and where they store build artifacts.
• What their infrastructure looks like, how it functions, how data flows in and out of the apps.
• How the apps function, what they do, how they do it, and how the company makes money.
• How they observe, monitor, fix issues, run their DevOps, handle rotations, pagers, and where the team responsibilities are.
• Lots of nitty-gritty details on the GitOps flow, software used, packages, and politics.

It's a lot.

Here's my strategy for joining a new team and getting up to speed quickly.

1. When you show up on day 1, you've already been hired. You've been vetted. You've gone through the challenging interview process. No one wants to see you fail. Everyone is on your side. You need to leave the mentality of "Oh my god, what if people don't like me or think I'm good" behind and step into the mentality of "I've been hired to do a job and do it well. Help me get there as quickly as possible." Mindset is everything.
2. Start with what you know. It doesn't matter if you are a junior developer or a senior architect. Every place does things differently, but there are lots of commonalities. Start there. Find the things you know and start branching out from there. For me, I know how infrastructures and apps work. What I didn't know was how exactly this company applied those techniques.
3. Ask questions. Say upfront, "I'm going to ask a million questions." And then ask a million questions. Be smart about what you are asking. If it's something you can Google, do that. If you can ask ChatGPT what something is, do that. Don't drop proprietary code or data into ChatGPT if it's against company policies. But you can ask how things work generally or remove data to make a question more general.
4. When learning something new, bring it back to what you know. I've used ArgoCD a lot for Kubernetes continuous deployments. This company uses FluxCD instead. I specifically asked ChatGPT to compare and contrast those two things and give full examples of how both work end-to-end. I read the docs on Flux and set up an example app that's deployed with it. I now feel comfortable enough to know how it works. But I started from what I already knew.
5. Learn the stack, either bottom-up (infrastructure first, then application layer) or top-down (how do the apps work, how do they communicate, how do they run?). Depending on your skill set, you will be happier starting at the top or bottom of the stack. As an architect, I like going bottom-up. Show me the infrastructure because that defines what can communicate and how they do so. Then tell me what the apps do. At the same time, I talk to the product organization to learn how the company makes money and builds a product so when I get to the code, I can check... is this really doing the right thing?
6. To learn all these, ask who can give you brain dumps via meetings and schedule as many as you need. Drop a meeting on their calendar, ask important questions you can't learn from Googling/ChatGPT, and understand the pain points. At the end of each meeting, I like to ask, "What am I not asking? What do you have on your mind that I might not know about?" It helps uncover my blind spots and leads me to new things to investigate.

That's how I've onboarded to a new company and team in 24 working hours. I'll be starting to work on the implementation in the next day, knowing how the product works at a high and low level.

Tech Tip

GitHub - 99designs/aws-vault: A vault for securely storing and accessing AWS credentials in development environments

A vault for securely storing and accessing AWS credentials in development environments - GitHub - 99designs/aws-vault: A vault for securely storing and accessing AWS credentials in development envi…

GitHub99designs

A common setup in AWS is to have roles with elevated permission that a user assumes when they need to take an action. Assuming this role, especially when protected with MFA, is... annoying.

Luckily, AWS Vault is a great command line tool that lets you assume a role on the command line so you can execute commands with it. You need to set your AWS profile configuration to have the role you want to assume:

[default]
region = us-east-1

[profile admin]
mfa_serial = arn:aws:iam::111111111111:mfa/admin

And then you can run the following:

aws-vault exec admin -- aws s3 ls

Cloud Chronicles

• YouTube Subscribers: 3,945 (+166 in the last 7 days)
• Newsletter Members: 730 (+34 in the last 7 days)

This week, I've been super busy onboarding at my new contract, and my kid was sick for a few days, which took a lot out of me. I'm hoping to get a video up soon, though, so stay tuned.

I played around a little bit with ChatGPT's image recognition, and it's... quite impressive. It was able to read a receipt and transcribe it perfectly. Lots of fun opportunities for building around this new tech.

Last Byte

• A TypeScript Bun web framework, Elysia.js.
• Raspberry Pi 5 is coming out.
• Paisa, an open-source finance manager. Not a SaaS, but you could take this and build a similar thing as a SaaS.

This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.

The best side project is the one you work on. It's also the one you use. The perfect place to start building something is to find something you do every day and replace it with your own version.

The Best Bits

• DALL·E 3 is out. While we can argue over how good it is, the fact that it has an API means it can plug into every SaaS out there.
• Next.js 13.5 has been released with faster local dev, less memory usage, icon library improvements, and lots of bugs fixed. There is also a Next.js conf on October 26th.
• HyperDX is an open-source observability platform unifying session replays, logs, metrics, traces, and errors.
• V0, a generative user interface system by Vercel. It generates copy-and-paste React code based on shadcn/ui and Tailwind CSS.

What is Bun?

Bun is an all-in-one toolkit for JavaScript and TypeScript apps.

Okay, what does that really mean?

Bun was created to answer the question, "If you were to build a JavaScript runtime today, what would you do differently?"

You see, running JavaScript on the server was very hard for a long time. There wasn't a good way to do it, and when you could, it was like running a limited browser session on your computer. There was no way to interact with the file system, open sockets, or do anything useful.

When Node.js came out in 2009, it had a revolutionary idea: A standard library that allowed your JavaScript code to interact with the host running it. Suddenly JavaScript could be run on the server and could do anything other languages had the ability to do.

We've learned a lot since 2009.

These days there are multiple tools web developers need to use to get anything done. We rarely think about it being a problem because... well, it's always been that way. Things like npm, yarn, lerna, pnpm, tsc, Webpack, Babel, and more. Each of these is a separate tool but needs to work in harmony to build, test, and deploy a modern web app.

Bun does all of that.

And it does it in a single binary: bun.

It's hard to overstate how powerful that is. Bun is the runtime for your code. It's also the package manager that will manage your dependencies. It's a weird artifact of time that has caused npm and node to be separate binaries and projects.

Bun looked at all that and said: "Wait. This makes no sense!"

Bun goes further, though. It can run TypeScript and JSX code without needing external code. Yes, it still compiles TS to JS internally, but that's abstracted away from the user. You can just do:

bun script.ts

And it just... works. In fact, it works so well that they recommend not necessarily transpiling your code for production. Leave it all in TypeScript. Let Bun do the work for you.

The goal is to have Bun be perfectly compatible with Node.js and for it to be a drop-in replacement. There are lots of guides you can take a look at to see how you can use Bun with our favorite framework.

I'm going to try it out for my next projects and hopefully switch over for good. Let me know your experience!

Learn to Build SaaS

In my Time Tracker series, I set up the app to use OAuth with Google, but I never came back and created a video for it. Well, here it is! This walks through the entire Google Cloud Console part as well as the Next-Auth part. It pairs well with my Next-Auth guide if you want to customize it.

Tech Tip

When using the AWS command line, you can quickly sync a directory to an S3 bucket with a single command:

aws s3 sync ./local-folder/ s3://bucket-name-here/

This is useful for backing up files or hosting a website.

Cloud Chronicles

• YouTube Subscribers: 3,779 (+175 in the last 7 days)
• Newsletter Members: 696 (+47 in the last 7 days)

This wraps up week two of successfully publishing videos on time! Big win in my book.

In other exciting news, I signed up my next big client! This contract will be worth about $75,000 and extend until the end of the year. I'll be helping the company with their DevOps layer (Yes, I can do DevOps, thanks for asking), as well as other work they want me to tackle. I think this will turn into a great series of how to run your apps in production so that when things break, you know how to fix them.

I'm hoping to still land one more deal in the next few weeks, but it's been a slow process.

Last Byte

• A fantastic story on debugging a problem: My car is allergic to vanilla ice cream.
• No sacred masterpieces.
• Full-featured admin for Next.js and Prisma.

This guide runs through the full setup of OAuth with Google as the identity provider. This will let your users log in with Google.

Google Cloud Console

The best way to get through the console is to watch the video above.

Google Cloud Platform

Google Cloud Platform lets you build, deploy, and scale applications, websites, and services on the same infrastructure as Google.

You will need to create your OAuth consent screen and then create the OAuth Credentials. With those, you can setup Next-Auth.

Session Helper

I like to create a helper function that will return the user in a session from the server.

import { User, getServerSession } from 'next-auth'

export const getUserSession = async (): Promise<User> => {
  const authUserSession = await getServerSession()
  return authUserSession?.user
}

If you need to pass through additional data, you'll need to use the same session method to ensure that data is correctly passed through:

import { User, getServerSession } from 'next-auth'

export const session = async ({ session, token }: any) => {
  session.user.id = token.id
  session.user.tenant = token.tenant
  return session
}

export const getUserSession = async (): Promise<User> => {
  const authUserSession = await getServerSession({
    callbacks: {
      session
    }
  })
  if (!authUserSession) throw new Error('unauthorized')
  return authUserSession.user
}

The full example makes it a little more clear.

Code

Become a free member to get the complete source code below.

examples/next/oauth-google at main · a-bit-of-saas/examples

Example code for learning. Contribute to a-bit-of-saas/examples development by creating an account on GitHub.

GitHuba-bit-of-saas

This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.

The biggest productivity hack is simply finishing what you started. Once you train yourself to be ruthless about that, you are quite cautious about flippantly starting new things. Only start what you truly want to finish.

The Best Bits

• For the adventurous, Bun 1.0 is out.
• NGINX Unit is a universal web app server. A lightweight and versatile open-source server that simplifies the application stack.
• AI Summaries of the top stories. A good idea for product ideas seems to be using AI to summarize high-value content.
• React Aria Components are now in beta.

Product Founder Fit

You hear a lot about product market fit. The idea that in order for a product to be successful, it needs to correctly fit the needs of a market. If your product isn't successful, either the product was wrong or the market was wrong.

Or both. Hopefully, you don't get it that wrong.

However, there is another fit that is very important when building a product. And that is product founder fit. The idea is that the product and the founder also need to be compatible, or else it won't be successful.

In 2016, I started working at a startup that was building a process engine. That's a fancy way to say the product would execute tasks in order, and sometimes there would be a branch in logic. You could write a process to do anything, which was very powerful but also very vague.

Think: lines of code with if statements. But instead of code, a user would drag and drop pre-made tasks in an order.

Just like how code can solve anything, so could this.

It's hard to sell a vague solution.

So, we made it more specific over time. If we could solve something more specific with our vague solution, users might see how they could use it to solve more problems.

Or, that was the idea.

What happened next was interesting, though. The specific solution we started implementing was around monitoring basic metrics to ensure a website was running.

Think, Uptime Robot.

But remember, we weren't Uptime Robot! We were a vague solution that could solve anything, and we just so happened to pick keeping a website up. But of course, if that's what we actually wanted to be doing, there were a lot better, faster, and cheaper ways to check if a website is running.

And so, it failed to gain traction.

When it failed, we pivoted.

But when we pivoted, we ended up pivoting into the area we had been doing a lot of work already. The area of monitoring. And so we went deeper down this rabbit hole.

At the time, it had made sense. We already had code written for this. We already had some infrastructure. It's not that hard to change what we had, really.

The problem wasn't the code. The problem was we had no business in the monitoring space. I wasn't a DevOps engineer, I was a full-stack engineer. My coworkers weren't ops, either. While we all knew how to keep apps running, we didn't have 10, 20, or 30 years of experience doing it.

We didn't know what the gaps were in the industry. We didn't know what the problems were.

We just kinda stumbled in and pretended like we could build something people wanted in a market we had little business in.

A place where even though there is a big market and lots of products... we didn't have a good fit. The market founder fit wasn't there.

And so, as you build your products and explore markets to jump into... make sure you are a good match for them.

Learn to Build SaaS

I'm back to making videos! The live streams will happen again (don't worry), but I need to master my process for getting videos out the door as well. This week I finish my round-the-world view of authentication by building out a password reset flow.

Tech Tip

When submitting a form, you will want to ensure the submit button is disabled the moment the form is submitted. This will stop the user from pressing the button multiple times and accidentally submitting twice.

Before, you would store that information in some state, with useState. But with server actions, you can actually get the status of a form with a new experimental hook called experimental_useFormStatus. This will expose a pending attribute to know when a form has been submitted and is pending.

To create a dynamic button, you can do this:

'use client'

import { LoadingIcon } from 'any-icon-lib'
import { Button } from './button'
import { ReactNode } from 'react'
import { experimental_useFormStatus } from 'react-dom'

export const SubmitButton = ({ children }: { children: ReactNode }) => {
  const { pending } = experimental_useFormStatus()
  return (
    <Button type="submit" disabled={pending}>
      {pending ? <LoadingIcon className="animate-spin" /> : children}
    </Button>
  )
}

Note that the button needs to be a client component.

Cloud Chronicles

• YouTube Subscribers: 3,604 (+132 in the last 7 days)
• Newsletter Members: 649 (+34 in the last 7 days)

You guys are great.

I love helping and talking with you on YouTube, Twitter, and email. I really do. When things get hard, I think about all the people I've helped on this journey and the ones I still have yet to help.

I've reset some internal expectations to get back on the right track. I'm releasing one video a week for the next four weeks. Even when things get hard, and my contract work is busy, I will get these videos out. That is forcing me to get things done, evaluate what can be better, and ensure my time is being spent well.

The first video dropped on September 14th, and the link is above. Thanks for your support!

Last Byte

• For all of us who enjoyed LAN parties growing up, here are some memories.
• Redesigned Next.js console output coming soon.
• In case you want more exciting shadows, here's another generator to make them.

Resetting a password is important to your application's security and usability. Without a doubt, your app users will sign up and then forget their password.

Nothing is worse than returning to the login page and getting rejected for a wrong password.

What password did I use again? Was there a 1 at the end? Or maybe an exclamation mark?

Well, forgetting your password and being unable to reset it is even worse.

Luckily for the builders out there, creating this flow isn't complicated and will ensure your users can self-serve and get back into your app. And what's better than that?

A note about OAuth

Before we get started, this entire article is a good reason for not asking users to sign up with their email and a password. If a user signs in with an identity provider like Google, Apple, or GitHub, you don't need to worry about these flows. If a user forgets their password, they reset it with the provider, not you. And you can still ask for the email during the signup flow.

Another option is to use a third-party provider like Auth0, which has these flows built in.

However, this isn't always practical or ideal. So, in those situations, you'll need to build this.

Overview

The flow isn't complicated for a password reset. You'll need the user's email and trust they have access to it. If they don't, or you didn't collect an email during signup (for example, just a username), then you have no way to send them a secure message.

Password reset works by assuming the user can access the email they signed up with. That email should be secure, and only that user can access it. Therefore, to reset the account with you, you confirm their access by sending a secure, one-time code to their email. The user proves they received that code, and therefore, they are who they say they are.

With that, let's run through an example using Next.js.

Example

This example was written with Next.js 13 using the app directory. It used Radix themes, Tailwind CSS, and Mailgun. You can find a link to the source at the bottom of the page.

Schema

When a user requests a password reset, save that token in your database. You can save it on the user record itself, but I suggest creating a new table instead. This will create an automatic audit trail of how many times a user has requested and reset their password.

model User {
  id                  Int                  @id @default(autoincrement())
  email               String               @unique
  password            String
  name                String?
  passwordResetTokens PasswordResetToken[]
}

model PasswordResetToken {
  id        Int       @id @default(autoincrement())
  token     String    @unique
  createdAt DateTime  @default(now())
  resetAt   DateTime?

  user   User @relation(fields: [userId], references: [id])
  userId Int
}

Request Reset Page

Create a page like /forgot-password in your app and have a form that asks the user to submit their email. This is the email you will send the password reset code to.

<Card className="gap-4 flex flex-col">
  <Flex gap="4" direction="column" asChild>
    <form action={submit}>
      <h1 className="text-2xl font-light">Reset password</h1>
      <p>
        Enter your email address to get instructions for resetting your
        password.
      </p>
      <TextField
        name="email"
        type="email"
        size="3"
        placeholder="Your email..."
      />
      <SubmitButton>Reset Password</SubmitButton>
      <Link href="/" className="text-sm text-neutral-700/80 flex items-center">
        <CaretLeftIcon />
        <span>Return to Login</span>
      </Link>
    </form>
  </Flex>
</Card>

When the user submits their request, you need to:

1. Find the user in your database
2. Create a record of the password reset in the database
3. Create and send an email to the user with the unique code.

export async function resetPassword(data: FormData) {
  const email = data.get('email')
  if (!email || typeof email !== 'string') {
    return {
      error: 'Invalid email',
    }
  }

  const user = await prisma.user.findUnique({
    where: { email },
  })

  if (!user) {
    return {
      error: 'This email is not registered',
    }
  }

  const token = await prisma.passwordResetToken.create({
    data: {
      userId: user.id,
      token: `${randomUUID()}${randomUUID()}`.replace(/-/g, ''),
    },
  })

  const mailgun = new Mailgun(formData)
  const client = mailgun.client({ username: 'api', key: API_KEY })

  const messageData = {
    from: `Password Reset <security@${MAILGUN_DOMAIN}>`,
    to: user.email,
    subject: 'Reset Password Request',
    text: `Hello ${user.name}, someone (hopefully you) requested a password reset for this account. If you did want to reset your password, please click here: ${PROTOCOL}://${DOMAIN}/password-reset/${token.token}

For security reasons, this link is only valid for four hours.
    
If you did not request this reset, please ignore this email.`,
  }

  await client.messages.create(MAILGUN_DOMAIN, messageData)
  redirect('/forgot-password/success')
}

This example uses Mailgun to send the email, but any transaction service will do.

Handle Reset Request

The above email sends the token to the user's email as a link. When the user clicks on it, you show them a page where they can enter a new password. When submitted, validate everything is correct, and only then reset the password.

This form was located at /password-reset.

<Card className="gap-4 flex flex-col">
  <Flex gap="4" direction="column" asChild>
    <form action={submit}>
      <h1 className="text-2xl font-light">Choose a new password</h1>
      <p>You can reset your password here.</p>
      <TextField
        name="password"
        type="password"
        size="3"
        placeholder="Password"
      />
      <TextField
        name="confirm"
        type="password"
        size="3"
        placeholder="Confirm password"
      />
      {error && <p className="text-red-500 text-sm">{error}</p>}
      <SubmitButton>Reset Password</SubmitButton>
      <Link href="/" className="text-sm text-neutral-700/80 flex items-center">
        <CaretLeftIcon />
        <span>Return to Login</span>
      </Link>
    </form>
  </Flex>
</Card>

On the server, the validation needs to look at the token and the new password and ensure the token is valid, unused, and timely. The passwords need to match as well.

export async function resetPassword(token: string, data: FormData) {
  const password = data.get('password')
  const confirmPassword = data.get('confirm')
  if (
    !password ||
    typeof password !== 'string' ||
    password !== confirmPassword
  ) {
    return {
      error:
        'The passwords did not match. Please try retyping them and submitting again.',
    }
  }

  const passwordResetToken = await prisma.passwordResetToken.findUnique({
    where: {
      token,
      createdAt: { gt: new Date(Date.now() - 1000 * 60 * 60 * 4) },
      resetAt: null,
    },
  })

  if (!passwordResetToken) {
    return {
      error:
        'Invalid token reset request. Please try resetting your password again.',
    }
  }

  const encrypted = await hash(password, 12)

  const updateUser = prisma.user.update({
    where: { id: passwordResetToken.userId },
    data: {
      password: encrypted,
    },
  })

  const updateToken = prisma.passwordResetToken.update({
    where: {
      id: passwordResetToken.id,
    },
    data: {
      resetAt: new Date(),
    },
  })

  try {
    await prisma.$transaction([updateUser, updateToken])
  } catch (err) {
    console.error(err)
    return {
      error: `An unexpected error occured. Please try again and if the problem persists, contact support.`,
    }
  }
  redirect('/')
}

And now you have successfully reset the user's password!

Source Code

examples/next/password-reset at main · a-bit-of-saas/examples

Example code for learning. Contribute to a-bit-of-saas/examples development by creating an account on GitHub.

GitHuba-bit-of-saas

This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.

The end of summer has come with a vicious heat wave in the northeast US. When it's this hot, all I can think of is how nice it would be to have some water to swim in! The best friends are the ones with pools.

The Best Bits

• Astro 3.0 was released.
• Making sense of React Server Components.
• Open-source visual editor for React.
• React component library to build analytics dashboard.
• An open-graph meta tag test and validate site.

Just launch it

Too many individuals grapple with the idea of launching a project that isn't polished to perfection. They ponder, second-guess, and tweak details endlessly in pursuit of a flawless product. However, you should launch as soon as you can, even with something imperfect.

Here are some clear wins when you launch as soon as you've solved the core problem.

Perfection is Illusive: First and foremost, perfection is a moving target. What appears perfect today might be outdated or irrelevant tomorrow. Instead of chasing an ever-evolving ideal, it's more pragmatic to start with a minimum viable product (MVP) and refine it as you learn more.

Rapid Feedback: By launching earlier, you allow yourself to collect invaluable feedback from real users or stakeholders. This real-world data is often more beneficial than any number of brainstorming sessions or theoretical models. You learn what genuinely works, what doesn’t, and what users truly want. If you launched too soon, you'll know immediately. Fix it with rapid improvement.

Efficiency: Perfecting a product or project often requires a considerable investment of time, money, and energy. If the 'perfected' version doesn’t resonate with the market, these resources are wasted. Starting with a simpler version allows for a more efficient allocation of resources based on actual needs and feedback. Your users will tell you what they want you to do next.

Avoiding Analysis Paralysis: Spending too much time in the planning phase can lead to indecision and stagnation. The fear of making mistakes or not achieving perfection can be paralyzing. By pushing to start and then iterate, you sidestep this potential pitfall and maintain forward momentum.

While the desire for perfection is natural, it’s essential to recognize that in many scenarios, launching and refining as you go is a more strategic approach. Embracing the cycle of learning, pivoting, and iterating can lead to better products, more satisfied users, and more innovation.

Tech Tip

It's not hard to pass a component as a property in React. This is a great tip from Matt.

const Row = (props: {
  icon: React.ComponentType<{
    className?: string;
  }>;
}) => {
  return (
    <div>
      <props.icon className="h-8 w-8" />
    </div>
  );
};
 
<Row icon={UserIcon} />;

In the above the icon proper is React.ComponentType. You can pass in the props that the component takes by passing { className?: string } to React.ComponentType, indicating that this is a component that can receive a className prop.

This basically says icon can be any component that can receive a className prop. This is a very flexible type, and it's easy to use.

Cloud Chronicles

• YouTube Subscribers: 3,472 (+173 in the last 7 days)
• Newsletter Members: 615 (+26 in the last 7 days)

I'm still working on updating my process to get content out the door. The most consistent thing I do is this newsletter, so I'm trying to expand what makes it successful to other parts of my content.

Last Byte

• The Worst Programmer I Know.
• A peer-to-peer file transfer web app.
• Another icon set.

This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.

It's Labor Day weekend in the United States, the unofficial end of summer. I hope you all had a fantastic summer and are looking forward to the end of the year. Let's get it!

The Best Bits

• Vercel's Platform Demo Kit for multi-tenant Next.js projects.
• Learn more about SEO's interaction with core web vitals.
• A fun tale on why I highly recommend SaaS development over mobile app development.
• Minimal snippets for modern CSS layouts and components.

Security vs. Usability

There was an article recently talking about how short session length does not increase security. There are a lot of good comments on the article, which are worth a look if you're interested.

This is, of course, one of those topics that is incredibly nuanced. And for almost any service, there will be tradeoffs that need to be thought through and the best path implemented. And once you've implemented it, measure the impact and adjust as needed.

There's often no shortcut.

Session length is just one of these debates. Banks tend to have very short sessions. GitHub has kept me logged in literally forever. Which one is more secure?

Personally, I lean toward convenience on this one (infinite sessions!) because the services I build myself don't have a lot of valuable information. Needing to log in frequently causes friction that doesn't help early-stage products that are still finding product market fit. For more enterprise customers, they'll often opt for shorter sessions.

Another good example of this debate is a password reset feature. When a user inputs their email, and that email does not exist, you can either:

1. Inform the user this email does not exist. This often means the user mistyped their email or they used a different email, and they are happy to understand why they are not getting a password reset email.
2. Informing the user if their email exists or not is leaking information about which emails are in your database, so you always return a success message no matter what. More secure but a worse experience.

This is one of those small things that I enjoy seeing how different services handle. I've generally seen most services do option 2, but lately, I've seen more services do it the first way. Other protections put in place, such as rate limiting, can decrease the attacker's ability to abuse the feature.

It's always a tradeoff, though.

What side do you fall on?

Tech Tip

I've been... hacking on a side project lately. It's an online multiplayer implementation of Dominion. Yes, yes, I know, you can already play online. The point isn't to play; the point is to learn how to create a game server implementation that handles asynchronous client input.

Anyways, the server is a Socket.io web socket server, and the frontend is pure React. This is one of those moments in life where Next.js is just really bad and would not be a good option.

Of course, now that I'm outside the Next.js world, I need to rely on... other tooling. So I have nodemon set it to hot restart the server and Vite for the frontend tooling. It's fine. The Nodemon setup was a little tricky since it has a different TypeScript configuration than the client. So when you're doing this, here's what you can do.

Create a nodemon.json file:

{
  "watch": ["src/"],
  "ext": ".ts,.js,.tsx",
  "ignore": ["src/**/*.spec.ts"],
  "exec": "ts-node --project tsconfig.server.json src/server/index.ts"
}

This is read by default, so your dev command can just be nodemon. And then, to configure a backend server with TypeScript, your tsconfig.server.json file should have the following:

{
  "compilerOptions": {
    "outDir": "dist",
    "sourceMap": true,
    "target": "esnext",
    "module": "commonjs",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "noImplicitAny": true,
    "strict": true,
    "skipLibCheck": true
  },
  "include": ["src/**/*.ts"]
}

That configuration is set up for a regular Node.js project! Now you can run your own server without interfering with Vite.

Cloud Chronicles

• YouTube Subscribers: 3,299 (+281 in the last 7 days)
• Newsletter Members: 589 (+31 in the last 7 days)

I need to figure out my YouTube schedule. Also, I should be starting a new freelance project soon (Hurray!) that will take up quite a bit of my time. Sooo, I really need to do some time management and ensure I have my priorities figured out.

That will probably mean less streaming, so I can break up the content process a little more. There are plenty of videos to be made, so no worries there. I just need to tighten up my process for making them.

Last Byte

• Of course, once I learned Terraform, there was a massive break in the community around Hashicorp's new license. Introducing: OpenTF.
• Tell your boss about ChatGPT Enterprise so you can automate yourself out of a job faster.
• An oldie but goodie - when your coworker does great work, tell their manager.

This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.

Friends don’t let friends pick us-east-1.

- AWS Proverbs

That is all. Continue along your US East 2 day.

The Best Bits

• Code Llama 2, an open-source LLM for coding.
• Add dir=auto to your inputs for automatic right-to-left orientation.
• useMemo overdose (You know who you are).
• Do short sessions help security?

The Price of Complexity

It's hard to keep things simple.

Complexity is the natural state of software, and without care and maintenance, the code will devolve.

The hard part is knowing what is complex vs. simple and fighting against that complexity before it rears its head.

The first part comes with experience. Certain solutions are simpler than others. For example, monolith software is simpler than microservices. A single process is simpler than multiple processes. One thread is simpler than concurrent threads.

Over time, you'll get better and better at knowing which solutions are complicated. Sometimes, that will just require building the solution to get a feel for it. And sometimes, that complexity is worth it!

For example, setting up a GraphQL endpoint is more complex than setting up individual (perhaps RESTful) APIs. You need a GraphQL Schema, resolvers, and a server, all on top of the API endpoint. However, in return, you get type safety and the ability to request more or less data on the fly from the client. That tradeoff is often worth it.

This article (which inspired this post) talks about a team debating how to resolve their database being put under too heavy load. The options presented would resolve it but would also increase complexity by a lot. The simple solution (but not easy) was simply to track down performance issues in the code, optimize queries, and rewrite code to avoid expensive tasks.

This is a great example of fighting back against complexity. While other solutions might sound fun and exciting, they offered an irrevocable increase in complexity. Avoid that for as long as you can.

For Recast, I'm already annoyed that my converter process is a different service. But building out a more robust pipeline will increase the complexity even more, so I'll push what I have until it can't take it anymore.

Learn to Build SaaS

Just a single stream this week as I refactored the converters for Recast, the ultimate file conversion service. I've been doing some research into some of the most challenging converters, and I think there are some good solutions. I'll be looking to implement them next week at the latest.

Besides making subpages for specific conversions, I think I'll branch out shortly and build some auxiliary projects that'll help Recast. Things like user reviews and contact forms are prime targets for their own SaaS, and I can open source a lot of that.

Tech Tip

I've started writing tests for the converters to isolate problems earlier in the dev cycle. This is tricky because the converters rely on local executables that are installed. In production, that will be Debian. Locally, it was macOS. However, some of these programs are... really challenging to install. I simply don't want them locally.

This is the perfect use case for Docker! I've created a Docker image that contains all the executables that the tests need:

FROM node:18 as builder

WORKDIR /usr/src/app

RUN apt update \
    && apt install -y build-essential libjpeg-dev libpng-dev libtiff-dev potrace imagemagick ffmpeg pandoc \
    && npm install -g pnpm
    
COPY pnpm-lock.yaml package.json ./
RUN pnpm install

After you build this, the trick is to run the tests in the container without needing to rebuild it all the time. This is easily achieved with a volume mount, but that'll also copy in the node_modules. This is a problem since the docker image and host are different OS's.

The fix is to add node modules to the .gitignore file:

node_modules/

So they aren't copied into the image at all.

Then you need to shadow mount a directory when using the container so the node_modules within the container is not overridden:

docker run --rm -v $(pwd):/usr/src/app -v /usr/src/app/node_modules -w /usr/src/app imagename:latest pnpm test

And now you can easily run tests in Docker without needing to rebuild the image all the time!

Cloud Chronicles

• YouTube Subscribers: 3,018 (+391 🎉🎉 in the last 7 days)
• Newsletter Members: 558 +41 in the last 7 days)

YouTube has been showing more people my "Buy and Sell SaaS" series, which accounted for a lot of new subscribers. Clearly, there is quite a bit of demand for really making money from building SaaS. The tricky thing is, of course, it's still not easy. Building a product that's worth money takes time, and it's impossible to do that in a single 4-hour video.

That being said, hopefully, there will be some more opportunities to intertwine building SaaS and cashing out.

Last Byte

• Ask vs Guess culture.
• Debugging hydration errors in Next.js.
• How a startup loses its spark.

This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.

A small note and a humble victory – today, I had to pay for the larger plan on Ghost because my newsletter has too many members. I totally forgot this was even a thing when I set it up originally, I never expected to have over 500 people subscribed.

Thank you, each and every one of you. It means the world to me.

The Best Bits

• Supabase had its launch week and released some goodies, including an updated integration with Vercel and database branching.
• Atlas Icons, another icon library. And you thought I was done.
• Backstage.io is a SaaS product that helps internal teams catalog and manage their services. There's literally a SaaS for everything.
• HTMX is a small library that lets you code interactivity right in your HTML. I wouldn't recommend it for serious projects yet, but it is cool.

Thoughts on Pricing Your Product

It came up on stream on how I was planning on charging for Recast, a flat subscription vs a usage-based system. This brought up a couple of good points that I thought were important.

The price you charge is related to the value you provide, not the cost.

Well, at least it should be. Usage-based systems can easily be turned into charging just enough money to cover how much the service costs to run. For example, charging per GB of storage or per conversion a user runs.

The problem with this is that with optimizations, you can get this cost pretty low, so you won't be charging a lot of money. AWS' S3 storage is incredibly cheap, allowing you to store vast amounts of data. But what you are storing might be incredibly valuable, such that if the service were to disappear, you would suffer greatly.

What you are paying for isn't the storage; it's the service. It's the value you provide.

So if you are going to consider usage-based pricing, ensure you are not just covering your costs. Price accordingly to the value your service is delivering.

Usage-based pricing is complicated.

Stay away from complexity as long as you can. And usage-based pricing is more complex than a simple subscription. There is more to keep track of to ensure the billing is accurate.

Not only is it complicated for the developer, but it's complicated for the user. They don't know how much they are going to pay month to month. And having a consistent number is very helpful for accounting and selling into the enterprise. Imagine this conversation both ways:

Them: How much does this cost?
Recast: It's $1,000/mo for the enterprise plan.

Or

Them: How much does this cost?
Recast: Well, it's a flat fee of $200 a month, and then depending on how many conversions you do it'll cost $0.05 per conversion, unless they are videos, then it's $0.1 per minute of footage, or if you use a "premium" API which costs $1 per usage...

You get the point. Wrap it all up, give them an upper limit, and call it a day. It's a win-win.

Learn to Build SaaS

This week I've run two live streams as I build out Recast. There are always a few people who show up, so it's a lot of fun!

Recast is a file conversion SaaS that lets you convert quickly and easily. As I've been working through the project, I've been talking and thinking about the bigger play. Instead of just converting files, the service will start letting you change and mutate the data within the files. Users will be able to build complex flows that can be shared that'll transform their data with no code.

I think there's something in there that could be worth something. It's worth exploring.

Tech Tip

I was playing around with gm, which is a Node.js library that uses Image Magick to manipulate images. It has an easy-to-use API which is nice. If you're looking to manipulate images from Node, this is a good way to do it. I didn't end up using the library in Recast, so here's what I did:

import GM from 'gm'

const gm = GM.subClass({ imageMagick: '7+' })

gm('example.png')
  .stroke('#171717')
  .fill('#171717')
  .font('inter.ttf', 100)
  .gravity('Center')
  .drawText(0, 0, 'magick!')
  .write('drawing.png', function (err) {
    console.log('DONE', err)
    if (!err) console.log('done')
  })

This snippet reads in an image and then writes "magick!" in the center of it in the Inter font.

Cloud Chronicles

• YouTube Subscribers: 2,627 (+488 🎉🎉🎉 in the last 7 days)
• Newsletter Members: 517 (+38 in the last 7 days)

Okay, this is getting ridiculous. I mean, great! I mean, what. In the last 7 days, I've almost gotten 500 new subscribers. YouTube appears to have rewarded my consistent live stream, even if my video posting is... less than consistent. A majority of my new subs came from the live streams rather than videos.

The algorithm is also showing my content to more people, almost twice as many. That's helping to bring in more people.

It's awesome! And fun. And wild. You all are great; thanks for sticking around.

Last Byte

• Firefox Finally Outperforming Google Chrome In SunSpider. I guess it's time to switch.
• A video game where you are the operating system.
• How to bypass YouTube video download throttling.

This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.

Good design isn’t just beautiful and incredible and boundary-pushing, it also remembers what it means to be human.

- Cabel Sasser

The Best Bits

• Shadcn/ui released themes!
• Radix UI released themes (I'm not even kidding).
• Create a Generative Landing Page (I did this for Recast)
• Water (go on, I'll wait).

Which UI Library are you using now?

It feels like in the past few weeks, we've had a bunch of fantastic releases of UI libraries, with more to come. In case you haven't been hacking on the frontend much, I've seen the following:

• React Aria Components
• Radix UI themes
• Shadcn/ui themes
• Tailwindcss Catalyst (coming soon)
• NextUI v2

These libraries are a new kind of UI library. At their core, they are powered by headless code; either components or hooks. These low-level primitives can be used to build a UI that looks like anything.

And then, on top of those primitives, the creators are now layering a full UI library that includes all the standard components you would want to use. Some of these libraries can be copied into your code; others are installed.

The benefit here, though, is because they are built on the primitives, if you want to make changes to the components, you have an easy way to "drop down" a level and get to a lower level API. This amounts to a lot of flexibility and power. You can get started quickly and then customize as you go.

The biggest question now is which one do you choose?

That's a personal choice. I like the Radix JSX component approach, but they don't have anything for handling some elements, such as buttons. So I often reach for React-Aria and then sprinkle in some Radix as I need to.

Probably not the best, but I do like the best of both worlds.

What are you using?

Learn to Build SaaS

This week I've run two live streams as I build out Recast. There are always a few people who show up, so it's a lot of fun!

Cloud Chronicles

• YouTube Subscribers: 2,099 (+226 🎉 in the last 7 days)
• Newsletter Members: 479 (+28 in the last 7 days)

Look at those YouTube subscribers! Holy cow! I'm not sure what exactly I did to make the algorithm like me, but I added over 200 subs in the past week. Looking at the analytics, I think posting the videos really helped – which means, of course, I should post more... but I need to jump on that and do them.

I'm going to try and make some more videos that are less tutorial focused and instead focused on other aspects of building out SaaS.

Last Byte

• Temptations of an open-source browser extension developer.
• Blocked by Cloudflare.
• Devtools for React Server Components.

The official AWS docs for installing the AWS CLI does not have instructions for Homebrew, which is mind-boggling.

So, instead, here are the steps you can take to install the latest version of AWS CLI on your Mac with Homebrew.

brew update
brew install awscli

Once it's installed, you can verify it works with:

aws --version

And the output should be something like the following:

aws-cli/2.11.2 Python/3.11.2 Darwin/22.6.0 source/arm64 prompt/off

This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.

Exploring some ideas this past week led me to Acquire.com, where I read over and over the phrase Pre-revenue MicroSaaS, which to me, translated to "I built this in a weekend and think I can sell it.

The Best Bits

• NextUI v2 is out, rewritten in Tailwind and React Aria!
• Learn more about React Server Components.
• Lucia 2, an authentication library.
• Run Llama 2 uncensored, locally.

Please Buy my Pre-revenue MicroSaaS

It's a dream of many people to build a product and sell it, reaping the rewards and fame of exiting a business. I've had those thoughts a lot too.

There's just a catch.

You need to sell a business, not a weekend hackathon project. And selling a business requires actually having a business, not just some code.

And that's hard.

A business needs users, usage, and a brand.

The first aspect that prospective buyers will look at is the user base and usage of your app. These metrics are often considered more important than the technology itself, as they provide a snapshot of the business's existing reach and the extent to which its software is utilized.

Even a pre-revenue MicroSaaS business with a burgeoning user base should show promise because a large number of users typically indicates a significant market need or interest. Moreover, high user engagement and usage statistics signal the utility and popularity of the software.

Of course, if the user base shows promise... why are you selling it?

Most of the time, these apps are not growing and do not show promise. They often were launched on Product Hunt or Hacker News and got some initial interest, only for that to fade quickly. In the graph below, these apps are in the trough of sorrow.

When you get into the promised land, you no longer have a hackathon project. You have a business. And a business requires a brand.

The brand of a SaaS business often plays a pivotal role in its potential success and saleability. A strong brand helps a business to stand out from the competition, promotes customer loyalty, and can serve as a significant draw for potential buyers.

Branding isn't just about having a catchy name or an attractive logo. It's about creating a unique identity that encompasses everything from the company's mission and values to its customer service. A strong brand story can influence how the market perceives the company and the value it provides.

These are things that will get someone to buy your business. But just having some code is the equivalent of having an idea. And ideas aren't worth anything.

So what business are you building?

Learn to Build SaaS

This doesn't let you upload files to Vercel btw, just how to get the data without a third-party library.

This one is either going to be lots of fun or the death of me. Take a look; the idea is to build a SaaS app with the idea of selling it. That means focusing a bit on the business side of things, not just the tech.

And lastly, no preview for this one because it's scheduled for Friday morning: https://youtu.be/5_JT9H8j1Us

I've been on a roll! I came back from vacation, itching to get some content done. I'm trying to do more content that is less perfect but still good. I've left some "ums" in and cut down a lot on the editing. Let me know what you think!

Tech Tip

Today during the live stream, I found out that Amazon has a V3 version of their JavaScript SDK: https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/

If you don't use it, it shows a big nasty warning in your project, so they clearly want people to upgrade.

Their docs, as usual, are awful, but to get started with a service, you now do:

npm install @aws-sdk/client-s3

Instead of installing aws-sdk.

Happy coding!

Cloud Chronicles

• YouTube Subscribers: 1,873 (+82 in the last 7 days)
• Newsletter Members: 451 (+25 in the last 7 days)

Estimated revenue from YouTube ads? $6.54. Niiiiicccee.

Still, it's a step in the right direction. At this rate, it'll take me 4 months to get my first check for $100 (the lower limit of what they pay out). I guess I'll keep my day job.

Last Byte

• Optimize your React code.
• How to get ChatGPT to stop apologizing?
• Make your mouse work better on Macs (some good suggestions in the comments too).