A Bit of SaaS Weekly: Incremental Deploys

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

If you find yourself in a rut, don't be afraid to shake things up in a dramatic way. Often it's easier to change when you deal a big blow to the system rather than try to tweak things bit by bit.

The Best Bits

• An open-source WYSIWYG Markdown editor. I've been using variations of these on and off over the years, so having another one to use is great. Here's the demo.
• An open-source all-in-browser background image remover. Not only is it open-source, but it's also one of the best online ones I've tested. I think Photoshop is better, though.
• Effect, a TypeScript library designed to help developers easily create complex, synchronous, and asynchronous programs. Not sure about this one; it reminds me a lot of Go.
• Advanced macOS command line tools.

Push Often; Push Small

One of the most powerful parts of building software is being able to push incrementally. Instead of making a single big change, you can make many small ones.

Either way, you end up in the same place. But one of those is faster and better.

Hint: It's not making a single big push.

I wrote about this in the context of pull requests, but it works in the same way when you're just making changes within a branch or on main itself.

Why?

Small changes force you to work in a smarter way.

You need to work in chunks that are functional.

When you make small changes, each one needs to compile, run, and work. You can't get yourself into a huge mess where you're 1300 lines of code deep, and nothing works.

You need to write the feature in the correct order.

When you ship code that always works, you need to write the code in the proper order. You can't build the API before the database layer has been written. And you can't write the UX before you can call into that API (okay, okay, you can, but you don't need to most of the time).

By breaking the work apart, you need to build out the database, and then build the API, and then make the UI work on top of that. Each one of these can be tested and validated. Each small chunk is less likely to be broken.

What happens if you realize you need to change your data model? Then finish the UI as best you can, and then run through the cycle all over.

As you iterate, this cycle becomes faster and faster. The commits become blurs, and you are always able to validate you have a working app. Each push runs the full CI and ensures the build is always correct.

When you do a big push, you inevitably spend lots more time debugging the code and understanding what went wrong. And cutting down on how long it takes to debug is one of the best ways to make you a better engineer.

Learn to Build SaaS

Build a full stack tracker SaaS app! In this series, I'm going to build a SaaS app that I will use for all my freelance work. We're starting totally from scratch and running through the entire thing!

Session two builds on the first session and adds more details to the track page as well as clients!

Tech Tip

name: Prisma
on:
  push:
    branches: [$default-branch]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - run: npm ci
      - run: npx prisma db push
        env:
          DATABASE_PRISMA_URL: ${{secrets.database_url}}

When shipping your web app, you want a good way to make database changes locally and then sync those to production. GitHub's CI can do this on pushes to the main branch. Use the following GitHub workflow to ensure your production database stays in sync.

Go forth and code!

Cloud Chronicles

• YouTube Subscribers: 1,515 (+75 in the last 7 days)
• Newsletter Members: 332 (+26 in the last 7 days)

Weekly Update: v2023.6.19

Last week I touched base with all my current clients (and several I’ve been chatting with about future projects) to understand if they will need my services for the second half of the year. Project management! To my delight, I heard back from all of them and locked down several

Build SaaS with EthanEthan Mick

I said I was going to be doing some live streaming last week and... I did it! I did two live streams, each about 4 hours. It was honestly a lot of fun. I'm super amazed that people showed up to watch, and extremely thankful. While I am prepared to do these and have no one watch... it's a lot of fun when people come and hang out in chat.

The live streams took the place of content this week. I will do a deeper look at the analytics in the coming weeks, but I don't want to change what I'm doing too soon. The live streams force me to sit down and code for a long period of time, which is great. And I enjoy it a lot! So instead of worrying if it's good for my watch hours, I'll do what I can to make it work, since it's good for me.

Last Byte

• The Password game.
• No vehicles in the park (game).
• Open-source resume builder.