## The Big Idea

Stable products still need maintenance. Defaults and shiny features quietly tax systems over time, and efficiency is a sign of craftsmanship, not penny-pinching.

## “Just Enough” Is an Ongoing Practice

At some point, my next.js website crossed a line I did not notice right away. It was stable, not changing much apart from new posts and newsletters. Traffic was healthy. And yet, I was steadily consuming more of the resources measured by **Vercel's free tier**. Nothing had broken. Nothing felt slow. But the line on the graph kept moving in the wrong direction.

That surprised me.

We often tend to think of stability as the end of something. Engineer ship something, it works, and we move on. Modern web frameworks ship with helpful defaults, and those defaults are optimized for convenience, not restraint. Prefetching everything on the page. Recomputing pages that could have been built once. Redirecting politely when a bot is clearly probing your pagination. Individually, each decision makes sense. Over time, they quietly add up.

Taking time to chase this down pulled me away from real work, the kind with deadlines and people waiting on me. I am not short on things that demand attention.

The results of a few hours of my time were exactly the doctor ordered:

<Image
 publicId="newsletters/just-enough-is-an-ongoing-practice/isr-reads"
 alt="A screenshot of the Vercel dashboard showing ISR reads before and after the changes"
 caption="ISR Reads before and after the changes"
/>

<Image
 publicId="newsletters/just-enough-is-an-ongoing-practice/fast-origin-transfer"
 alt="A screenshot of the Vercel dashboard showing Fast Origin Transfer before and after the changes"
 caption="Fast Origin Transfer before and after the changes"
/>

ISR Reads and Fast Origin Transfer both dropped dramatically, and flattened out. The site went back to living comfortably within a modest tier, even with steady traffic. What struck me was not how clever the fixes were, but how ordinary they felt in hindsight. These were not optimizations born from genius. They were the result of paying attention.

<Aside type="note">

 👉 Interested in the details of these changes? Check out my post on [reducing Next.js bandwidth with link prefetch](https://mikebifulco.com/posts/reduce-nextjs-bandwidth-with-link-prefetch).

</Aside>


## Keeping the lights on

The larger takeaway isn't at all about ISR or Fast Origin Transfer or prefetching. I think there's a lesson in what it means for a product to be "finished".

Launches of new products and features are exciting. It is _always_ a thrill to be working on the new hotness, drawing attention from your peers and customers.

But - there is a version of craftsmanship that only shows up after spotlight moves on. Funny enough, during my time at Google and Stripe, this was called KTLO: Keeping The Lights On.

## The unsung hero of the product lifecycle

This is the craft and attention to detail that shapes the integrity of the system. Efficiency, performance, and even environmental impact rarely make it into launch announcements. They still shape the integrity of the system. It's the work that is often thankless, and invisible to end users.

Growing the skill for this kind of work is not a one-time event. It is a skill that must be cultivated over time. It is a skill that must be practiced regularly. It is a skill that must be honed over time.

This is the same idea I wrote about before as **[just enough, nothing more](https://mikebifulco.com/newsletter/reflecting-on-one-year-as-startup-cto#just-enough-and-nothing-more)**. You don't cross the finish line once. You return to it. You notice drift. You develop a sense for new signals to listen to from the systems you've built and used. You remove things that no longer serve the system. You question defaults that once seemed harmless.

A stable product is not a finished product. It is simply a product that now requires a different kind of care.

“Just enough” is not a milestone. It is an ongoing practice.

Just Enough Is an Ongoing Practice

## A quiet problem I almost missed

I got one of those automated emails from Vercel that made me stop and read it twice.

My personal blog, a mostly static site with no video and lazy-loaded images, had already used more than **15 GB of outgoing bandwidth** for the month. That was roughly three quarters of Vercel's free tier, and the reset was still weeks away.

<Image
 publicId="posts/reduce-nextjs-bandwidth-with-link-prefetch/vercel-email"
 alt="A screenshot of the Vercel email showing a warning about hitting tier limits"
 caption="Wuh oh - work up to an email from Vercel warning about hitting tier limits"
/>

Traffic here is steady, but not especially high. Something didn't add up.

So I did what I probably should have done sooner and opened the analytics dashboard.


## It turned out nothing was wrong

The bandwidth wasn't coming from bots, scraping, or hotlinking. It was coming from **Fast Origin Transfer**, which in Vercel's world is largely driven by prefetching.

Specifically, Next.js `<Link>` prefetching.

By default, every `<Link>` on the page prefetches its destination as soon as it enters the viewport. That's a reasonable default for many apps. Navigation feels instant, and most of the time you never think about it.

On my homepage, though, there are a lot of links visible right away. Post summaries link to articles and tags. The footer includes a long list of tag pages. There are navigation links, social links, and related content.

Altogether, more than **sixty links** were prefetching their target pages the moment someone loaded the homepage. On every visit.

## How Next.js Link prefetching actually works

The short version is that the `<Link>` component in Next.js has a `prefetch` prop that defaults to `true`. In production, any link that enters the viewport automatically fetches the page it points to in the background.

This became more noticeable for me after upgrading to **Next.js 16**, which made prefetching behavior more aggressive by default. The framework is smarter about what it fetches now, but on pages with lots of links, the volume of background requests can still add up quickly. On Vercel, those requests are metered as **Fast Origin Transfer**.

The detail that made this fix viable for my site is that **hover prefetching still happens** even when viewport prefetching is disabled. When someone hovers a link, Next.js will still fetch what it needs before the click.

That means you can keep most of the perceived performance benefit without eagerly downloading dozens of pages that may never be visited.

One important caveat: this behavior depends on which router you're using. On the **Pages Router**, `prefetch={false}` disables viewport prefetching but still allows hover prefetching. On the **App Router**, `prefetch={false}` disables both. If you want hover-only behavior there, you'll need to call `router.prefetch()` yourself on mouse enter.

## The changes I made

Rather than touching every `<Link>` by hand, I added a small wrapper component that flips the default to no viewport prefetching.

```tsx
// src/components/Link/Link.tsx
import NextLink from 'next/link';
import type { ComponentProps } from 'react';

type LinkProps = ComponentProps<typeof NextLink>;

/**
 * Custom Link wrapper.
 * Defaults prefetch to false to reduce background bandwidth usage.
 */
const Link = ({ prefetch = false, ...props }: LinkProps) => {
 return <NextLink prefetch={prefetch} {...props} />;
};

export default Link;
```

Then I updated imports across the site to use this wrapper instead of next/link directly.

```diff
- import Link from 'next/link';
+ import Link from '@components/Link';
```
For the small set of links people are most likely to click, primarily the main navigation, I opted back into prefetching explicitly.

```tsx
<Link href="/newsletter" prefetch>
 Newsletter
</Link>
```

That keeps the interface feeling fast where it actually matters.

## The results

The number of background prefetch requests dropped immediately. Instead of sixty-plus fetches on every homepage visit, only a handful of intentional ones remained.

Based on early numbers and bundle sizes, I'm seeing something in the range of a 40 to 60 percent reduction in bandwidth usage. That's the difference between flirting with Vercel's free tier limits and staying comfortably under them.

| Metric | Before | After |
|--------|--------|-------|
| Viewport prefetch | All visible links | Primary navigation only |
| Hover prefetch | Yes | Yes |
| Background bandwidth | ~15 GB/mo | Estimated 6-9 GB/mo |

## When this is worth doing

This pattern makes sense if:

- You have pages with lots of visible links, like homepages or tag indexes
- Your pages prefetch non-trivial JavaScript bundles or data
- You're on Vercel's free or Pro tier and paying attention to bandwidth
- You've noticed Fast Origin Transfer climbing without an obvious cause
- You recently upgraded to Next.js 16 and saw a usage spike

It's probably not worth the effort if:

- Your pages have very few links
- Navigation speed matters more than bandwidth for your use case
- You're already prefetching intentionally and have bandwidth to spare

## Trade-offs, honestly

The main downside is that the first click to a non-prefetched page might be slightly slower.

In practice, I haven't noticed it. Most people hover before clicking, and hover-triggered prefetching still kicks in. The perceived speed is nearly identical.

The wrapper component adds a small abstraction, but it also gives me a single place to control this behavior site-wide. If Next.js changes their defaults again, and they will, I only have one file to update.


## Follow-up: another important change

After reviewing more of my analytics in PostHog, I realized I was getting _loads_ of traffic from crawlers and bots that were trying to visit arbitrary page numbers on my site by appending them to the URL:

```markdown
https://mikebifulco.com/page/117
https://mikebifulco.com/page/9
https://mikebifulco.com/page/28
```

In an attempt to make my site more friendly to people who somehow got a link to a page that didn't exist, I had set up a server-side redirect that would redirect to the first page -- this redirect was _also_ triggering ISR reads each time it ran.

The change I made here was obvious in retrospect: visit a page that doesn't exist? 404. No additional checks, just the basics. No more ISR reads.

## What I took away from this

- Sensible defaults aren't universal
- Prefetching is powerful, but it isn't free
- A small wrapper component can save real money
- It's worth occasionally checking what your framework is doing on your behalf

This is the kind of issue that only shows up when you've been running your own site for a while. Nothing was broken. It was just quietly inefficient.

## You're not the only one

Once I started digging into this, I realized how common the problem is. There are long-running threads full of developers hitting the same wall: unexpected bandwidth spikes, climbing Fast Origin Transfer costs, and confusion about what prefetch actually does.

If you're dealing with this too, these are worth reading:

- [Next.js prefetching and Vercel high Fast Data Transfer](https://community.vercel.com/t/nextjs-prefetching-and-vercel-high-fast-data-transfer/9154)
- [How to reduce fast origin transfer](https://community.vercel.com/t/how-to-reduce-fast-origin-transfer/23551)
- [Please allow to globally disable prefetching](https://github.com/vercel/next.js/discussions/24009)
- [`<Link>` prefetching behavior](https://github.com/vercel/next.js/discussions/60581)

If you've run into similar surprises, I'm always curious to hear about them. You can find me on [Bluesky](https://bsky.app/profile/mikebifulco.com) or [Threads](https://threads.net/@irreverentmike).

Optimizing Your Next.js Site's Fast Origin Transfer and ISR Reads

How Next.js Link prefetching actually works

## Introduction

Sometimes a third-party package breaks, and you can't wait for a PR to make its way into a release. Fortunately, `pnpm patch` makes it dead simple to hotfix packages locally while keeping your version control clean.

Recently, we needed to patch the [`@payloadcms/storage-uploadthing` package](https://www.npmjs.com/package/@payloadcms/storage-uploadthing) to fix a bug with image loading, so that we could continue to use it as our image hosting provider for [Craftwork](https://craftwork.com)'s implementation of [Payload CMS](https://payloadcms.com).

Here's how we handled it, using `pnpm patch`.


### What is pnpm patch?

[`pnpm patch`](https://pnpm.io/cli/patch) is a tool provided by the pnpm package manager that allows you to patch packages locally—and commit those changes cleanly. It works by creating a patch file that contains the changes you want to make to the package. You can then apply the patch file to the package using `pnpm install`.

## The process

Patching a package is a three-step process:
1. Track down the bug
2. Create a patch file
3. Apply the patch file to the package

Let's go through each step in detail.

### Step 1: Track down the bug

In our case, we tracked the bug down by making changes to the `handleUpload` function in `@payloadcms/storage-uploadthing`. You can do this in two ways:

1. Dig into `node_modules/@payloadcms/storage-uploadthing/src/...` directly
2. Or, clone the repo and search from there if you want to keep your project folder clean

We worked directly inside `node_modules` to validate the fix quickly. One thing to keep in mind here is that running `pnpm install` will overwrite your changes to the package -- which is eactly why we need to use `pnpm patch` to create a persistent patch!

### Step 2: Make a Local Fix

Once you've got a fix in mind, try it out directly in your project. You will do this by making temporary edits right inside the installed version of the package within your IDE.

<Aside type="note">
 In our case, the fix for `@payloadcms/storage-uploadthing` involved some minor changes:

 - the `handleUpload` function wasn't setting a `url` field based on the UploadThing API's response, so our Payload db didn't have any image URLs stored.
 - the `disablePayloadAccessControl` setting was commented out, which caused payload to store _local_ image URLs instead of UploadThing's public URLs.
</Aside>

Once we saw that this fix solved the issue in development, it was time to commit it to source control using `pnpm patch`.

### Step 3: Create a Persistent Patch with pnpm patch

<Image
 publicId="posts/patching-npm-dependencies-with-pnpm-patch/patch-process-1"
 alt="A screenshot of the terminal showing the output of the `pnpm patch` command"
 caption="The `pnpm patch` command opens the dependency's code in a temporary directory for you to edit."
/>

To preserve your fix and commit it to source control:

1. run: `pnpm patch <package-name>`. This opens the dependency's code in a temporary directory for you to edit.
2. Reapply the fix in the temporary folder.
3. Test it - do everything you would typically do to make sure the fix works: test functionality, run linters and test suites, etc.
4. To complete your patch and ready it for addition to source control on your project, run: `pnpm patch-commit <package-name>`

That saves the patch to your repo, and pnpm will re-apply it automatically every time you install dependencies. It also modifies your `package.json` to reference the patched version.

This will add a new entry to your `package.json` like this:
```json
"@payloadcms/storage-uploadthing": {
 "patches": {
 "@payloadcms/storage-uploadthing": "patch/@payloadcms/storage-uploadthing.patch"
 }
}
```

...as well as a file in your project's `patches` directory that represents the patch itself, in git diff format. This file type is a little difficult to read. You can re-open your patch file in your code editor to see the changes. Your changes will also be reflected in your `pnpm-lock.yaml` file.

This will cause pnpm to apply the patch every time you install dependencies.

### If you need to edit your patch

This is one part of the workflow that leaves a bit to be desired - if you need to edit your patch later, the best workflow I've found is to remove the patch from your project by running: `pnpm patch-remove <package-name>`, and then start a fresh patch by running: `pnpm patch <package-name>` (and going through these steps again).

You _can_ edit the `.patch` file directly, but it's finicky. In most cases, it's easier to remove and re-create the patch.


### Closing the loop with the package maintainer

Your dependency is now patched, and you can commit it to source control to use. This can help provide evidence to open source maintainers that the fix is needed, and that it works. It's good practice to [open a pull request](https://github.com/payloadcms/payload/pull/14250) to the package maintainer with your fix so that they can review it and merge it into the main branch.


### When it's time to remove the patch

Once there is an upstream fix in place, you can remove the patch from your project by running: `pnpm patch-remove <package-name>`.

This will remove the patch from your `package.json` and the `patches` directory, and you can then commit the changes to source control.

Remember that this doesn't automatically update the dependency in your project to the latest version - you'll still need to use `pnpm install` to do that.

---

## Why this process is useful

- You don't need to wait on library maintainers to merge PRs to get your fix into your project
- Your fix lives in version control, so teammates and CI builds stay in sync
- It's a fast, repeatable way to patch packages without publishing a fork


## Not using pnpm?
If your team is using a package manager other than pnpm, there are other options that are very similar:

- for `yarn` you can use [`yarn patch`](https://yarnpkg.com/cli/patch)
- for `bun` you can use [`bun patch`](https://bun.com/docs/pm/cli/patch)
- for `npm` you can use [`npx patch package`](https://www.npmjs.com/package/patch-package)
- if you're using ruby's `bundler`, you're in the wrong place, and you have my sympathies.

The specifics of each of these options are very similar, but vary slightly - refer to the docs linked above for a walkthrough of each.

Patching NPM Dependencies with pnpm patch

Step 3: Create a Persistent Patch with pnpm patch

Closing the loop with the package maintainer

## A Quick Win with text-wrap: balance

Here's a ludicrously simple tip to make your website more readable: use the `text-wrap: balance` CSS property. It's one line of CSS, but it makes a noticeable difference in how text appears, especially for headings.

### Why Use text-wrap: balance?

When text breaks across multiple lines, it often creates uneven line lengths, which can feel awkward to read. The `text-wrap: balance` property ensures that text lines are balanced, creating a more visually pleasing and readable layout.

Take a look at these two versions of a heading:

**Before:**

### What is text-wrap: balance?

`text-wrap: balance` is a CSS property designed to improve the visual balance of text that spans multiple lines. By default, when a block of text wraps onto a new line, the lengths of those lines can vary significantly, creating uneven and sometimes awkward breaks.

With `text-wrap: balance`, the browser automatically adjusts the wrapping of text so that the lines are as close to equal length as possible. This makes the text easier to read, and looks great - particularly for headings, short paragraphs, and blockquotes.

### Key Points:

- **Purpose**: Ensures evenly distributed line lengths in multi-line text.
- **Use Case**: Best suited for headings, short paragraphs, or any text that benefits from visual balance.
- **Compatibility**: Works on most modern browsers and gracefully falls back to default text wrapping behavior where unsupported.

By enhancing the balance of text, this property helps to create a polished and professional design with minimal effort.

## See text-wrap: balance in action

Here's a quick side by side example of a heading before and after using `text-wrap: balance`:

<heading className="text-3xl font-bold text-purple-700">
 This is a heading that doesn't have the rule applied; text will break onto a
 new line unevenly
</heading>

 

And by contrast -

 

<heading className="text-3xl font-bold text-balance text-purple-700">
 This is a heading that will feel nicely balanced if it spills onto a new line
</heading>

(Note: you may need to resize your browser window to see the difference)

## How to use it: CSS

One little line of CSS does the trick:

```css
h1,
h2,
h3,
h4,
h5,
h6 {
 text-wrap: balance;
}
```

## How to use it: Tailwind

Recent releases of Tailwind have built-in support for `text-wrap: balance`. You can start using it with the `text-wrap-balance` class.

```
<h1 class="text-wrap-balance">
 This is a heading taht will feel nicely balanced if it spills onto a new line
</h1>
```

### Browser Support

According to Can I Use, `text-wrap: balance` is supported by approximately 90% of browsers. While there are exceptions (e.g., IE11, Opera Mini, and some niche mobile browsers), the fallback is harmless: the text will wrap as it normally would without the property.

### Why It Matters

Legibility and readability are critical for user experience. There's even a psychological principle-the [Aesthetic Usability Effect](https://mikebifulco.com/newsletter/aesthetic-usability-effect) - that suggests people perceive more attractive designs as easier to use. Balancing your text lines is a subtle but effective way to make your site look polished and professional.

## Try It Today

Improving the look and feel of your site doesn't have to involve a complete overhaul. Small changes like text-wrap: balance can make a big difference. Add it to your site, and give your visitors a better reading experience-one balanced line at a time.

<details>
 <summary className="text-lg font-bold inline ml-4 cursor-pointer text-pink-600">
 Video Transcript
 </summary>

[00:00:00] **Mike Bifulco:** Hey, what's up friends. This is Mike from tiny improvements. I have a ludicrously simple tip for you.

[00:00:03] That's going to make your sites look better with one line of CSS. And I cannot believe how easy this is, which is why I'm making a video about it.

Side by side Demo: Single post

[00:00:10] **Mike Bifulco:** What we're looking at here is my website. I've made a change. That is exactly one line of CSS between this and the version you're about to see.

[00:00:16] And I think the change is tremendous. Take a look at this.

[00:00:21] Again, version one. Version two.

[00:00:23] Version one. Version two. Version one. How to set up self healing, URLs, and next JS for better. SEO. Version two, how to set up self healing, URLs, and next JS for better SEO. I think that's a little more readable. Don't you?

[00:00:38] Maybe he doesn't pronounce enough here. Let's look at a more detailed example.

Side by Side example: Lots of posts

[00:00:41] **Mike Bifulco:** this is my newsletter page, where I list off many newsletters that I've written in the past.

Subscribe to 💌 Tiny Improvements

[00:00:45] **Mike Bifulco:** If you're watching this and you don't subscribe already I would love it if you did. I write a weekly newsletter called tiny improvements with product tips for startup founders, product builders, and indie hackers, based on my experience, building startups in the past and currently building my startup Craftwork, which is a Y [00:01:00] Combinator backed startup.

Looking at the change

[00:01:00] **Mike Bifulco:** now let's take a look at this change here.

[00:01:02] It's much more pronounced when you see it multiple times.

[00:01:04] So, what we're looking at is CSS change that brings balance to text when it breaks across lines. And that is almost exactly what the change is. It is CSS, text balance.

[00:01:14] If I pull this up on the Chrome for developers site, you can see from my pal, Adam Argyle, a super straight forward tutorial on what this thing looks like.

[00:01:24] And the change is pretty easy to see when it's animated like this. Although it's a little hard to describe what's happening is the balanced version is trying to make the text break into lines that are roughly evenly sized.

[00:01:33] So it has a lot more visual balance. It's a little easier to parse because your eyes and jumping from one line to the next isn't quite as far of a distance on the balanced version versus the unbalanced version. It also works with Arabic text, right to left left to right. It doesn't matter.

[00:01:46] There are some limitations here.

[00:01:48] This balance rule works on up to six lines, which means that if you apply it to everything, it won't work for long paragraphs, for example. But the nature of this rule really applies to headings. This is more or less the way that this should be applied [00:02:00] and I'll show you how I did it on my site.

[00:02:01] Next.

Implementation details in Next.js with Tailwind

[00:02:01] **Mike Bifulco:** This is what you have to do to make this thing happen on your site, where you're implementing headings. You need to add a text balance rule to it. This has done with tailwind. So it's applying the text wrap, colon balance CSS property to my headings. And this component happens to apply to all the headings on my site. So it was super easy to do, but if you had to do it somewhere else, it would look something like this. Const balanced, heading. Equals. Return H one style equals there you go.

[00:02:31] Tax rate balance. This would do it. If you need to do it, one-off for some reason, but you could also apply this to block quotes. Like the Google article explained. So const balanced block quote equals tax wrap balance, or in tailwind land, you could do. Class name equals text balance, not work just as well.

[00:02:51] Matter of fact, let's go do this for the block quote on my site too.

[00:02:53] I have this. Lovely block quote, component that I use to render block quotes on my site. And I think it's a reasonable thing [00:03:00] to add text balance here as well. So we're going to do that and that will improve the aesthetics of my site. That's super nice. It's very subtle. People may never notice that this happens, but it should make it so that when your title's going to a second line, the look that much nicer, pretty cool, right? I thought so.

## Can I use it yet though?

[00:03:13] **Mike Bifulco:** Last thing I know what you're thinking. Is this something that I can actually use yet? Well, the good news is pretty much, yes. According to can I use this is used by almost 90% of browsers on the internet, which is fantastic. My apologies to people who use IE 11 opera mini UC browser for Android QQ, browser, Baidu browser, or Caio S browser.

[00:03:32] You're going to have to wait a little bit longer to see nice titles on my site, but in the meanwhile, the fallbacks. All back scenario for this is that your text will rep as it used to, if you're using this rule. So I consider this relatively safe to use.

[00:03:44] It's also already supported by tailwind, which is fantastic.

[00:03:47] I think you should go add this to your site and give it a shot. Legibility and readability are really important for user experience. And there's this thing called the aesthetic usability effect that the better looking your site is the better looking your product is.

[00:03:58] The more people will [00:04:00] inherently like it. It's a scientifically proven thing that, the better looking something is the more people put value in it.

[00:04:05] So why not? I don't want line change like this.

[00:04:07] That gets you some real wins for free.

[00:04:09] All right.

[00:04:09] That's a quick tip. I hope it's helpful for you until next time.

[00:04:12] My name is Mike Bifulco. This is a tiny improvements. Give them hell out there.

[00:04:15] ​

</details>

CSS Tips - text-wrap:balance will make your sites feel better

## My writing workflow

I have worked diligently to develop a writing workflow that keeps me productive and focused on writing, rather than getting hung up on the tools I use to write.

### A little about me

I'm Mike Bifulco, a software engineer and designer. I work as CTO and Cofounder of [Craftwork](https://craftwork.com) (Y Combinator S23), and I publish a weekly newsletter called Tiny Improvements to a focused audience of startup founders, product builders, and indiehackers.

I have worked in developer relations and content creation since about 2017, and have been publishing content on [mikebifulco.com](https://mikebifulco.com) since 2019.

Along the way, I've learned a lot about how to write and publish content, and I've developed a workflow that keeps me productive and focused on writing, rather than getting hung up on the tools I use to write.

My site is built with Next.js, and I use Markdown (and something called MDX) to write posts.

Sharing my work online has created endless connections and opportunities for me; if I had never hit the `publish` button on my work, I would not be where I am today.

### Why workflow matters

Time and time again, I've seen aspiring writers, devrel-ists, and content creators waste weeks, months, and sometimes years trying to get everything _just right_ before they share their work with the world. That is a waste of time, and it's a shame.

Regardless of who you are, the tools you use, and what you're writing about, landing on a workflow that works for you is the first step to getting started.

If the work you're creating is good, you've got a great foundation to stand on. Sharing your expertise and knowledge with your community starts there - the rest is just details.

## How I publish content on my Next.js site with Markdown and MDX

For all content on my site, my authoring workflow looks like this:

### Write in Markdown

<Image
 publicId="posts/content-creation-workflow-my-writing-process/writing-screenshot"
 alt="A screenshot of my IDE with a Markdown file open"
 caption={
 
 writing new posts looks a whole lot like{' '}
 <a href="https://mikebifulco.com/posts/self-healing-urls-nextjs-seo">
 this
 </a>
 .
 
 }
/>

1. I write in [Markdown](https://daringfireball.net/projects/markdown/). This makes it easy to write without distraction, and keeps my writing process focused on _what_ I should be saying, rather than how it looks.
1. I create a file for each new post in [the source code for my site](https://github.com/mikebifulco/blog) under the `src/data/newsletters` directory, as a single `.mdx` file with a small amount of frontmatter (title, desctiption, tags, slug, and a cover image).

### Every article needs a cover image

<Image
 publicId="posts/content-creation-workflow-my-writing-process/figma"
 alt="A screenshot of a Figma file with a cover image for an article"
 caption={
 
 <a href="https://mikebifulco.com/newsletter/open-sourcing-my-design-system">
 I use Figma
 </a>{' '}
 to create cover images for all of my articles.
 
 }
/>

1. For every article, I create a `1200 x 630px` cover image in [Figma](https://mikebifulco.com/newsletter/open-sourcing-my-design-system). This is the image you'll see on social media sites when a link to my articles is shared. Any other images included in the body of a post are created the same way, and are generally the same size.
1. I use [Squoosh](https://squoosh.app) to compress and optimize any included images, and then upload them to [Cloudinary](https://cloudinary.com) as `.webp` files.

### Commit, merge, and publish

<Image
 publicId="posts/content-creation-workflow-my-writing-process/pull-request"
 alt="A screenshot of a pull request for this very post in GitHub"
 caption="This is what a pull request looks like for this very post."
/>

1. When I'm done writing and ready for a newsletter to go live on my site, I commit the changes to a new branch, and open a pull request _to myself_ to merge the changes into the `main` branch. This generates a preview build of the new page on Vercel, where I can check out the changes and make sure everything looks good before merging.
1. After the PR is merged, Vercel automatically builds the site and deploys the changes, and the article is live in a few minutes.

## After I publish: sharing my work

**The most critical part of this process is sharing my work with the world.**

Once a post goes live, I run off to social media and start _sharing my work_ with the world - on Bluesky, on Threads, on LinkedIn, and on Reddit. The ins and outs of that process is a whole other article, but I'll say this: it's just as important as _actually publishing something_.

## Go hone your process

Here's the thing: this is _my_ workflow - it works great for me, because I built it around my own preferences and needs. As you're designing your workflow for publishing, take advantage of the things your brain likes.

Is it easier for you to write in Notion? Great! Start there. Is Markdown a pain in the butt? Skip it and use something that you like better. There's no right anwers here - the only thing that matters is that you actually get over the hump and _publish something_.

Once you've published something, you can iterate from there.

Good luck!

Content creation workflow: my writing process

How I publish content on my Next.js site with Markdown and MDX

## Transitioning from next-sitemap to Next.js's Built-in Sitemap.xml and Robots.txt APIs

In this post, I'll walk you through the process of migrating from the next-sitemap npm package to using Next.js's built-in API for generating sitemap.xml and robots.txt files. This transition not only simplifies our codebase but also leverages the capabilities of Next.js to enhance our SEO strategy.

### Why Migrate?

The [next-sitemap npm package](https://github.com/iamvishnusankar/next-sitemap) was a great tool for generating sitemaps, but as Next.js has evolved, it has introduced built-in support for sitemap and robots file generation. This change allows for a more streamlined approach, reducing dependencies and improving maintainability.

Admittedly, I have also been a bit of a laggard in updating my site to the new app directory - this is actually the _very first_ use of App Router on this site!

## What is a sitemap?

A sitemap is a file that lists all the URLs on your site, helping search engines discover and index your content. It provides a roadmap for search engine crawlers to navigate your site and understand its structure. They're also used by other services like Google Search Console to understand your site's structure. If you haven't used Google Search Console, it's an invaluable resource for measuring your site's search engine performance.

I've written at length about the value of SEO, including the [SEO tools I used to grow my sites to 20k+ visitors/month](https://mikebifulco.com/posts/seo-tools-for-new-projects).

## What is a robots.txt file?

The robots.txt file is a configuration file used to instruct web crawlers (like Googlebot) on how to crawl your site. It allows you to specify which pages should be indexed and which should be excluded, helping control the visibility of your content to search engines. In this case, we're using robots.txt to stop search engines from indexing URLs that we don't want to show up in search results, like Next.js API routes, and other pages that are generated dynamically.

## Removing the next-sitemap dependency

The first step is to remove the next-sitemap dependency from your project:

1. remove `next-sitemap` from your package.json file - make sure to check both `"scripts"` and `"devDependencies"`, and remove it from both places.
2. run `npm install` (or `yarn install` or `pnpm install`) to update your lockfile
3. delete your `next-sitemap.config.js` file if it exists
4. **Important:** If you have `sitemap.xml`, `sitemap-0.xml`, etc. files in the `/public` directory of your repo, delete any that exist. Next won't generate a sitemap file if these are already there - and it can be tricky to debug!

Side note: [`next-sitemap`](https://www.npmjs.com/package/next-sitemap) was a fantastic tool, and served me for quite a long time. I'm super thankful to the maintainers for their work on the package - it filled an important need for a _very_ long time!

## Generating a sitemap.xml file with Next.js

Next.js has a great built-in API for generating sitemaps and robots files. We'll use this API to generate our sitemap.xml and robots.txt files. The API is simple to use and allows for customization of the sitemap and robots file generation process.

There are a couple choices for [creating a sitemap with Next.js](https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap#generating-a-sitemap-using-code-js-ts):

1. **Write and maintain the XML for your sitemap yourself** - this may be okay for really small sites, but you will need to add an entry to this file for _every_ page you want search engines to know about. This quickly becomes cumbersome for sites with dynamic content, or even just a lot of pages.
2. **Use Next.js's built-in API to generate the sitemap.xml file** - I am going to opt for the built-in API because my site has hundreds of pages published, and I don't want to have to maintain a sitemap file with an entry for every single page.

### Configuring the sitemap.xml file

Create a new file in the App directory called `sitemap.ts`:

```tsx
import type { MetadataRoute } from 'next';

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
 return [
 // TODO: one entry for every page you want search engines to know about
 ];
}
```

This file is where you will add an entry for every page you want search engines to know about. The goal is to return an array of objects of the following type:

```tsx
type SitemapFile = Array<{
 url: string;
 lastModified?: string | Date;
 changeFrequency?:
 | 'always'
 | 'hourly'
 | 'daily'
 | 'weekly'
 | 'monthly'
 | 'yearly'
 | 'never';
 priority?: number;
 alternates?: {
 languages?: Languages<string>;
 };
}>;
```

A couple things to note here, from the [sitemap spec](https://www.sitemaps.org/protocol.html#xmlTagDefinitions):

1. The `url` property is required and should be the full URL to the page you want to include in the sitemap.
2. The `changeFrequency` property is optional and can be one of the following values: `always`, `hourly`, `daily`, `weekly`, `monthly`, `yearly`, or `never`. This is a _hint_ to search engines about how often the page is likely to change. Google and other search engines may choose to use different values than you specify if it becomes clear that your page changes at a different rate than you specify.
3. The `priority` property is "The priority of this URL relative to other URLs on your site." It is an optional property and can be any number between 0 and 1. If you don't include it, it will default to 0.5 for every page. I recommend setting this to 1 for your homepage, and cascading it down to 0.5 for other pages, depending on their relative importance to your site. It may not actually influence search engine behavior - and it's not a guarantee that a page will rank higher just because it has a higher priority - but it is a useful hint for search engines.
4. `alternates.languages` is a feature of Next.js that allows you to specify alternate versions of your page in different languages. This is useful if you have a blog post that is published in multiple languages, and you want to include all of the versions in your sitemap. I only publish in English (_en este momento!_), so I haven't tested this yet, and it isn't included in this tutorial.

### Populating your sitemap.ts file

#### Static pages

For static pages on my site, I opted for a semi-manual approach to adding them to the sitemap. I created an array of strings that represent the routes I want to include in the sitemap, and then mapped over that array to create the sitemap entries.

```tsx
// Define your static routes
const routes: string[] = [
 '', // home page
 '/about',
 '/integrity',
 '/newsletter',
 '/podcast',
 '/posts',
 '/tags',
 '/work',
 '/shop',
];

// Create sitemap entries for static routes
const staticRoutesSitemap = routes.map((route) => ({
 url: `${baseUrl}${route}`,
 lastModified: new Date(),
 changeFrequency: 'weekly' as const,
 priority: route === '' ? 1 : 0.8,
}));
```

When run, this will generate an array of sitemap entries for each of the routes in the `routes` array - note that the homepage has a priority of 1, and all other pages have a priority of 0.8.

#### Dynamic pages

For pages that are generated dynamically, or hosted by your CMS, the process isn't too different. You will need to fetch the URL of each page you want to include in the sitemap, and then create a sitemap entry for each one. In my case, I have 3 different sources of dynamic content:

1. Newsletters: these are dispatches of my newsletter [💌 Tiny Improvements](https://mikebifulco.com/newsletter), which I send out every week.
2. Blog posts: these are the blog posts I publish on this site (you're reading one right now!).
3. Tags: These are metadata tags I use to categorize my blog posts and newsletters issues. I generate a list of all tags on the site, and then map over that list to create a sitemap entry for each one.

I write all my site content in [`MDX`](https://mdxjs.com/docs/what-is-mdx/), and save them as files in my site's repo under the `src/data/` directory.

I used a utility function to grab all of the newsletter issues, blog posts, and tags from the `src/data/` directory, and then mapped over each one to create a sitemap entry. For newsletters, that looks like this:

```tsx
// this is a helper function used across my site.
// replace with whatever is needed to fetch from the CMS you use
const newsletters = await getAllNewsletters();

// create a sitemap entry for each newsletter
const newslettersSitemap = newsletters.map((newsletter) => ({
 url: `${baseUrl}/newsletter/${newsletter.slug}`,
 lastModified: new Date(newsletter.frontmatter.date),
 changeFrequency: 'weekly' as const,
 priority: 0.8,
}));
```

The same pattern is used for blog posts and tags.

## Sitemap.ts: The complete file

```tsx
import type { MetadataRoute } from 'next';

import { getAllPosts } from '@lib/blog';
import { getAllNewsletters } from '@lib/newsletters';
import { getAllTags } from '@lib/tags';
import { BASE_SITE_URL } from '@/config';

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
 const baseUrl = BASE_SITE_URL;

 const newsletters = await getAllNewsletters();
 const newslettersSitemap = newsletters.map((newsletter) => ({
 url: `${baseUrl}/newsletter/${newsletter.slug}`,
 lastModified: new Date(newsletter.frontmatter.date),
 changeFrequency: 'weekly' as const,
 priority: 0.8,
 }));

 const posts = await getAllPosts();
 const postsSitemap = posts.map((post) => ({
 url: `${baseUrl}/blog/${post.slug}`,
 lastModified: new Date(post.frontmatter.date),
 changeFrequency: 'weekly' as const,
 priority: 0.8,
 }));

 const allTags = await getAllTags();
 const tagsSitemap = allTags.map((tag) => ({
 url: `${baseUrl}/tags/${tag}`,
 lastModified: new Date(),
 changeFrequency: 'weekly' as const,
 priority: 0.5,
 }));

 // Define your static routes
 const routes: string[] = [
 '', // home page
 '/about',
 '/integrity',
 '/newsletter',
 '/podcast',
 '/posts',
 '/tags',
 '/work',
 '/shop',
 ];

 // Create sitemap entries for static routes
 const staticRoutesSitemap = routes.map((route) => ({
 url: `${baseUrl}${route}`,
 lastModified: new Date(),
 changeFrequency: 'weekly' as const,
 priority: route === '' ? 1 : 0.8,
 }));

 // combine all the sitemap entries into a single array
 return [
 ...staticRoutesSitemap,
 ...newslettersSitemap,
 ...postsSitemap,
 ...tagsSitemap,
 ];
}
```

### Testing your sitemap

Fire up `next dev` and navigate to `/sitemap.xml` - you should see your sitemap! Make double and triple sure that your sitemap has an entry for every single page you want search engines to know about. You may also want to check that it _updates_ correctly by adding a new page and checking that it appears in the sitemap.

<Aside type="warning">

If it doesn't seem like your sitemap is updating correctly, **remember to check your `/public` directory for sitemap.xml files** that may have been generated by `next-sitemap`, and delete them!

</Aside>

## Creating a robots.txt file

Next up, robots.txt. This is a _very_ similar process - we will follow the [docs for robots.txt](https://nextjs.org/docs/app/api-reference/file-conventions/metadata/robots) from Next.js.

This is a deceptively important file for your website's SEO. It is a really good idea to familiarize yourself with the [robots.txt file format](https://www.robotstxt.org/robotstxt.html), and to understand the meaning of each rule you set.

### Disallow everything for non-production environments

**🚨 Important: ** If you are running a non-production environment, you will need to add a check to your robots.ts file to disallow all requests. This is because non-production environments often have URLs that you don't want search engines to index - it would be bad news if Google decided that a deploy preview of your site should rank higher than your production site!

### Robots.ts: The complete file

Much like static pages for the sitemap, you will need to add an entry for every path you don't want search engines to index.
In my case, I have a reverse proxy in front of my site that handles analytics and logging with PostHog, and I don't want search engines to index those URLs.
You'll see that handled below with `noIndexPaths`.

```tsx
import type { MetadataRoute } from 'next';

import { BASE_SITE_URL } from '@/config';

const noIndexPaths = [
 '/ingest', // posthog's reverse proxy
 '/ingest/*', // posthog's reverse proxy
];

export default function robots(): MetadataRoute.Robots {
 // 🚨 IMPORTANT: if this is not a production environment, disallow all requests
 if (
 // Vercel-specific environment variable. Please check the docs for your hosting provider!
 env.VERCEL_ENV !== 'production' ||
 // for a generic node environment
 process.env.NODE_ENV !== 'production'
 ) {
 return {
 rules: [
 {
 userAgent: '*',
 disallow: '*',
 },
 ],
 };
 }

 return {
 rules: [
 {
 userAgent: '*',
 disallow: '/api/', // Next.js API routes
 },
 {
 userAgent: '*',
 disallow: '/_next/', // Next.js build output
 },
 {
 userAgent: '*',
 disallow: '/public/', // static files like css, images, fonts. This one's up to you!
 },
 ...noIndexPaths.map((path) => ({
 userAgent: '*',
 disallow: path,
 })),
 ],
 sitemap: `${BASE_SITE_URL}/sitemap.xml`,
 };
}
```

A few important callouts here: `BASE_SITE_URL` is a variable I set in my site's config, and it is the full URL to the root of my site (`https://mikebifulco.com`). You will need to replace it with the actual URL of your site.

## Deployment checklist

Now that everything's done, make absolutely sure you've got everything configured correctly. Here's a quick checklist I used to verify that my new sitemap and robots.txt were set up correctly:

```md
**Before going live**, verify that:

- robots.txt
 - [ ] visit `/robots.txt` and verify that it exists
 - [ ] check that there is an entry for your sitemap that contains a full URL, including the protocol (`https://`)
 - [ ] read through the disallow rules to make sure they make sense for your site. If you're using next.js, this will include `/_next/` at a minimum, and possibly `api/` and `public/` if don't want those directories indexed.
- sitemap.xml
 - [ ] visit `/sitemap.xml` and verify that it exists
 - check that it contains the correct entries for all:
 - [ ] static pages
 - [ ] dynamic pages (newsletters, blog posts, tags)

**While testing deploy previews of your site**, verify that:

- [ ] your sitemap is being generated correctly
- [ ] your robots.txt is being generated so that it **disallows all requests** in deploy previews

**After going live**, check that:

- [ ] your sitemap is being picked up and read by [Google Search Console](https://search.google.com/search-console)
- [ ] use something like the [Ahrefs Webmaster Tools Site Audit](https://ahrefs.com/signup?plan=awt&return=website-checker) to scan your site and verify that it is indexed correctly and that there aren't any issues.
```

And that's it! You've successfully migrated from the next-sitemap library to Next.js's built-in sitemap and robots.txt APIs.

## See the code changes I made to my site

If you're curious to see the code changes I made to my site to implement this, you can [view the diff on GitHub](https://github.com/mbifulco/blog/pull/894/files).

Migrate from next-sitemap to the Next.js App Directory's sitemap

Transitioning from next-sitemap to Next.js's Built-in Sitemap.xml and Robots.txt APIs

Generating a sitemap.xml file with Next.js

Disallow everything for non-production environments


In this video from my Tiny Improvements series, I'm diving into product analytics to improve newsletter signups on my personal site. Join me as I share my engineering process, from discovering a bug with my old provider to setting up an A/B test with PostHog to find the best-performing newsletter signup form. Despite fewer-than-hoped signups, I've gathered key insights to refine my strategy. Plus, a sneak peek into my next steps, like redesigning the signup popup and enhancing site SEO. If you're a startup founder or indie hacker, you’ll find plenty of actionable tips here!

## See the code changes I made in this video

Code changes for this video are available in this pull request are available at [mbifulco/blog#856](https://github.com/mbifulco/blog/pull/856)

## Timestamps for this video

00:00 Product Analytics for Engineers
01:18 The Results are in!
04:09 Code review in Next.js
04:49 I switched from VS Code to Cursor
05:50 Looking at the variant that won
06:31 Ship a variant directly from PostHog
07:30 A surprise I didn't see coming
08:05 What we did and what's next


The results of my PostHog AB Test are in!

See the code changes I made in this video


In this video, I discuss my recent efforts to improve the product analytics experience on my website. Over the past two weeks, I addressed a sign-up issue by switching to a new email service and implementing AB testing on my newsletter forms. I analyzed the results, but discovered a bug that prevented complete data collection. I walk through identifying the problem, show the fixes I made, and reset the experiment to gather accurate data. I also encourage viewers to check out the open-source code for my site and invite feedback and questions.

## See the code changes I made in this video

Code changes for this video are available in this pull request are available at [mbifulco/blog#840](https://github.com/mbifulco/blog/pull/840)

## Video Timestamps

00:00 Introduction and Recap
00:44 Analyzing AB Testing Results
02:32 Sponsorship Shoutout
03:01 Deep Dive into Data Analytics
05:41 Fixing Implementation Bugs
08:33 Resetting and Restarting the Experiment
10:28 Conclusion and Next Steps


How I found a missing change on my next.js site with PostHog

## Test, trust the data, and optimize your site for better results

In this video, I dive into A/B testing with PostHog to boost newsletter signups on my site. I walk you through my process-from identifying issues with signups, switching email platforms, to experimenting with different UX elements. I'll show you how to set up and run A/B tests, and explain why trusting the data is crucial for making smart, data-driven decisions. If you're a developer or UX enthusiast, this video will help you refine your own website's user experience.

The code for my site is available on github - you can see the Pull Request for the changes associated with this video here: https://github.com/mbifulco/blog/pull/832

## Watch the first two episodes in this series:

1. [Product Analytics for engineers: Debugging a conversion problem on my next.js site](https://mikebifulco.com/posts/debugging-a-conversion-problem-on-my-nextjs-site)
2. [Fixing the bug behind my Conversion Problem](https://mikebifulco.com/posts/fixing-my-conversion-problem)

## Video Timestamps

- 00:00 Introduction and Series Overview
- 00:35 Identifying the Signup Problem
- 00:59 Switching to Resend
- 01:11 Exploring AB Testing
- 01:19 Sponsorship by PostHog
- 02:11 Website Elements and Hypotheses
- 04:07 Implementing AB Tests
- 05:03 Setting Up PostHog Experiments
- 07:20 PostHog Implementation Details
- 08:31 Testing and Analyzing Results
- 10:52 Tell me what you think!

<details>

 <summary>

 Transcript

 </summary>

[00:00:00] **Mike Bifulco:** Hello, and welcome back to tiny improvements. My name is Mike And since we last talked, I've been working on a problem on my website. This is the third video in a series that I'm doing on trying to get people, to sign up for my newsletter.

[00:00:11] If you're new here, I read a weekly newsletter called tiny improvements.

[00:00:13] That is meant for product developers, startup founders, indie hackers, people who are interested in building products. Where I share the things that I've learned, building products that companies like Google and Stripe and Microsoft, and more recently building a venture capital backed startup I'm co-founder of a company called Craftwork. We went through Y Combinator last summer. And so this is my way of giving back. I'm trying to give away the things that I know for free, because I've been really lucky in my career.

[00:00:34] And I want you to be as lucky as I have been. So since you're here, let's talk about where we've been in the first video. I discovered that I had a problem with signups and people weren't subscribing. I was using convert kit for my newsletter at the time and was having some sort of mystery problem with signups.

[00:00:47] So I added a bunch of telemetry to show me when signups were happening and to try and detect failures from that experience, I found that. I was getting some mystery failures with convert kit in my implementation of my newsletter signup form. And that's [00:01:00] what led me to what I did in the second video, which is where I replaced convert kit with Resend.

[00:01:03] So now I use Resend email platform for both sending my newsletters and getting people to sign up for my mailing list. That's been really nice so far. In this video I'm exploring the next thing I wanted to get into, which is AB testing stuff on my site.

[00:01:16] So let's take a look at that and see what that actually means in practice.

## Sponsored by Posthog

[00:01:19] **Mike Bifulco:** Hey, all this video series is sponsored by PostHog. After seeing my first video, they reached out about a sponsorship, which is really cool.

[00:01:25] And frankly, I'm flattered to see it. I was planning on making these videos either way and that's because I really enjoy PostHog. I also really enjoy building products and seeing things improve over time. . I wouldn't take a sponsorship from something that I don't believe in and don't use, I hope you're enjoying this series and I hope you're learning something.

[00:01:39] If you're really into it, it might also be worth giving. PostHog a shot. One of my favorite things about the platform is that they're free tiers, unbelievably generous. You can get a whole lot out of PostHog for free before paying anything to decide if it's worth it for you.

[00:01:50] There's also a self host option. If you want to go that route and PostHog also has a ton of open source software, which means you can have influence over the product itself.

[00:01:58] I think that's really amazing. And the team has been [00:02:00] super responsive so far. So if you want to check it out, go to PostHog dot com slash Mike Bifulco. There'll be a link in the description. It will let them know I sent you and it means a lot to me.

[00:02:09] Thanks so much. I hope you enjoy the rest of the video.

[00:02:11] Okay, this is my site and this is one of the things that I'm interested in testing to see if I can make a difference in the amount of people signing up.

[00:02:17] When you visit my site, read one of my newsletters or any of the articles on my site. There's a bunch of things that are made available at the top of the pages, a cover image and a title things you're probably used to seeing, I have this nice dynamic. Table of contents, which is really helpful I also record audio versions of some posts, which is why we see this podcast embedded here. if we scroll through the post, when you get towards the end of it, a couple of things happen.

[00:02:36] This pop-up, that just flew in from the left is a thing called polite pop. This is where the first call to action typically comes for someone to subscribe to my newsletter. I've got a couple of hypotheses on how we can do better here. What I want to do is test the copy.

[00:02:48] That's rendered here to see if there's maybe a different treatment, that we can show. To people to get them more compelled to sign up. I might also choose to remove this. It kind of is just an ag and I think people are really well-trained to just dismiss pop-ups and [00:03:00] try and get them out of their face.

[00:03:01] And it's a little bit of a rude experience while you're on a site. I see loads of people coming to my site and clicking this. No thanks button. I've got tons of telemetry on that. That may not be long for this world.

[00:03:09] The other thing that I see, and I think this is worth testing straight away is at the bottom of each post.

[00:03:14] I have this giant banner, which is this big striking thing that says ship products that matter. And I really like this. This is something I workshopped for awhile, trying to come up with a slogan or phrase, something that was sort of attention grabbing. That's supposed to give people a reason to sign up.

[00:03:28] However, I think what I've done here is I built something that is so different from everything else. That's that seen on my site that. By the time you get down here, as you scroll down and you get this great big dark banner that appears, it's pretty obvious that the article is over and then I'm not giving you any more value here. And so what I want to test is if I can replace this with something that's a little more subtle.

[00:03:47] So maybe not a giant banner like this, but something that says, Hey, I write this cool newsletter. I think you might like it. Please subscribe. And maybe Tiki into people's psychology a little bit to keep them reading on the page. watching back some replays of people visiting the site. [00:04:00] It's pretty common to see someone get to about here and go away.

[00:04:02] And if they leave before they get down here, I've lost. So. we're going to try a couple of things here and that's. Where AB testing comes in.

## A-B Testing in PostHog

[00:04:08] an AB test is exactly what it sounds like. I have version a version B and sometimes C D E F a number of different versions of one bit of user experience that I want to test against each other to see how they perform. The idea here is to see that if I do this versus that is one going to get me more people signing up for my newsletter or not.

[00:04:24] **Mike Bifulco:** And we can kind of test some hypothesis from there. Now there's some really important statistics involved in how this works. What I really like is that when you collect data, the math will tell a story. And if you're willing to trust the math and listen to what the statistics say, you can probably make a good data driven decision to move yourself from doing well, to doing better and incremental change over time will do really well.

[00:04:46] But you have to be comfortable with trusting what the statistics say. And let me be the first to tell you that there's a lot to learn about that, and it can be really counter-intuitive. I am far from a statistics expert. I have learned a lot of mathematics in my life.

[00:04:57] You have to learn to trust the statistics. [00:05:00] And so that's what we're going to try to do here. Let me get off my high horse. Let's talk about this. So this is my first experiment is called newsletter banner treatments. So you give it a name, which is a human readable thing, and then our feature flag key.

[00:05:10] So this is the key that we'll use programmatically to make decisions based on this experiment. So I gave it newsletter banner treatments as the key. The description here again is a human readable thing. It's meant for me when I go review these later on to see what this experiment was all about.

[00:05:23] So I may fill this in with more detail, but the idea is I want to test different UX presentations of the newsletter banner that appears at the bottom of articles. To see which one performs best.

[00:05:32] By default PostHog will give you a control, which is the fallback value. So the control is meant to be in scientific method speak.

[00:05:39] That means the thing that we know how it performs and the baseline for the experience right now, that's that big dark banner that I show on my site that I was just showing you that people sort of. Seem to scatter away from. I'm running two tests against that in this case. So I'm going to test a simple implementation and a hero implementation. Those are bits of UI that I've built alternatives for.

[00:05:58] And I'll show you what they look like. [00:06:00] So if I come through and I hit, continue on this experiment, we'll see that PostHog does a little bit of thinking. And it goes to do some give me some numbers on roughly what this would look like. And what I want to check is my newsletter subscribed event.

[00:06:11] So I'm hoping to see more of these newsletter subscribed things happening. With one variant of this versus the other, they'll probably all perform slightly differently. We're going to pick the one that wins out of the three. So. I've picked the event that I want to use. If I go to the next page here, what I get is the goal for the experiment.

[00:06:28] So this now shows me everything in one view. What it's saying at the very top is this is a draft. I haven't actually started it yet. By results are not significant, meaning I haven't collected enough data to make a decision. And the feature flags name is here.

[00:06:39] Down here, we get implementation details from PostHog, which is literally code snippets that you can use in your application. So you can switch through these and see what they look like.

[00:06:47] There's react native there's no, there's Ruby, all kinds of stuff in here. What's really cool is they show you exactly how to do this. So you load the feature flag using the feature flags name. If you have a user ID, like an email address, if someone's logged in, you can pass that [00:07:00] into, they always get a consistent experience per user. And then you make a decision based on what comes back. So the feature flag will say for this person render a simple one. It might come back and say for this person render a hero one and you do different things based on that. So what I'll do is I'll hit launch on this thing, It'll sort of thing for a second and go live and I'll, show you what the implementation looks like, next.

[00:07:20] Okay, implementation time. So I'm using post hogs library called PostHog JS.

[00:07:26] Thanks sports, some really nice react components, which I'm using in this implementation here. So this experiment name, newsletter, banner treatments is what we just saw on the site. These are the three different experiment variants.

[00:07:35] So these are the things that the experiment will tell me to render for different users. And we'll collect data on that. And I'm using a thing called PostHog feature, which is a react component exported by post hog, which takes in the name of the flag. As well as the part of the experiment to match.

[00:07:50] So what this is saying is we're going to do this with the newsletter experiment. So if it comes back and says control, we're going to render this thing, the fancy component, which is the newsletter banner that's currently shown on [00:08:00] the site with the dark background.

[00:08:01] I've created two other variants. The simple one here is based on a fairly standard tailwind component library. And this one called hero is one that I was using on other pages on my site, but wasn't consistently showing on the bottom of articles.

[00:08:13] now I'm taking all three of these things. And for about a third of users, I'll show each one of these and we'll track. How many of them convert to newsletter subscriptions over the next. Week or so, and we'll see what comes back.

[00:08:23] Next thing to see is what this looks like in the browser, because PostHog also provides some tools for you to be able to poke around with these and make sure it works well before you roll it out to your users.

## PostHog's A-B Testing tools in the browser

[00:08:31] **Mike Bifulco:** All right back here on post-talk and here's what I want to show you.

[00:08:35] from any page on PostHog, you can get to this handy thing called toolbar. If I click into this, this gives me the ability to launch a PostHog specific toolbar within the context of my site. So it doesn't really fancy injection of content. And it renders PostHog using what I believe is a Chrome extension.

[00:08:50] And so if I click on this, it's going to load my local host, which I've told is where I'm running my site. This is what the tool bar looks like.

[00:08:55] Typically you'll see it. Like this, when it first comes up and we're really interested in this [00:09:00] feature flags. Functionality here. So there's a bunch of things here. You can do actions and heat maps and all kinds of stuff like that. But let's take a look at feature flags first. I'm going to navigate to one of my newsletters, the most recent one, we were just checking this out and I'm going to scroll to the bottom and I'm going to go to this feature flags thing here and already something looks different, This is not the banner that was showing before. And this is a sign that my experiment is working. you can see here, I can manually override the experiments that I'm seeing personally in development.

[00:09:25] And as I toggle through these, I get three different presentations. this one might look familiar. This is the hero one I had before. This is the simple implementation that I wanted to take a look at. And then here's the control implementation. the important thing to test here is we're trying to test things that could produce the same output against each other. When users come to this page, I want to make sure they can submit this form and get the output that I want from each of them, which is that newsletter subscribed event.

[00:09:46] So from this control one, This is a newsletter subscription form. First name and email address is exactly what we want to see the simple form, same thing. First name, email address, and then the hero form. Once again, first name and email address. So. [00:10:00] All the primitives are here. I have three different variants of this thing.

[00:10:03] The next thing to do is to set this live and just record some traffic for awhile. there are some statistical minimums. We have to get a certain amount of users interacting with each one of these, to be able to say whether it worked or not. And the next part is just waiting. So we're going to spin this up on PostHog.

[00:10:17] We're going to collect some data over the next week or two, however long it takes, and then we'll start to make some decisions based on that and go into the next step from there.

[00:10:23] So that's all there is to it. It's a little bit of implementation. It's a little bit of work to set up the three different variants, but now I need to trust the statistics. I need to listen to what comes back from post-hoc as the experiment runs. And tweak my site design based on the data that comes back. My guess is it'll probably take about two weeks for this to come back with meaningful results. But lucky for me, I can run a couple of experiments in parallel, as long as the two different experiments don't interfere with each other. I can probably still draw a valid conclusion from it. So over the next week or so I'll watch this and I'll see what happens.

## What do you think?

[00:10:52] **Mike Bifulco:** If you've been hanging on for the whole series so far, I'm really curious what you think of this.

[00:10:55] Is this something you would find useful for your site? Do you have an idea of experiments you'd like to run? Do you have [00:11:00] questions about this stuff?

[00:11:01] I spent a bunch of my career working in design and user experience. So this sort of thing is a process that I really enjoy, but I can understand that it might be frustrating too, especially if you just want to get to results.

[00:11:10] If you have questions for me, feel free to drop them in the comments. . Your ideas are always welcome here. There's no criticism too big or too small. I'd love to hear what you're thinking. Thanks so much. My name is Mike bi-fold co this is tiny improvements and we'll catch up for the next one.

</details>

Unlocking A/B Testing with PostHog: Improving Newsletter Signups

Test, trust the data, and optimize your site for better results

Watch the first two episodes in this series:

PostHog's A-B Testing tools in the browser


Watch [Product Analytics for engineers: Debugging a conversion problem on my next.js site using @PostHog](https://youtu.be/4nWcB1a8M1s) on YouTube

Thanks so much to PostHog for sponsoring this video and supporting my work! Give it a whirl over at https://posthog.com/mikebifulco and tell 'em I sent you!

## Summary

In part two of my adventure with product analytics, I tackle a significant drop in my newsletter subscribers. Join me as I dive into the data using PostHog, identify and fix critical errors, and ultimately switch from ConvertKit to Resend – a more developer-friendly email platform.

Along the way, I'll show you how I integrated tRPC into my Next.js site for a type-safe API, created hooks for better data management, and set use posthog to chase down the root of the bug.

Whether you're a startup founder or an indie hacker, you'll find valuable insights to improve your product. Plus, transparency is key – this video is sponsored by PostHog, but all opinions are genuinely mine. Let's build something great together!

## Video Timestamps

00:42 ConvertKit Stats

01:06 Subscription Form

02:45 Sponsored by Posthog

03:16 Resend broadcasts

03:36 tRPC

03:54 tRPC Demo

04:43 Subscription form code walkthrough

06:27 useNewsletterStats

07:33 What I'm seeing in posthog

08:37 What's next

09:45 Next PostHog tests

10:11 What do you think I should do next?

10:31 Wrap up

## Links

- Watch part 1 of this series: [Product Analytics for engineers: Debugging a conversion problem on my next.js site using @PostHog](/posts/debugging-a-conversion-problem-on-my-nextjs-site)


Fixing the sign-up problem on my site using PostHog Product analytics


Watch [Product Analytics for engineers: Debugging a conversion problem on my next.js site using @PostHog](https://youtu.be/4nWcB1a8M1s) on YouTube

## Summary

I've been experiencing a problem with my personal website, mikebifulco.com, where my newsletter sign-ups have mysteriously plummeted. In this video, I take you through the process of diagnosing and debugging this issue using Posthog, a powerful product analytics tool.

We'll start by taking a look at the site, identifying potential problem areas, and then diving into the code. I'll show you how I implement Posthog to track user interactions and gather valuable insights. We'll explore how to handle form submissions, track events, and use Posthog’s features to pinpoint what's going wrong.

Throughout the video, I'll share my thought process, hypotheses, and the steps I take to experiment and test different solutions. If you've ever had a non-bug issue in production, this video is for you. Let's get to the bottom of this conversion rate mystery together!

You might be interested in this video if you want to learn about debugging and optimizing website performance, especially using tools like Posthog. Relevant technologies and subject areas include React, Next.js, form handling, product analytics, serverless functions, and conversion rate optimization.

## Video Timestamps

0:00 Product Analytics for engineers: Debugging a form conversion rate problem on my website with Posthog

01:05 Site walkthrough

01:30 Are people annoyed by the popup?

02:53 Long form article pages

04:02 Looking at the code

05:20 Dive into the code

07:13 Newsletter form refactor

10:45 Serverless function for newsletter subscribe

12:26 The results in Posthog

13:29 What we did, and what's next

14:43 Why Posthog and product analytics are helpful

15:41 Epilogue: We learned something! Next steps...

## Links

- Watch [Product Analytics for engineers: Debugging a conversion problem on my next.js site using @PostHog](https://youtu.be/4nWcB1a8M1s) on YouTube
- Part 2 of this series: [Fixing the sign-up problem on my site using PostHog Product analytics](/posts/fixing-my-conversion-problem)


Mike Bifulco

💌 Tiny Improvements Newsletter