A Bit of SaaS Weekly: Summer Hours

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

One thing I love about software is that it's often an intersection of passions from those who create it. That is, you don't make software for software. You make software to do something, and that something is often what you care about.

What are you passionate about?

The Best Bits

• Llama 2, the next generation LLM from Meta.
• A glitch in the SEO matrix.
• A great article on differentiating state in frontend frameworks.
• Full-text search with Postgres (I love Postgres!)

When do you stop?

As a solo engineer building a product it's very important to know where your time is best spent. Now, of course, if you have things you love doing, you should be doing those. But in every product there are places where you can best spend your time.

As you spend more time on a specific area, you're going to have diminishing returns. Going from nothing to something takes just small amount of time. Hours, or less. But refining it over and over yields diminishing returns. It looks something like this:

So what's the balance to strike? How do you know when to stop? For the questions, I try to borrow a number from the Pareto principal, that is:

Make the feature 80% perfect.

80% is a great stopping place. It's far enough along with development that you're probably going to hit all the major features. But you'll probably want to continue to refine the feature a little more.

The thing is, that last 20% is going to take as long as the first 80%. The refinement, tweaking, and perfection takes a long time to get right. And there's no end to it. You can continue tweaking it forever. It's hard to know exactly when it's done.

Because as you know – software is never done.

So here's the lesson. Just don't do it.

Not at first. You can come back to it when you know customers use it. You can see what works well and what doesn't. Then when you know it's worth the time investment, you can refine the feature and spend some more time on it.

But to start?

80%. Then ship it.

Learn to Build SaaS

This week I went through and implemented analytics and reporting for the time tracker SaaS app. We used the tremor.so library for the graphs, and it worked great. We also did some polishing on the team's page and allowed the user to update roles.

I've updated the app hostname to be: time-tracker.abitofsaas.app

I'm mostly done with the app at this point. There are things I want to polish up, and I might do a stream or videos on the marketing page... but for the most part, it works, and I can use it.

Tech Tip

When testing Stripe subscriptions, you will want to listen for events from Stripe for subscription lifecycle events. The most important is "inform me when a customer cancels or fails to pay for their subscription". When that happens, you will want to update your application to remove their paid plan features.

Testing webhooks is hard, but using Stripe's CLI, you can easily test locally.

stripe listen --forward-to localhost:3000/api/webhook

With that, I was testing and listening for incoming webhooks with no additional setup.

Go forth and code!

Cloud Chronicles

• YouTube Subscribers: 1,731 (+70 in the last 7 days)
• Newsletter Members: 401 (+19 in the last 7 days)

This July has been super busy but also not very stressful work-wise. I have lots of projects starting in the next few months, and it felt okay to coast a bit in July. I'll be up next week in Vermont, and when I come back, I'll do some reflecting on where I stand so far this year.

Last Byte

• TypeChat, types for LLM.
• Everytime you click this link, you'll go to a random Web 1.0 site.
• It takes six days to change 1 line of code.