How to Create a Wiki for a Side Project with a Knowledge System

Why Side Projects Need a Wiki

Side projects have a specific knowledge problem that full-time projects don't: you work on them intermittently. A side project might get 3 hours on a Saturday, then nothing for two weeks, then a focused weekend, then sporadic evenings. Each time you return, you spend the first 30-60 minutes re-orienting: What was I working on? Why did I make that decision? What was I trying to figure out? Where did I leave off?

Without a wiki, re-orientation cost is high and compounds over time. The more complex the project, the longer the re-orientation takes. For projects that span years, the early decisions — why you chose this architecture, why you structured the database this way, what you learned from a failed approach — are completely inaccessible.

A wiki for a side project isn't bureaucracy. It's the mechanism that keeps context available across the gaps in your working time, enables re-orientation in minutes rather than an hour, and accumulates the project's knowledge in a form you can actually use later.

---

What a Side Project Wiki Is For

A side project wiki serves five functions:

1. Context preservation: The current state of the project, what's working, what's in progress, what decisions have been made and why.

2. Decision log: Why you made architectural decisions, technology choices, product direction choices. "I chose Postgres over MongoDB because…" documented now prevents reconsidering the same question six months later.

3. Technical reference: How the system is set up, what the deployment process is, how to run the local dev environment, what the key integrations do.

4. Research and learning: What you researched while building, what resources you found useful, what you learned from failures.

5. Future planning: Ideas and planned features, prioritization notes, directions you're considering.

---

Choosing the Right Tools

The wiki core: Notion vs. Obsidian vs. a simple Markdown structure

For a solo side project, the wiki tool should be:

• Fast to write in (friction kills side project documentation)
• Good for search (you'll search rather than browse)
• Accessible from any device (you capture ideas everywhere)
• Future-proof enough that you won't need to migrate it in 2 years

Notion: Best for most solo founders. Database features (for task tracking, decision logs with properties), easy embed of images and code blocks, web access from anywhere, reasonable search. Free for solo use.

Obsidian: Best if you prefer local files and rich linking. Every note is a Markdown file you own. The backlinks and graph view are powerful for a complex project. Sync requires iCloud or Obsidian Sync ($4/month).

A git repository's /docs folder: Best for technical projects where the wiki belongs in version control alongside the code. Every doc is Markdown, diff-viewable, and commits are timestamped. Navigation is less convenient than Notion.

The research and capture layer: WebSnips

WebSnips works alongside the wiki as the capture and research layer:

• Research you do while building (competitor research, API documentation pages, tutorials, solutions to technical problems you find)
• External references and resources
• Market research and customer feedback

WebSnips captures and annotates the external web content; your wiki documents the decisions and knowledge you generate from that content. The two systems are complementary: the wiki is your internal knowledge; WebSnips captures the external inputs.

---

Setting Up the Wiki Structure

Core sections of a side project wiki

[Project Name] Wiki

1. Overview — What this project is, who it's for, what problem it solves, current status
2. Architecture — System design, technology stack, key design decisions
3. Decision Log — A dated record of significant decisions with reasoning
4. Development Reference — How to run locally, deployment process, environment setup
5. Product — Current features, planned features, user feedback, roadmap
6. Research and Learning — External research, resources found useful, experiments and what they taught
7. Business — (if applicable) Revenue, customers, distribution channels, goals

Each section starts as a single page and expands to sub-pages as the project grows.

The overview page

The overview page is the first thing you read when you return to the project after a break. It should take under 3 minutes to read and fully reorient you.

Overview page content:

# [Project Name]

## What it is
[One paragraph: what the product does, who it's for, what problem it solves]

## Current status
[Where are we right now? What phase? Last deployed version?]

## What I'm working on now
[The immediate current focus — what was I doing before I stopped?]

## The big picture
[What does "done" look like? What's the long-term vision?]

## Key numbers (if applicable)
[Revenue, users, metrics that matter]

## Last updated: [date]

Update the "What I'm working on now" field before every session ends. This makes the next session's start-up almost instantaneous.

---

The Decision Log

The decision log is the most valuable part of a side project wiki and the most commonly skipped. It answers the question "why did I build it this way?" when you return to the project months later or when you're explaining it to someone else.

Decision log format

Create a database (in Notion) or a dated list (in Obsidian) with one entry per significant decision:

DECISION: [Title of the decision]
Date: [when decided]
Context: [what was the situation? What problem was being solved?]
Options considered:
  1. [Option A] — [pros / cons]
  2. [Option B] — [pros / cons]
  3. [Option C] — [pros / cons]
Decision: [What was chosen]
Reasoning: [Why this option over the others]
Constraints that shaped this: [time / money / skill / dependencies]
Tradeoffs accepted: [what downsides are you living with?]
Conditions for revisiting: [under what circumstances would you change this?]

What counts as a significant decision

Not every small technical choice needs a decision log entry. A useful heuristic: would you need more than 5 minutes to remember why you did this if you came back in 6 months? If yes, log it.

Decisions worth logging:

• Technology stack choices (language, framework, database)
• Architecture patterns (monolith vs. microservices, SaaS vs. self-hosted)
• Product direction decisions (adding or cutting features, targeting a different customer)
• Pricing and monetization decisions
• External service choices (payment processor, email provider, hosting)
• Any decision where you considered multiple options seriously

Decisions not worth logging:

• Implementation details that can be read from the code
• Small UX choices that can be changed trivially
• Decisions that have no persistence (which café to work from)

---

Technical Reference Documentation

The technical reference section answers "how do I [do this thing]?" without requiring investigation or debugging. For a solo project, this primarily documents:

Local development setup

A step-by-step guide to getting the project running on a new machine (or your machine after a year away):

## Local Development Setup

### Prerequisites
- [Tool 1] version [X] or higher
- [Tool 2]
- [Account/API key needed]

### Setup steps
1. Clone: `git clone [repo-url]`
2. Install dependencies: `[command]`
3. Configure environment: copy `.env.example` to `.env` and fill in:
   - `[VAR_1]`: [where to find this]
   - `[VAR_2]`: [where to find this]
4. Database setup: `[command]`
5. Run locally: `[command]`
6. App runs at: [URL]

### Known issues
- [Issue]: [workaround]

If you've set this project up more than once, you know there are "known issues" steps that aren't documented anywhere and you have to remember each time. Document them.

Deployment process

## Deployment

### To production
[Step-by-step deployment commands or process]

### What to check after deploying
1. [Check 1]
2. [Check 2]

### Rollback procedure
[How to undo a bad deploy]

### Services and credentials
- Database: [service, location]
- Email: [service, how configured]
- Hosting: [service, billing cycle, how to access]
- Domain: [registrar, renewal date]

The domain registrar and renewal date field is specifically important for side projects that may sit dormant — losing a domain because you forgot to renew it is a common side project tragedy.

Architecture overview

For anything beyond a simple CRUD app, document how the pieces fit together:

## Architecture

### System diagram
[Simple diagram or description of components]

### Key design patterns
[Any specific patterns used — event-driven, CQRS, specific caching approach — with brief explanation]

### Database schema
[Link to schema file or brief description of main tables/collections]

### API structure
[Endpoint conventions, authentication approach, rate limiting]

### Third-party integrations
- [Integration 1]: [what it does, how it's configured]
- [Integration 2]: [what it does, how it's configured]

---

Research and Learning Notes

As you build, you research and learn. Capturing this in the wiki prevents re-researching the same things and builds a record of your technical learning.

What to document

Problem-solution pairs: When you hit a bug or a problem you had to research to solve, document it:

Problem: [specific error message or symptom]
Cause: [what was wrong]
Solution: [what fixed it]
References: [links to Stack Overflow, GitHub issues, documentation that helped]
Date: [when this happened]

This is the technical variant of the decision log. Future you — or future contributors — will hit the same problems. Having them documented saves hours.

What didn't work: Failed experiments that could tempt you to try again:

Attempted: [what I tried]
Why I thought it would work: [the reasoning]
Why it didn't: [what actually happened]
What I tried instead: [the successful approach]

Useful resources found: Tutorials, documentation, blog posts, Stack Overflow answers that were genuinely useful. Brief annotation on what each one explains.

---

Integration with WebSnips for Research

WebSnips captures the external research that feeds into your wiki decisions. The workflow:

During a research session:

1. You're solving a technical problem or making a product decision
2. Capture relevant web pages in WebSnips with annotations about why they're relevant
3. Research the question, form your conclusion
4. Write the conclusion (decision or problem-solution) in the wiki
5. Link to the WebSnips captures in your wiki note if the source material matters

Result: The wiki contains your decisions and reasoning; WebSnips contains the external material that informed those decisions.

---

Worked Example: Side Project Wiki for a Newsletter Tool

The scenario: An indie developer is building a tool that helps newsletter writers organize their research before each issue. She's been working on it for 8 months on weekends, has 43 paying customers, and works on it 4-8 hours per week.

Wiki structure (after 8 months):

Overview page (updated before every session ends):

• "Current status: Beta, 43 paying customers, $387/month MRR"
• "What I'm working on now: Refactoring the Collection import to fix the rate-limit bug from issue #47. Was in the middle of the webhook handler when I stopped."

Decision Log highlights:

• "Dec 2025: Chose Postgres over MongoDB — decision recorded with full reasoning. Key factor: relational joins for user-to-collection queries; NoSQL would complicate queries I do constantly."
• "Feb 2026: Chose Stripe over LemonSqueezy — logged with comparison. Decided: LemonSqueezy handles VAT automatically, which matters for my EU customers."
• "April 2026: Decided NOT to build email marketing integration — logged. The scope would double development time for a feature 3 of 43 customers asked for."

Technical reference:

• Local setup: 12-step documented process with all "known issues" documented (specific Node version conflicts, the environment variable for the webhook test URL)
• Deployment: 7-step deploy process with post-deploy checklist
• Architecture diagram: Simple 3-component diagram (frontend, API, database) with notes on the queue system

Research and learning notes:

• 8 problem-solution pairs from debugging sessions
• 3 failed experiment notes (attempted Vercel serverless, hit cold-start issues, switched to Fly.io)
• 12 useful resources linked with annotations

How the wiki helps:

When she returns after a 2-week break:

1. Read overview page: 2 minutes, fully reoriented
2. Open the "Current focus" note: knows exactly where she left off in the codebase
3. First line of code within 5 minutes of sitting down

Without the wiki, re-orientation took 45-75 minutes and she frequently re-researched decisions she'd already made.

---

Key Takeaways

1. The overview page with "what I'm working on now" is the highest-ROI wiki page: updating it before every session ends converts the next session's 45-minute re-orientation into a 2-minute one.
2. The decision log is the most commonly skipped and most valuable section: future you will thank present you for documenting why you chose Postgres, why you didn't integrate with Zapier, and why you sunset that feature.
3. Document known issues in the setup guide, not just the happy path: the things that "just work" don't need documentation; the things that always break do.
4. Problem-solution pairs are cheap to write and expensive to not have: 3 sentences at the time of solving saves 45 minutes of re-research 8 months later.
5. WebSnips captures the external research; the wiki captures your conclusions from it: the two-layer approach keeps the wiki clean (your thinking) and the research organized (the sources).

---

Conclusion

A side project wiki is the infrastructure that makes intermittent work sustainable. Without it, every session gap is a context loss that compounds: the project becomes harder to re-enter, decisions become harder to remember, and eventually the "maintenance mode" overhead of re-orientation crowds out actual building. A wiki with an accurate overview, a decision log, clear technical reference documentation, and notes on what you've learned converts the side project from a context-dependent activity into a documented system you can step into and out of without losing your place. The investment in documentation pays back in every future session — particularly the sessions that happen 6 months after you've been away.

Start your side project wiki with WebSnips as the research layer — capture the external resources and research that inform your project decisions, and build the organized knowledge base that makes intermittent work sustainable.