The notes live in four apps, and none of them links to the other three. You have install notes for your home server in a default mobile notes app, coding reference snippets in a private gist folder, book takeaways in a Notion database, and hobby project research saved as loose Markdown files on your desktop. Pulling them into a single static wiki cuts app switching and lets you connect related ideas you’d otherwise miss. This project uses only plain text files, no third-party hosting lock-in, and teaches core static site fundamentals you can reuse for personal or work projects later.
Build Next Stack editors
Note names that survive a month of adding pages
Bad file naming is the number one reason personal wiki projects fall apart after a few weeks. If you name a note `server-notes.md`, you’ll have 6 overlapping versions of that file by the end of the year, none of which you can distinguish without opening each one. Kebab-case (all lowercase, spaces replaced with hyphens, no special characters or emojis) works for file names because it’s compatible with every operating system, every static site host, and eliminates broken links from unexpected URL encoding issues. A simple naming rule to follow: every file name should include the core topic, plus any context that makes it unique, such as a year, version number, or category prefix, so you don’t have to overwrite old notes when you update a process. Example measurement: Renaming 10 existing scattered notes to follow this convention takes 7 minutes total, no extra planning required.
Below is your pre-built wiki page map and internal link checklist to use for your first 10 notes, no brainstorming required:
| Note ID | File Name | Core Topic | Required Internal Link Targets |
|---|---|---|---|
| 1 | home-server-ubuntu-2404-install.md | Step-by-step install for x86 home server | 2, 4 |
| 2 | home-server-docker-portainer-setup.md | Container management dashboard setup | 1, 5 |
| 3 | python-list-comprehension-cheat-sheet.md | Reusable syntax reference for common use cases | 6, 7 |
| 4 | home-server-pi-hole-ad-block.md | Network-wide ad blocking configuration | 1, 9 |
| 5 | home-server-immich-photo-backup.md | Self-hosted encrypted photo storage setup | 2, 9 |
| 6 | python-fastapi-basic-crud-template.md | Minimal REST API starter code for side projects | 3, 10 |
| 7 | python-error-handling-best-practices.md | Debugging guardrails for small scripts | 3, 6 |
| 8 | book-atomic-habits-2023-takeaways.md | Personal productivity actionable notes | 9, 10 |
| 9 | personal-digital-backup-strategy.md | 3-2-1 backup rule implementation for personal data | 4, 5, 8 |
| 10 | side-project-roadmap-q3-2024.md | Prioritized list of hobby projects to build | 6, 8 |
Internal Link Validation Checklist
- [ ] All internal links use full root-relative syntax: `[link text](/notes/target-file-name.md)` to avoid broken relative path links
- [ ] No links point to external app URLs (e.g., Notion, Apple Notes, private gist links) for content hosted in your wiki
- [ ] Every note has at least 2 inbound links from other wiki pages to eliminate orphaned content
- [ ] No broken links (verify by clicking every link in your local preview before running a full build)
- [ ] Link text describes the target content explicitly, not generic phrases like “click here” or “see more”
Link pass that turns ten files into a wiki
A folder of disconnected notes is just a file dump, not a wiki. Internal linking turns separate pieces of information into a connected knowledge base you can navigate by context, instead of searching for file names every time. Use the required link targets in the page map above as your starting point, so you don’t waste time overthinking which notes to connect. You can insert links directly in the body of notes when you reference a related process, or add a dedicated “Related Pages” section at the bottom of each note to group links, no strict formatting rules apply for a personal wiki. Once you’ve added the required links, you can add 1-2 extra optional links per note if you spot obvious connections you missed in the initial page map. Illustrative example: A full link pass for 10 notes takes 15 minutes total, including 5 minutes to run through the validation checklist.
Build script you run after each save
You don’t need to learn a complex static site generator to build this wiki. A minimal 5-line build script handles all core functionality, and you can write it in bash, Python, or any scripting language you already know. Your initial build script only needs to do three things: first, copy all Markdown notes from your working `/notes` folder to a clean `/build` output folder, second, convert each Markdown file to valid HTML using a lightweight parser like Python’s `markdown` library or the Node.js `markdown-it` package, and third, inject a shared 1-line navigation bar at the top of every HTML page that links back to your wiki home page. You can add extra functionality later, like syntax highlighting for code snippets or auto-generated backlink lists, but start with the minimal version to avoid scope creep. Example measurement: A minimal build script runs in 2 seconds for 10 notes, so you can run it manually every time you save a change without waiting for hot reloading or build processes.
Search box that can wait until the index exists
Building search functionality is a common trap that makes new wiki creators abandon their projects before the core functionality works. You don’t need a search box for your first 10 notes: browser-native Ctrl+F or Cmd+F search on an auto-generated index page that lists all your wiki notes works perfectly fine for small collections. When you have 20+ notes and want to add dedicated search, you can generate a JSON index of all your note content during the build step, then use a lightweight client-side search library like Lunr.js to power the search box, no server or database required. All search processing runs in the user’s browser, so you don’t have to pay for any backend services to support it. Example measurement: Adding client-side search to a working 20-note wiki takes 45 minutes, which is a good follow-up task once you have the core linking and build workflow running consistently.
Export folder you can zip without a database
The entire wiki lives in your `/build` folder, which is 100% static HTML, CSS, and optional original Markdown files. There is no backend, no database, no environment variables, and no special hosting requirements to run it. You can zip the entire build folder and move it to a new computer, host it for free on GitHub Pages, Netlify, or Vercel, or even open the HTML files directly in a browser without an internet connection if you’re working offline. You can set up a simple cron job or GitHub Action to auto-export a zipped backup of the entire build folder and your original working notes every week, so you never lose access to your content if a hosting provider goes down or you lose access to one of your old note apps. Example measurement: A 10-note wiki build folder is less than 1MB zipped, so you can store hundreds of backups on a cheap USB drive with no storage constraints.
Grab the 10 most referenced notes from your four scattered apps, rename them using the kebab-case convention outlined above, and run through the first three items on the internal link checklist to connect your most frequently used ideas this week.