4 min read

A Bit of SaaS Weekly: Find the Fit

A Bit of SaaS Weekly: Find the Fit

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}
Submit 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