michael-dean-k/

← all posts

How I built this

A few notes about this site:

  • Every post is a local markdown file on my computer
  • It only took 15 minutes to build v1of the website with Claude
  • I can sync my local files to here with a single /push command.

Eventually I'll expand here on why having your own personal site is better than hosting your stuff elsewhere, on someone else's server, in a noisy public square. For now, I'll walk you through the set up in case you want to do the same. It's not too technical and requires no coding. You could probably upload this whole guide into Claude Code and have it walk you through. Once you have all the programs/accounts set up, and a few markdown files ready, you can launch the v1 of your site very quickly.

Set this up before you start.

  1. Obsidian: Download this app to create and edit markdown files.
  2. Claude Code: Create an account and use it through the desktop app or terminal
  3. Github: Create an account and your first repository to host your files.
  4. Netlify: Create an account, create a project, and connect it to your Github repo.

1. Obsidian: everything is local markdown files.

Over the last few years I've hosted my writing files across different apps: Notion, Evernote, Google Drive, Substack. Now I want to consolidate everything into a centralized repository, and in the spirit of "digital sovereignty," own my data. I don't want to be locked into an ecosystem; a local repo lets me be nimble, able to repoint my whole corpus to wherever it wants to be (whether it's a website like this, or context for an AI).

I have a folder on my computer called /writing, and inside of it are more folders of markdown files. I use Obsidian for text editing, which is just an interface to create, edit, and delete markdown files in a local folder. Here's the folder structure:

writing/
├── code/              ← the AI-generated website, and build.js "site builder"
├── publish/           ← canonical content (everything below ships to the web)
│   ├── assets/        ← images, referenced from files as "/assets/(name).jpeg"
│   ├── definitions/   ← vocabulary entries (vocabulary, usage)
│   ├── essays/        ← published essays (mix of full text & Substack URLs)
│   ├── logs/          ← timestamped notes (the majority of my vault)
│   ├── pages/         ← standalone pages (like this one)
│   ├── sources/       ← books from Readwise along with highlights
│   └── topics/        ← grouped into folders by category
└── working/           ← drafts and templates (gitignored, never published)

In Obsidian, if you type "- - -" on the first line, it opens up property fields on the top (like in Notion). This is called "YAML" or "frontmatter." The beauty of markdown is you can treat each file like a database object without being locked into a particular database. By adding properties, you can sort and filter views on your website. Here's an example of the YAML properties on top of an essay page (Obsidian has a clean interface to edit all this):

---
title: The Signal in the Slop
subtitle: On curation
time: 2026-04-08 18:01:00
URL: https://www.michaeldean.site/p/the-signal-in-the-slop
link-out?: false
pre-amble: #renders this as a card on top of the page
words: 1957
topics: "[[curation]]" "[[the-best-internet-esasys]]" #use [[ ]] to link pages
---

2. Claude: design your website with AI.

Once you have a collection of files, you can ask Claude Code to design the website for you. I use Claude Code in the terminal for everything, but I suppose you could do this all through the Claude desktop app as well. Either way, you described features in plain English—"a stream of logs sorted by date," "a dictionary view with A–Z navigation," "a library of book highlights from Readwise"—and Claude builds each one.

The traditional approach is to use a static site generator like Hugo, Jekyll, Astro, or Eleventy, which each have their own opinionated frameworks and conventions. Instead, I had Claude Code use the remark libraries that are beneath those generators. It wrote a "build.js" script that walks through my folders in /writing/publish/, parses each markdown file, and then renders the whole thing as HTML. Here are the libraries being used:

  • gray-matter reads the YAML frontmatter at the top of each file.
  • remark-parse parses the body into a markdown syntax tree.
  • remark-gfm adds GitHub Flavored Markdown extensions (tables, footnotes, autolinks).
  • remark-rehype converts the markdown tree into an HTML tree.
  • rehype-stringify turns the HTML tree into the final string.

The website code lives in code/:

code/
├── build.js          ← 600 lines of Javascript to turn my .mds into a site
├── package.json      ← list of dependencies for build.js to read
├── netlify/          ← where I host the site
└── src/
    └── templates/    ← the different templates throughout my site

Honestly, I haven't read the code yet. There's a possibility that this whole build is just a test site to help me visualize and format my archive, and then once I'm done I'll just rebuild the shell in 20 minutes. The principle here is that AI lets you build websites around your data, instead of fitting your data into someone else's CMS. The website is a shedable skin that can constantly molt as your archive changes.

3. GitHub: push your files to a cloud repository.

GitHub is the link between my computer and the Internet. Create an account at github.com, then create a (private) "repository"—a project folder that lives in the cloud. Think of Github as Dropbox or Google Drive but for code. There is functionality specific to software developers that you won't need to use, but Github is the standard to host code that different providers (ie: both Netlify and Claude Projects can point to your repo). It also serves as a backup and version control. After initial setup, you never need to touch GitHub's web UI.

Git is best for team collaboration, where you can have multiple branches developing in parallel (ie: different developers each working on distinct parts of the codebase and syncing back to the source), but for a personal websites, I can everything on a single branch called main. To publish your local files to your repo, there are three commands:

git add .                  # stage all my changed files
git commit -m "new logs"   # save a snapshot with a message
git push                   # send the snapshot to GitHub

Most Macs come with git already installed; if not, just ask Claude to install it for you (brew install git). Once it's working, you don't even need to remember the three commands — you can wrap them in a skill.

A skill is a custom slash command for Claude. You describe a workflow in plain English—"can you create a skill that stages all changes in writing/, commits with a sensible message, and pushes to GitHub?"—and Claude saves it as a markdown file in your skills folder. From then on, typing /skill-name runs the workflow for you.

I have two skills for managing this site:

/writing-push-local    ← runs build.js, opens site in browser to preview. 
/writing-push-public   ← pushes to GitHub, which Netlify sees.

The full workflow becomes:

  1. Write something in Obsidian
  2. /writing-push-local to preview it
  3. /writing-push-public to ship.

4. Netlify: where your site is hosted.

Netlify takes the code from your GitHub repo and publishes your site. Like GitHub, the basic setup is a one-time thing: create a Netlify account, make a new project, name it, and point it at your repo. After that, every time you push to GitHub, Netlify automatically handles the update.

If you want to add more dynamic features—user accounts, databases, etc.— things get a little more complex, but Claude Code can still handle all of it if you give it access to Netlify's command-line tools (npm install -g netlify-cli). As an example, I built a commenting system for this site: readers can highlight any passage and leave a note, and each comment lives as a row in a Netlify-hosted Postgres database.

Netlify is just one option; you can use Vercel, Heroku, Cloudflare Pages, GitHub Pages, or any other service that serves static files. They all work the same way: connect your GitHub repo, auto-deploy on push. Compare this to Squarespace, where a single platform owned the files, the design, the code, and the hosting. With a modular stack like this, you can swap out any part of this.

Any questions, email me at michael@michaeldean.site