
<Image
  publicId="newsletters/reflecting-on-one-year-as-startup-cto/cover"
  alt="The first year of being a technical startup cofounder"
/>

Last year, I wrote a reflection on [the first 90 days as a technical cofounder](https://mikebifulco.com/newsletter/building-a-startup-in-2023-90-day-report) about the first three months of building Craftwork. That article was largely a reflection on the differences between building a company from scratch in 2023 versus the last time I did it, around 2016. Plenty has changed since then, and I think that article is still worth a read.

Today, I want to reflect on the first year of building [Craftwork](https://craftwork.com/). We've written many chapters of our story in the last year, and I think it's worth taking a moment to reflect on what we've accomplished and what we've learned.

<SponsoredSection
  CTAtext="Subscribe Today"
  href="https://codestory.co/"
  imagePublicId="sponsors/code-story/hero"
>

### Their tech, Their products.... Their Stories.


Code Story is a podcast featuring founders, tech leaders, CTOs, CEOs, and software architects, reflecting on their human stories in creating world changing, disruptive digital products.


</SponsoredSection>

## You won't know some things until you try

I've spent a good deal of my career working in UX. I've gotten to work with some incredibly talented designers and UX researchers, and I do believe that good design is a competitive advantage. Even still, when building real features for real people, you can't always predict what will work and what won't.

Designing great software needs to be both proactive and reactive - you need to have a vision for what you want to build, but you also need to actively respond to feedback and data.

For example: the very first version of Craftwork's estimate builder was designed to be _extremely_ self-serve - we built a tool that would let customers scope out their entire project without needing to talk to us. We thought this would be a great way to let people get a feel for what we could do for them, and to be extremely transparent about what their project would cost.

In practice, we found that people were often overwhelmed by the number of choices they had to make. Over and over we saw people getting stuck playing with our estimate builder, weighing the cost of one little change against another. Many people got stuck on this process, and never actually submitted a request for painting.

On a hunch, we ran a quick A/B test to see if it would be more productive to have a conversation with one of our team members first, and the results were clear: our customers have lots of interesting questions, and a price calculator wasn't answering all of them.

We've since reworked the estimate process to be more of a guided conversation, and we've found that using it to create a human connection with our customers has been a great way to build trust and to get the ball rolling on a project.

## You can't do it alone

While building my last company, I was convinced that we could do everything with an exceptionally small team - we were just 3 people, from inception to acquisition. I'm proud to say we did the damn thing, but it was _really_ difficult. You'll often hear founding employees at startups talk about how they're "wearing many hats" - that's definitely true, and it makes work a lot of fun. It's also true that you can't wear _all_ the hats. It's _also also_ true that there exciting, beautiful new hats out there that you don't know you need to wear.

From my first day as a working professional, I've always wanted to be surrounded by people who are smarter than me. Building Craftwork has been no exception - my cofounders are dedicated, talented, and damn good at what they do. We have also hired some _truly_ amazing people to build our team.

### A few things I've learned about building the right team:

Engineers tend to undervalue the importance of understanding the mechanics of the business. Our growth team at Craftwork has been instrumental in helping us understand how to reach new customers, and how to build a _profitable_ product that people want.

Building a brand is like nurturing a garden. It takes time, patience, and a lot of care. Craftwork's brand has really grown into something special, and it's been a joy to watch it happen. Give our [Instagram](https://www.instagram.com/craftworkpaint/) a peek if you want to see what I mean.

At this stage in the startup journey, hiring engineers is really challenging. The perfect engineer for a startup is someone who is comfortable with a lot of ambiguity, who can work independently, and who can communicate well... in addition to being technically competent. It's a tall order, and it can be a challenge to find the right people.

When I have roles open on my team, hiring is the most important thing I do day to day. It is also a full-time job in itself. It requires a fair deal of patience to assemble the right team, as well as a drive to actively and creatively seek out the right people.


## Just enough (and nothing more)

I recently came across the Japanese Phrase ほどほど (hodohodo), which means "just enough." I've been trying to use it as a reminder to keep things simple, and to avoid overcomplicating things. My team is tasked with building the features we need most _today,_ with eyes on what we'll need in 6 months and a year... and that can be overwhelming.  It's easy to spiral out of control with feature creep and over-engineering, and finding ways to help each other _just-enough-for-now_ is a team remit.

_Just enough_ spills over into many areas:
- **Build vs buy:** almost every feature our team needs can be bought from a SaaS vendor, or coach built by our product team. Making this decision can be nuanced and difficult, and it's something we revisit regularly.
- **Adopting tooling:** Engineers love to play with new tools - there's always a new framework, language, database, or library to poke around with. We've been very deliberate about what we adopt, and we've been very careful to avoid adopting things just because they're new and shiny. We have also adopted tools with good intentions, and found ourselves jettisoning them when they don't work out for one reason or another.
- **Shipping new features:** Adding new functionality for our customers and teammates is always tempting, but it's important to be mindful of the complexity that comes with each new feature. Our engineering team is small-and-mighty, and ever new feature we build means we have less time to support the features we've already built.

I used to say _Just enough (and nothing more)_ - there's a funny irony in that phrase. A year into this thing, this feels more accurate: Just enough <s>(and nothing more)</s>.

---

## More on building startups

If you're inerested in a more detailed look at the past year, here's a few more links you might find interesting:

- 🎙️ [My interview on the podcast CodeStory](https://codestory.co/podcast/e14-mike-bifulco-craftwork/) was released today. Codestory's creator, Noah, was kind enough to reach out about sponsoring this newsletter as well. Telling Craftwork's origin story is a good reminder of how far we've come in a year.
- 🥽 [Learning is an infinite game](https://mikebifulco.com/newsletter/learning-is-an-infinite-game) tells a little bit about how we used 3D printing tech to produce tooling for large-scale paint projects, and what it was like to dive in to CAD modeling after years away.
- 📋 Hiring is hard. There have also been a ton of layoffs in the past year-and-change. I wrote [Your Resume Sucks. Here's how to fix it](https://mikebifulco.com/newsletter/your-resume-sucks) in an effort to help engineers represent themselves better when looking for a job.

---

## Thanks for reading

I'm grateful for the opportunity to reflect on the past year, and I'm grateful for the opportunity to share it with you. If you have any questions about what it's like to build a startup, I'd love to hear from you. Reply to this email and let me know what's on your mind.


The first year of being a technical startup cofounder


<Image
  publicId="newsletters/reddit-for-learning/cover"
  alt="Reddit as a tool for learning"
/>

Reddit has been an incredible tool for me as a writer and a learner. I've benefitted from many subreddits over the years, by immersing myself special interest topics for fun, like Strava or Watchmaking or Woodworking. I've also used reddit to share articles I've written, and to research niches for product ideas.

One thing I really love about reddit is that it is a fairly even playing field - posts that get upvotes ones which are interesting to real people, and the discussions that result are often candid and helpful.

It's not a popularity contest, it's a meritocracy.

_Many_ of the technical subreddits I frequent have fairly strict rules about what can be posted. Moderators are quick to remove low-content or spammy posts, and the community is quick to downvote posts that don't add value. When it works, this results in a fairly high signal-to-noise ratio, making places like [/r/javascript](https://reddit.com/r/javascript) a great place to learn.

Reddit's community code of conduct also encourages participation - reddit's famous 10% rule states that you should spend 10% of your time posting and 90% of your time commenting. This helps to keep the community active and engaged, and it also helps to keep the community from being overrun by spam.

This is a good thing, because it means that the content that _does_ get posted is generally high quality, and the discussions that result are often helpful and interesting.

Since the beginning of 2023, I've tried to spend some time browsing subreddits for [JavaScript](https://reddit.com/r/javascript), [Next.js](https://reddit.com/r/nextjs), and [Computer science](https://reddit.com/r/computerscience). It's an interesting way to keep up with what's going on in the industry, and is a good way to keep my own skills sharp.

I used to dismiss reddit as something that I didn't understand - though I've had an account for years, I didn't use reddit regularly until about 2018. If you find yourself in the same boat, consider giving it a try - rather than spending your time doomscrolling on instagram and TikTok, create a reddit account and subscribe to subreddits that will help you _learn_ something. Whether it's directly applicable to your professional life or not, having a steady drip of discussion from topics that interest you can be a fantastic way to stay sharp, and to keep an eye out for new opportunities.

Once you've done that, consider adding to the community by participating in discussions and posting content of your own. You'll be surprised at how much you can learn by teaching others, and you'll be surprised at how much you can learn by asking questions.

---

## Some super subreddits that suprised me

- [r/firebase](https://reddit.com/r/firebase) is the home on reddit for people building products with Firebase. My last startup was built using Firebase, and this subreddit was a great resource for me. It is moderated by a team of Firebase employees, and full of experienced devs with great advice.
- [r/buyitforlife](https://www.reddit.com/r/BuyItForLife/) is a subreddit where people ask about and recommend products that are built to last.
- [r/nextjs](https://reddit.com/r/nextjs) is just what it sounds like: discussions about building with Next.js. For me, it serves as a helpful ear-to-the-ground for tooling and best practices.
- [r/nocode](https://www.reddit.com/r/nocode/) might be one of the most inspiring subreddits I've found. No code tooling has come _so far_ in the past few years. There are solo founders building entire companies on no code tools. It's incredible.

## It's been a little quiet...

...on the Mike-publishes-content front lately. I've got a few things to share soon which I'm excited to share with you, buuut not for another week or two. If you're jonesing for some fun reading, the APIs You Won't Hate community has produced some great stuff lately:

- 🎙️ [My interview with Constantin Schreiber from Fastgen](https://apisyouwonthate.com/podcast/no-code-apis-and-automation-with-constantin-schreiber-from-fastgen/) dives into the low-code tooling for API devs that Fastgen is building.
- 📝 My cofounder and pal Phil Sturgeon produced a great review tooling review - [APIMatic Review: Developer Experience-as-a-service](https://apisyouwonthate.com/blog/apimatic-review-dx-as-a-service/)


Reddit as a tool for learning


OpenApi.tools is an Open Source and community-driven list of high-quality, modern tools for OpenAPI that we've been maintaining over at APIs You Won't Hate for the past few years, and it's overdue for a rebuild.

🔧 In this session, I'll be using Astro.build to recreate the openapi.tools site, with a focus on building a highly performant, maintainable, and SEO-driven experience for the next version. If i'm lucky, we'll even get into building some fun new features to help our community find the right tools for their use case with OpenAPI

I'll be building with:

- Astro: https://astro.build
- Hosting through @VercelHQ
- Visual Studio Code
- TypeScript
- React.js
- Markdown
- Fathom analytics @FathomAnalytics
- PostHog @PostHog
- Tailwind CSS @TailwindLabs

📅 Mark your calendars and join me at 10am EST for an insightful journey through the intersection of design and development. If you dig SEO and markdown, or you're a React developer, JavaScript enthusiast or TypeScript pro, or you've been curious about what Atsro brings to the table, you'll enjoy this one!

Don't miss out on this opportunity to learn, create, and connect. Be sure to subscribe and click the notification bell to stay updated on this and more exciting content from Craftwork.

For additional resources like my newsletter for founders and product builders, 💌Tiny Improvements, visit my website at https://mikebifulco.com/newsletter


Rebuilding an open source content-rich site with Astro, TypeScript, and React


Join me for an exciting live stream where we dive into the world of design and development at Craftwork! 🎨💻

🔧 In this session, we'll explore how we use a variety of image templates to elevate our software's appearance. From stylized portraits of our talented team members to vibrant paint swatches and eye-catching Open Graph (OG) preview images for our website, we'll unveil the secrets behind our visual magic.

🖌️ We'll kick things off by using the power of Figma, our design tool of choice, to craft stunning templates. Then, we'll dive deep into the development side, where we'll transform these designs into dynamically generated images. How? With the incredible Satori library and the magic of Edge Functions on Next.js, brought to you by the team at @VercelHQ .

I'll be building with:

- Satori & Next.js from @VercelHQ
- Figma
- Visual Studio Code
- TypeScript
- Tailwind CSS @TailwindLabs

📅 Mark your calendars and join us on Jan 27th at noon EST for an insightful journey through the intersection of design and development. Whether you're a React developer, JavaScript enthusiast, TypeScript pro, designer, or simply curious about UX and tech, this livestream is for you!

Don't miss out on this opportunity to learn, create, and connect. Be sure to subscribe and click the notification bell to stay updated on this and more exciting content from Craftwork.

See you there! 🚀🎉


Using Satori and Next.js to generate dynamic images


## Notes about today's Livecoding stream
This is a YouTube Livestream, where I'll be working on integrating Resend Broadcasts into my next.js site to use for sending newsletters. Resend released a new set of features this week that makes it easier to send mail to large audiences.

I'll be building with:

- Resend
- Next.js
- TypeScript
- Vercel
- Tailwind CSS

With Substack recently catching headlines for their boneheaded content moderation policies, lots of creators and developers have been looking at other tools for managing their mailing lists. Between Beehiiv, ConvertKit, Ghost, Mailchimp, and some of the other usual suspects, there are many options to choose from.

Let's take a look at Resend's new API to see how it works, and if it's a good fit for my workflow!

## Don't forget to subscribe

If you're interested in more content like this, please subscribe to my **[YouTube channel - @mikebifulco](https://www.youtube.com/@mikebifulco?sub_confirmation=1)!**


Configuring Resend Broadcasts for newsletters on my Next.js website



<small>

_note: This post is inspired by a great video from YouTuber Aaron Francis: [Make self-healing URLs with Laravel](https://www.youtube.com/watch?v=a6lnfyES-LA). For all my PHP homies - go check that video out. It's great!_

</small>

<Image
  publicId="posts/self-healing-urls-nextjs-seo/demo"
  alt="A demo of a self-healing URL made in Next.js"
  caption="Ever wonder how Amazon and Medium create self-healing URLs?"
/>

Building sites with human-readable URLs is helpful for a few reasons: it gives users a better understanding of what they're getting when they click on a link to your site, it's better for SEO, and it's more accessible (screen readers can read out the URL to the user and they can understand where they are on the site). It's also just a nice thing to do for your users... by way of example, these two URLs _feel_ dramatically different:

`https://example.com/posts/c61sca0`

vs

`https://example.com/posts/how-to-set-up-self-healing-urls-in-nextjs-for-better-seo`

The first one is a bit of a mystery box. You have no idea what you're going to get when you click on it. The second one is much more descriptive, and _hopefully_ the contents of the page match the URL.

...but, what happens if you change the title of the post? The human-readable URL is now misleading. If you're using a static site generator like Next.js, you can use the file system to create self-healing URLs that will always point to the correct page, even if the title changes.

Or, what if you're managing a larger site, where it's possible that two posts may have the same title?

These are both issues that self-healing URLs are attempting to solve.

## What are self-healing URLs?

**Self-healing URLs are URLs that allow for human-readable text, but also include a unique identifier that will always point to the correct page**, even if the human-readable text changes, or gets removed entirely.

In this post, we'll learn **how to set up self-healing URLs in Next.js.** This is something used on sites like Amazon and Medium to make sharing links a little more robust. These are URLs that allow for human-readable text, but also include a unique identifier that will always point to the correct page, even if the human-readable text changes, or gets removed entirely.

Here's the URL-pattern we're to build: `https://example.com/posts/${POST_TITLE}-${POST_ID}`.

Ultimately, we'll use the `id` of a post to identify which content to render on a page, and we'll use the `title` of the post to create a human-readable portion in the URL. As long as the URL ends with a hyphen followed by the `id`, we will redirect to the correct page, with a nicely formatted, human-readable URL.

## Self-healing URLs in Next.js with the App router

To create self-healing URLs for blog posts with the [Next.js App router](https://nextjs.org/docs/api-reference/next/router), we'll start with a fresh react app from the cli:

```bash
# with npm
npx create-next-app

# or, with yarn
yarn create next-app

# or, with pnpm
pnpm create next-app
```

Give your project a name, and select the options you want to use. I used all the defaults for this example:

```
✔ What is your project named? … next-self-healing-urls-app-router
✔ Would you like to use TypeScript? Yes
✔ Would you like to use ESLint? Yes
✔ Would you like to use Tailwind CSS? Yes
✔ Would you like to use `src/` directory? Yes
✔ Would you like to use App Router? (recommended) Yes
✔ Would you like to customize the default import alias (@/*)? No
```

You'll also need to install the `slugify` package, which we'll use to create a URL-safe slug from the post's title:

```bash
npm install slugify

# or, with yarn
yarn add slugify

# or, with pnpm
pnpm add slugify
```

### Set up dynamic routing

We'll need to add a few files to the default setup. Using the App directory, create the following directories and files:

```
app
├── posts
│   └── [slug]         // note that this is a _folder_ called [slug]. This is how dynamic routes are set up in the app router
│        └── page.tsx  // render one post
├── not-found.tsx      // this will render if someone tries to visit a post page with an id that doesn't exist in the url
├── sitemap.ts         // generate a dynamic sitemap with the _correct_ canonical URL for each post
└── utils
    └── post.ts        // types and helper functions to load posts and format URLs
```

Let's start with `post.ts`. This file contains a type definition and helper functions to load posts and format URLs.

```ts
import slugify from 'slugify';

export type Post = {
  userId: number;
  id: number;
  title: string;
  content: string;
};

export const getAllPosts = async () => {
  // fetch all posts from an example API.
  // this is just a placeholder, replace with your own data
  // shout out to https://jsonplaceholder.typicode.com/ - what a great service!
  const postsResponse = await fetch(
    'https://jsonplaceholder.typicode.com/posts',
  );
  const posts = (await postsResponse.json()) as Post[];

  return posts;
};

export const getPostById = async (id?: string | number) => {
  if (!id) {
    throw new Error('No ID provided');
  }

  if (typeof id === 'string') {
    id = parseInt(id);
  }

  const allPosts = await getAllPosts();

  const post = allPosts.find((post) => post.id === id);

  if (!post) {
    // we'll use a try/catch block around this function later
    // to redirect if a post doesn't exist with this id,
    // so make sure to throw an error here.
    throw new Error('Post not found');
  }

  return post;
};

/**
 * Converts input to a URL-safe slug
 * @param {string} title - the title of the post
 * @returns {string} a URL-safe slug based on the post's title
 */
const titleToSlug = (title: string) => {
  const uriSlug = slugify(title, {
    lower: true, // convert everything to lower case
    trim: true, // remove leading and trailing spaces
  });

  // encode special characters like spaces and quotes to be URL-safe
  return encodeURI(uriSlug);
};

// given a post, return its slug
export const getPostSlug = (post: Post) => {
  return `${titleToSlug(post.title)}-${post.id}`;
};

// given any slug, try to extract an id from it
export const getIdFromSlug = (slug: string) => slug.split('-').pop();

```

### Generate a sitemap with the correct canonical URL for each post

Let's talk SEO for a moment: Google (and other search engines) use your site's sitemap file to understand the structure of your site. This helps them index your site more accurately, and it helps them understand which pages are the most important. Next.js supports static and dynamic sitemap generation, which you can read about in their [docs on sitemap.xml](https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap). Your sitemap should contain the canonical URL for every page in your site.

When Google and other search engines crawl your site, they use the Sitemap as an address book, and then visit each page found in the sitemap to analyze the content on the page, and deciding how to rank it in search results. If the URL in the address bar doesn't match the URL that Google has indexed for that page, it can cause problems with SEO. For example, if you have a page with the URL `https://example.com/foo/bar/some-url-here`, but Google has indexed the page as `https://example.com/foo/bar/some-other-url-here`, Google will think that you have two pages with the same content, and it will penalize you for duplicate content.

This is where the **canonical tag** comes in. The [canonical tag](https://ahrefs.com/blog/canonical-tags/) is a special bit of metadata that you can add to your page's `<head>` tag, which is used to tell search engines which URL is the _original URL for the content onthat page_. Ideally, the canonical URL for our blog posts should _exactly_ match the pattern we've set up for our self-healing URLs: `https://example.com/posts/${POST_TITLE}-${POST_ID}`. This is the URL that we want Google to index for each post. We'll do that by making sure we use this URL in our sitemap, and by adding a canonical tag to each post page.

A canonical tag looks like this:

```html
<link rel="canonical" href="https://example.com/foo/bar" />
```


So, this is what sitemap.ts looks like:

```ts
import { getAllPosts, getPostSlug } from '@/utils/posts';
import { MetadataRoute } from 'next';

export default async function sitemap(): MetadataRoute.Sitemap {
  const allPosts = await getAllPosts();

  let urlPrefix = 'http://localhost:3000';
  if (process.env.NODE_ENV !== 'production') {
    urlPrefix = 'https://example.com';
  }

  return allPosts.map((post) => ({
    url: `${urlPrefix}/posts/${getPostSlug(post)}`, // https://example.com/posts/this-is-a-post-1
    lastModified: new Date(), // ideally, this is the last modified date of the post
    changeFrequency: 'daily', // this will be used to determine how often pages are re-crawled
    priority: 0.7, // the priority of this URL relative to other URLs on your site
  }));
}
```

Now, if you run your app and visit `https://localhost:3000/sitemap.xml`, you should see a sitemap that includes an entry for each post, with the correct canonical URL specified.


### Setting up page.tsx: where the magic happens

In the file `app/posts/[slug]/page.tsx`, we use the [Next.js App Router's `generateStaticParams` function](https://nextjs.org/docs/app/building-your-application/routing/dynamic-routes#generating-static-params) to generate URLs for all posts. This function is called at build time, and it returns an array of objects that contain the `slug` for each post. The `slug` is used to generate the URL for each post page.

Then, in the server function which renders the post page, we check whether the current URL's readable portion matches the post's actual slug. If not, we redirect to the correct URL.

We also use the [Next.js App Router's `generateMetadata` function](https://nextjs.org/docs/app/next-script#generating-metadata) to generate metadata for each post. This function is called at build time, and it returns an object that contains the `title` and `alternates` for each post. The `alternates` object contains the `canonical` URL for each post, which is used to tell search engines which URL is the correct one for each post. **This is critical for SEO purposes** - it helps Google verify that when your page loads, the URL in the address bar matches the URL that Google has indexed for that page.


```tsx
import { Metadata, ResolvingMetadata } from 'next';
import { RedirectType, notFound, redirect } from 'next/navigation';
import { isRedirectError } from 'next/dist/client/components/redirect';

import { Post, getAllPosts, getPostById, getPostSlug } from '@/utils/posts';
import { getIdFromSlug } from '@/utils/posts';

// generate URLs for all posts
export async function generateStaticParams() {
  const posts = await getAllPosts();

  return posts.map((post) => {
    const slug = getPostSlug(post);

    return {
      slug,
    };
  });
}

type PostPageParams = {
  params: {
    slug: string;
  };
};

export default async function Post({ params }: PostPageParams) {
  const id = getIdFromSlug(params.slug);

  let post: Post;
  try {
    post = await getPostById(id);
    const correctSlug = getPostSlug(post);

    // check whether the current URL's readable portion matches the post's actual slug
    if (correctSlug !== params.slug) {
      // if not, redirect to the correct URL
      const redirectUrl = `/posts/${correctSlug}`;
      await redirect(redirectUrl, RedirectType.replace);
    }
  } catch (e) {
    // this is a hack to make redirects work from within a try/catch block
    // shout out to @jeengbe on github for the tip
    // https://github.com/vercel/next.js/issues/49298#issuecomment-1537433377
    if (isRedirectError(e)) {
      throw e;
    }

    // if the post doesn't exist, return the "not found" 404 page
    notFound();
  }

  // make your post look nice IRL
  return <div>My Post: {params.slug}</div>;
}

export async function generateMetadata(
  { params }: PostPageParams,
  parent: ResolvingMetadata,
): Promise<Metadata> {
  // read route params
  const id = getIdFromSlug(params.slug);
  // fetch data
  const post = await getPostById(id);

  return {
    title: post.title,
    alternates: {
      canonical: `https://example.com/posts/${params.slug}`,
    },
  };
}
```

Another important note - _entire_ component is rendered server-side - visitors to this page won't see any content flash on screen if they enter an incorrect URL. This is huge for page performance and SEO purposes, and has traditionally been challenging while using Static Site Generation.

Instead of a screen flash, your users get a great experience: they can try to load an incorrect URL, and as long as the URL ends with a hyphen followed by the `id`, they'll be redirected to the correct URL seamlessly, like magic. If the URL doesn't match the pattern, they'll be redirected to the 404 page.



### Not Found: a 404 page for posts that don't exist

In `app/not-found.tsx`, create a 404 page that will render if someone tries to visit a post page with an id that doesn't exist in the url. [Next provides a `notFound` function](https://nextjs.org/docs/app/api-reference/functions/not-found) that will return a 404 page. We used this in page.tsx to return a 404 page if the post doesn't exist. You'll want to make this page look nice and include some helpful text, but for the sake of this example, we'll keep it simple:

```tsx
/*
  redirect to this page by calling the `notFound` function from the App Router in a page's server function:
  import { notFound } from 'next/navigation';
*/

export default function NotFound() {
  return <div>Not Found</div>;
}
```

## Try it out!

That should do it! run `yarn dev` to start the server, and navigate to `http://localhost:3000/posts/1` - you'll see it _automatically_ redirect to a better URL.

<Image
  publicId="posts/self-healing-urls-nextjs-seo/demo"
  alt="A demo of a self-healing URL made in Next.js"
/>

Nice!

Head over to `http://localhost:3000/sitemap.xml` and check out the nicely formatted sitemap, with the correct canonical URL for each post. Now your web app, your readers, _and_ Google are all on the same page. 🔥

## To do: update your redirects when a post's title changes

To be completely thorough there's one more thing we should probably do: if a post's title changes, you should add an entry to your redirects file to redirect the old URL to the new one. Even though this is a self-healing URL, it's still a good idea to add a redirect for the old URL, just in case someone has bookmarked it, or if someone has shared it on social media. This will also help Google understand that the old URL is no longer the correct one, and that it should index the new URL instead.

This is a bit more challenging, but it's worth it.

Because making this work is dependent on your specific setup, I'm not going to include a code example here, but I'll give you a few pointers:

- In your CMS, when a post is saved, check whether the title has changed. If it has, add an entry to your redirects file to redirect the old URL to the new one.
- It's a good to make sure that you don't accidentally create a redirect loop. If the new URL for a given path is the same as any of the prior URLs, don't add a new redirect, and remove any existing redirects for that path.
- You may need to kick off a rebuild of your site to make sure that the new redirect is picked up by your app. If you're using Vercel, you can use their [API to trigger a rebuild](https://vercel.com/docs/api#endpoints/deployments/redeploy-all-deployments) when a post is saved.


## Summary: self-healing URLs in Next.js

In this post, we learned how to set up self-healing URLs in Next.js. We used the App Router to generate URLs for all posts, and we used the App Router's `generateMetadata` function to generate metadata for each post. This function is called at build time, and it returns an object that contains the `title` and `alternates` for each post. The `alternates` object contains the `canonical` URL for each post, which is used to tell search engines which URL is the correct one for each post. **This is great for SEO purposes** - it helps Google verify that when your page loads, the URL in the address bar matches the URL that Google has indexed for that page. It also has usability benefits: if your post's title ever changes, the URL will magically update itself to match the new title. Additionally, people who visit your page while using a screen reader will have a better experience, because the URL will always match the content on the page.

Not too shabby!

## Get the code

You can find the code for this tutorial on [GitHub at mbifulco/next-self-healing-urls-app-router](https://github.com/mbifulco/next-self-healing-urls-app-router). If you enjoyed this post, please consider giving it a star ⭐️ on GitHub!


## PS: What about using the Next.js Pages router?

This post _started_ as a tutorial for using the Next.js Pages router to create self-healing URLs, but I ran into a few issues that would make it really challenging to recommend going down this path if you're using the pages router (which is actually what [mikebifulco.com uses](https://github.com/mbifulco/blog)!). For that reason, I think **this is a feature you should only add if you're using the App Router**. I'm including the draft of my original post here [in a gist](https://gist.github.com/mbifulco/daf23aed0d827ec6317962691cb9cd0d) in case anyone wants to take a stab at it. If you figure it out, please let me know!




How to set up self-healing URLs in Next.js for better SEO


## Adding custom fonts to your website is a typical requirement for most web projects

By default, Next.js sites will add small set of fonts that you can use for your sites (in addition to the default fonts for a given browser). That can be useful to get started quickly, but for most custom site designs, you'll need to add custom fonts and typefaces that fit your site's brand and design guidelines.

In this tutorial, you'll learn how to **add custom fonts to your Next.js site using the `next/font` package and Tailwind CSS**. There's a few configuration steps needed to load fonts from Google Fonts using `next/font`, generate CSS variables for each font, and then use those variables to create custom font families in your Tailwind config.

With this setup, you'll be able to easily use your custom fonts throughout your Next.js app using Tailwind's utility classes.

### SEO Benefits of using custom fonts correctly on your Next.js site

In addition to improving the user experience, implementing custom fonts on your website can also have a [positive impact on your Lighthouse scores](https://web.dev/patterns/web-vitals-patterns/fonts/) and SEO. However, it's important to implement custom fonts carefully to avoid performance issues. Using too many or too large font files can slow down your site's loading time and hurt your Lighthouse performance score. Additionally, using custom fonts in a way that affects the visual stability of the page can result in lower scores for Core Web Vitals, which can impact your SEO. So, it's important to strike a balance between using custom fonts to enhance the design and ensuring that they don't negatively impact performance or user experience.

### About next/font

[`next/font` is an npm package](https://nextjs.org/docs/api-reference/next/font) developed by Vercel, which provides an easy way to load fonts in your Next.js app, while maintaing performance, and minimizing [Cumulative Layout Shift (CLS)](https://web.dev/optimize-cls/). It uses the Font Loading API to asynchronously load local font files stored in your repo, or from popular font providers such as Google Fonts, Typekit, and Fonts.com. The package also generates optimized font subsets to reduce the amount of data transferred over the network, and it provides a convenient way to generate CSS variables for each font, which can be used to create custom font families in your [Tailwind config](https://tailwindcss.com/docs/configuration). This makes it easy to use custom fonts throughout your Next.js app with minimal configuration.

## How to: Add multiple custom fonts to your Next.js site with Tailwind CSS

There are several ways to load custom fonts into your next.js app. If you're using a Google Fonts as your custom font provider, you can use the `next/font/google` package to load fonts from Google Fonts. The process is slightly different for loading font files that are stored locally in your repo, but the basic steps are the same:

### Load custom fonts from Google Fonts

In `_app.jsx/tsx`, load your the fonts you need from `next/font/google`, but use the `variable` configuration prop, which you will use to generate a definition for a CSS `--var` for each font:

```tsx
import { Barlow_Condensed, Inter } from 'next/font/google';
const barlowCondensed = Barlow_Condensed({
  weight: '700',
  subsets: ['latin'],
  variable: '--font-barlow-condensed',
});
const inter = Inter({
  subsets: ['latin'],
  variable: '--font-inter',
});
```

### Load custom fonts from a local file

This next example shows how you would load a font from a local file. It also showcases another feature of the `next/fonts` library - you can map font weights to different files as needed. This also applies for font _styles_ (italic, bold, etc).

In `_app.jsx/tsx`, load your the fonts you need from `next/font/local` using the syntax below. Note that in this case, font files in my repo are also being hosted in `/public/fonts` directory. Again, make sure to use the `variable` configuration prop, which you will use to generate a definition for a CSS `--var` for each font:

```tsx
import localFont from 'next/font/local';

const grosa = localFont({
  src: [
    {
      path: '../../public/fonts/Grosa/Grosa-Regular.woff2',
      weight: '500',
      style: 'normal',
    },
    {
      path: '../../public/fonts/Grosa/Grosa-Medium.woff2',
      weight: '600',
      style: 'normal',
    },
    {
      path: '../../public/fonts/Grosa/Grosa-Bold.woff2',
      weight: '700',
      style: 'normal',
    },
  ],
  variable: '--font-grosa',
});
```

### After loading custom fonts, generate CSS variables for each font

Then, in that same `_app.tsx` component - pass the generated variables into the wrapper class. This will make that variable available to any child of that element in the DOM (in other words, your whole app):

```tsx
export default function MyApp({ Component, pageProps }) {
  return (
    <main
      className={`${inter.variable} ${barlowCondensed.variable} ${grosa.variable}`}
    >
      <Component {...pageProps} />
    </main>
  );
}
```

Behind the scenes, next is generates unique css classes for each font permutation. These classes do one thing: they define a [css custom property](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties) (sometimes called a css variable) for each font.

By adding the resulting CSS classes to the root of your Next.js app, these variables are made available to any child of the `App` component - essentially all pages and components on your site.

<Image
  publicId="posts/custom-fonts-with-next-font-and-tailwind/classes"
  caption="is a screenshot from Chrome Browser tools for Craftwork.com, which is built using this setup"
  alt="screenshot of chrome browser tools showing the resulting CSS classes"
/>

### Use these variables your Tailwind config to create font families

Up to this point, we've loaded our custom fonts into our Next.js app, and we've made those fonts available to our entire app using CSS variables. Now, we need to tell Tailwind how to use these variables, by assigning them to specific font-family classes.

In your Tailwind config, add an entry to your `theme.extend`, to create a new font family that uses the google fonts you just imported - that will look something like this:

```tsx
// tailwind.config.js
export default {
  theme: {
    extend: {
      fontFamily: {
        "barlow-condensed": "var(--font-barlow-condensed)", // note: you can call the left side of this whatever you want - barlow-bold or title-font or foo-bar, this is what you'll use in your Tailwind css classes to use this font
        "inter-medium": "var(--font-inter)", // note: the bit that goes inside the var() function is the same variable name we defined in app.tsx
      }
    }
  }
```

Then, whenever you want to use the fonts you've added, ask for that font-family in your tailwind classnames by prefixing the font-family with "font-", like this:

```tsx
const myComponent: React.FC = () => (
  <p className="font-barlow-condensed">
    This should be rendered with the Barlow font family
  </p>
);

export default myComponent;
```

That should do the trick!

If you're wondering where these steps came from, it is essentially a combination of the instructions provided in [Next's docs for Font Optimization](https://nextjs.org/docs/basic-features/font-optimization). My team is using this very configuration setup for our Next.js site on [Craftwork.com](https://craftwork.com) to load custom fonts both locally and from Google Fonts, and it's been working great.


Add custom fonts to Next.js sites with Tailwind using next/font


## I'm new to TypeScript.

I've been using TypeScript to build software for my new company, [Craftwork](https://craftwork.com). I've been pretty open about the fact that I'm new to TypeScript, and have been blissfully writing non-type-safe javascript code since somewhere around 2005.

Of course, that's all changing.

This new project is built with [create-t3-app](https://create.t3.gg), a framework for building TypeSafe apps with Next.js and TRPC. Out of the box, t3 is configured with some sensible (and fairly strict) settings for both eslint and TypeScript's tsconfig.

If you're familiar with TypeScript, Eslint, and tsconfig you may want to skip ahead to [My last resort to fix TypeScript errors in VS Code](#my-last-resort-to-fix-typescript-errors-in-vs-code).

### ESLint in a nutshell

If you're not familiar, _eslint is a **linter**_ - a tool that will help you identify and fix code quality and formatting issues in your code.

ESLint is a popular linter for JavaScript, and it can also be used with TypeScript. It provides a wide range of configurable rules that you can use to enforce consistent code style and identify potential bugs. ESLint is highly extensible, which means you can customize it to fit your specific needs. For example, you can use it to enforce your team's coding standards, or to catch common mistakes that TypeScript can't detect on its own.

### tsconfig in a nutshell

When you're working on a TypeScript project, `tsconfig.json` is a configuration file that allows you to specify how the TypeScript compiler should behave when it compiles your code.

The purpose of `tsconfig.json` is to provide a single source of truth for your TypeScript project's configuration. It allows you to specify options such as the target version of JavaScript you want to generate, the module system you want to use, the paths to your project's source files, and many other settings.

One of the main benefits of using `tsconfig.json` is that it allows you to enforce a consistent set of rules across your project. You can use it to enforce specific compiler options, which helps to ensure that your code is consistent and that everyone on your team is using the same settings. `tsconfig.json` also allows you to configure your project's build pipeline, so you can easily automate the process of compiling and bundling your TypeScript code.

Additionally, `tsconfig.json` allows you to take advantage of features like incremental compilation, which can significantly improve the speed of your builds by only compiling the parts of your project that have changed since the last build.

## How TypeScript works in VS Code

There are a few steps required to set up TypeScript to work with VS Code. If you haven't done this yet, you should follow the instructions on VisualStudio.com to get started: [TypeScript in Visual Studio Code](https://code.visualstudio.com/Docs/languages/typescript).

When you open a TypeScript file in VS Code, the TypeScript language server will start in the background. The language server is a separate process that provides language features like IntelliSense, code navigation, and code refactoring. It also provides the ability to run TypeScript code in the editor. Because TypeScript has _many_ options and plugins, the language server uses the `tsconfig.json` file in your project to determine the rules it should use to compile your code.

VS Code needs to determine which version of TypeScript to use, so it will look for a `package.json` file in your project. If it finds one, it will use the version of TypeScript specified in the `devDependencies` section. If it doesn't find a `package.json` file, it will use the version of TypeScript that is bundled with VS Code.

---

## My last resort to fix TypeScript errors in VS Code

Sometimes, when I'm working on a TypeScript project, I'll get an error in VS Code that I can't figure out. I'll check and double-check against articles and tutorials online, or ask my hyper-smart TypeScript friends ([Sean Rogers, everyone](https://seanrogers.dev/)), and despite doing everything I can think of to address the problem, sometimes I just can't get the error to go away.

Here's what I do when I find myself in this situation:

### Make sure VS Code is using the correct version of TypeScript

Sometimes VS Code's TypeScript process doesn't use the right version of TypeScript for the project I'm working on. For me, this seems to happen after updating TypeScript versions, or when switching between projects that use different versions of TypeScript.

To check which version of TypeScript VS Code is using, open the Command Palette (Ctrl+Shift+P on Windows, or &#8984; on a Mac) and type `TypeScript: Select TypeScript Version`.

<Image
  publicId="posts/typescript-vscode-error-fix-last-resort/select-typescript-version"
  alt="Select TypeScript Version in the command palette in VS Code"
/>

If the version of TypeScript that is selected is not the one you expect, select the correct version from the list. Generally speaking, you'll want to select the version of TypeScript that is specified in your project's `package.json` file, by selecting `Use Workspace Version` option.

### Restart the TS server process

If that doesn't fix the problem, or VS Code was already running my workspace's version of TypeScript, the next thing I'll do is restart the TS server process. This is the background process being run by VS Code to actually analyze and compile your TypeScript code into JavaScript. Sometimes this process malfunctions, and restarting it can fix the problem.

To restart the TS server process, open the Command Palette (Ctrl+Shift+P on Windows, or &#8984; on a Mac) and type `TypeScript: Restart TS Server`.

<Image
  publicId="posts/typescript-vscode-error-fix-last-resort/select-typescript-version"
  alt="Select TypeScript Version in the command palette in VS Code"
/>

### Restart the ESLint server process

On occasion I'll also need to restart the ESLint server process. Just like it sounds, this is the process that analyzes your code for linting errors, according to the rules specified in your project's `.eslintrc` file and the version of ESLint that is specified in your project's `package.json` file.

<Image
  publicId="posts/typescript-vscode-error-fix-last-resort/restart-eslint-server"
  alt="Restart ESLint Server in the command palette in VS Code"
/>

## If that doesn't work, I'm out of ideas

..and by that, I mean I'm still learning. There's loads to learn about TypeScript, and I've found quite a few great resources online from devs like me who have shared their experiences and knowledge. I hope this article helps you - and if you're looking for more, check these out:

- Kent C. Dodds has a great article called [Using fetch with TypeScript](https://kentcdodds.com/blog/using-fetch-with-type-script) which I nearly have memorized at this point. This is the problem I was trying work through when I discovered that I needed to restart the TS server process in VS Code.
- [James Q. Quick](https://www.youtube.com/@JamesQQuick) has a great YouTube channel where he shares tips and tutorials for building web apps with a wide variety of frameworks and technologies.
- I've got some more articles on working with TypeScript in VS Code, including [Refactoring TypeScript React components in VS Code](https://mikebifulco.com/posts/refactoring-typescript-react-components-vscode#resources-for-learning-typescript)


Steps I take to fix stubborn TypeScript errors in VS Code


## Extracting types from a JavaScript object

I am brand new to TypeScript, and far from an expert. So far, I really enjoy using it to build React apps with Next.js. As I'm growing the skills I'll need to be a better TypeScript developer, I'm finding that a fairly typical chore for me is to refactor my code to extract types from a JavaScript object. For example, I often find myself writing code in react components that looks a lot like this:

```tsx
import Footer from '@components/Footer';
import Header from '@components/Header';

const PageLayout = ({ children }) => {
  return (
    <>
      <section className="min-h-[100vh] pb-8 sm:pb-12 lg:pb-12">
        <Header />
        <div className="lg:relative">{children}</div>
      </section>
      <Footer />
    </>
  );
};

export default PageLayout;
```

There is no type-checking going on in this code as it is written. I've been writing react with good ol' plain JavaScript for so long that creating components like this is reflexive for me. I'm not even thinking about it.

Eventually during implementation I get to the point where adding some complexity to the component requires me to add some type-checking. At that point, I usually refactor the component to lambda syntax, and add a type annotation to the component:

```tsx
import Footer from '@components/Footer';
import Header from '@components/Header';

const PageLayout = ({ children }) => {
  return (
    <>
      <section className="min-h-[100vh] pb-8 sm:pb-12 lg:pb-12">
        <Header />
        <div className="lg:relative">{children}</div>
      </section>
      <Footer />
    </>
  );
};

export default PageLayout;
```

Next, I'll add a type annotation to the `children` prop:

```tsx
import Footer from '@components/Footer';
import Header from '@components/Header';

const PageLayout = ({ children }: { children: React.ReactNode }) => {
  return (
    <>
      <section className="min-h-[100vh] pb-8 sm:pb-12 lg:pb-12">
        <Header />
        <div className="lg:relative">{children}</div>
      </section>
      <Footer />
    </>
  );
};
```

Taking it a step further, I'll give the function a return type signature, using `React.FC` and generics to define the props:

```tsx
import Footer from '@components/Footer';
import Header from '@components/Header';

const PageLayout: React.FC<{ children: React.ReactNode }> = ({ children }) => {
  return (
    <>
      <section className="min-h-[100vh] pb-8 sm:pb-12 lg:pb-12">
        <Header />
        <div className="lg:relative">{children}</div>
      </section>
      <Footer />
    </>
  );
};
```

Up to this point, I don't really mind the way this component was written in any of the previous refactors. It's clearly getting more complex, but I can still understand what's going on. But what if I wanted to add a `variant` prop to the component? I'd have to add another type annotation to the function signature:

```tsx
import Footer from '@components/Footer';
import Header from '@components/Header';

const PageLayout: React.FC<{
  children: React.ReactNode;
  variant: 'dark' | 'light' | 'black' | 'tan';
}> = ({ children, variant }) => {
  return (
    <>
      <section className="min-h-[100vh] pb-8 sm:pb-12 lg:pb-12">
        <Header variant={variant} />
        <div className="lg:relative">{children}</div>
      </section>
      <Footer />
    </>
  );
};
```

Even with a little prettier formatting, this is getting a little hard to read. This is where I usually extract the props into a type, and then use that type in the function signature:

```tsx
import Footer from '@components/Footer';
import Header from '@components/Header';

type PageLayoutProps = {
  children: React.ReactNode;
  variant: 'dark' | 'light' | 'black' | 'tan';
};

type PageLayout = React.FC<PageLayoutProps>;

const PageLayout: PageLayout = ({ children, variant }) => {
  return (
    <>
      <section className="min-h-[100vh] pb-8 sm:pb-12 lg:pb-12">
        <Header variant={variant} />
        <div className="lg:relative">{children}</div>
      </section>
      <Footer />
    </>
  );
};
```

Now _this_ I like! The props for this page are defined in a single place, and the function signature is much easier to read.

## Using VS Code's refactor menu to extract types

As it works out, VS Code has loads of functionality to make this sort of work quicker. The refactor menu can be accessed by highlighting some code, right clicking on it, and selecting `Refactor...`. There are a number of TypeScript-specific functions provided which can help you refactor your code.

In this case, we can extract types from our component's signature in a few steps:

<Image
  publicId="posts/refactoring-typescript-react-components-vscode/refactor-1"
  alt="VS Code Screenshot: Select the entire `React.FC<` return type and right clicking on it"
  caption='Select the entire `React.FC<` return type and right click on it, and Choose "Refactor..." from the context menu.'
/>

<Image
  publicId="posts/refactoring-typescript-react-components-vscode/refactor-2"
  alt="VS Code Screenshot: Choose 'extract type to type alias' from the refactor menu"
  caption='Select "Extract type to type alias" to extract the type into a type alias'
/>

<Image
  publicId="posts/refactoring-typescript-react-components-vscode/refactor-3"
  alt="VS Code Screenshot: Give the extracted type a name, and hit enter."
  caption="Give the extracted type a name, and hit enter."
/>

## Bonus: Add JSDoc comments to your types for better intellisense

If you want to take it further, you can add a JSDoc comment to the type definition to add some documentation. This is a good way to document your code, and it's also a good way to get better intellisense for your code if it's supported in your editor:

```tsx
import Footer from "@components/Footer";
import Header from "@components/Header";

type PageLayoutProps = {
  children: React.ReactNode;
  variant: "dark" | "light" | "black" | "tan";
};

/**
 * The PageLayout component is used to wrap all pages in the application.
 * It provides a consistent header and footer, and a consistent layout for
 * the page content.
 * @param {object} props
 *   @param {React.ReactNode} props.children - The page content
 *   @param {"dark" | "light" | "black" | "tan"} props.variant - The color variant for the page
 * @returns {JSX.Element}
 **/
const PageLayout: PageLayout = ({ children, title }) => {

  /* etc */
```

## Don't learn TypeScript, just use it

...and by that I mean that TypeScript is a _great_ enhancement to building things with JavaScript, but you do not need to be an expert on TypeScript to use it by any means. I've been starting to use TypeScript more and more in my projects, and I've found that I can get a lot of mileage out of it without having to learn every single detail about it.

Theo from [t3.gg](https://t3.gg) has a great video that sums up my learning strategy for TypeScript pretty well, called Don't Learn TypeScript. I highly recommend watching it, or putting it in your queue for your next coffee break:

<YouTube youTubeId="kRiD6ZpAN_o" />

## Resources for learning TypeScript

As I mentioned, I'm fairly new to TypeScript - I only just started using it in the past few months. If you're learning TypeScript and are looking for some great places to learn, check these out:

- [Matt Pocock's YouTube channel](https://www.youtube.com/@mattpocockuk) is a library of really interesting videos about TypeScript. He shares tutorials as well as experience-driven, nuanced opinions about TypeScript (_when should I use an interface instead of a type?_ etc). IMO he's the defacto expert on TypeScript in real life.
- [TypeScript Course](https://www.typescriptcourse.com/) is a fantastic _free_ email course from [Joe Previte](https://jsjoe.io) [(@jsjoeio)](https://twitter.com/jsjoeio). It's a to learn TypeScript a little bit at a time.
- [TypeScript Deep Dive](https://basarat.gitbook.io/typescript/) is just what it sounds like - a thorough deep dive into TypeScript. It's a free book, with an available paid course on Udemy for those who want more .
- [TypeScript Handbook](https://www.typescriptlang.org/docs/handbook/intro.html) is the official TypeScript documentation. For better or worse, I don't think it's a great place to start, but it contains every detail you might possibly need. I've found myself coming back to it from time to time to look up specific features and to help debug this-and-that.


#typescript: 9 posts tagged