Use-Case Workflows
How to create a wiki for a side project with a knowledge system — a practical guide for independent founders and builders to document their project's
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.
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.
For a solo side project, the wiki tool should be:
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.
WebSnips works alongside the wiki as the capture and research layer:
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.
[Project Name] Wiki
Each section starts as a single page and expands to sub-pages as the project grows.
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]
[One paragraph: what the product does, who it's for, what problem it solves]
[Where are we right now? What phase? Last deployed version?]
[The immediate current focus — what was I doing before I stopped?]
[What does "done" look like? What's the long-term vision?]
[Revenue, users, metrics that matter]
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 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.
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?]
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:
Decisions not worth logging:
The technical reference section answers "how do I [do this thing]?" without requiring investigation or debugging. For a solo project, this primarily documents:
A step-by-step guide to getting the project running on a new machine (or your machine after a year away):
git clone [repo-url][command].env.example to .env and fill in:
[VAR_1]: [where to find this][VAR_2]: [where to find this][command][command]
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
[Step-by-step deployment commands or process]
[How to undo a bad deploy]
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:
[Simple diagram or description of components]
[Any specific patterns used — event-driven, CQRS, specific caching approach — with brief explanation]
[Link to schema file or brief description of main tables/collections]
[Endpoint conventions, authentication approach, rate limiting]
---
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.
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.
WebSnips captures the external research that feeds into your wiki decisions. The workflow:
During a research session:
Result: The wiki contains your decisions and reasoning; WebSnips contains the external material that informed those decisions.
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):
Decision Log highlights:
Technical reference:
Research and learning notes:
How the wiki helps:
When she returns after a 2-week break:
Without the wiki, re-orientation took 45-75 minutes and she frequently re-researched decisions she'd already made.
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.
See also: The Ultimate Guide to Web Clipping.
More WebSnips articles that pair well with this topic.
How to build a teaching resource library with a knowledge system — a practical guide for teachers and educators to organize lesson materials, curate
How to organize sources for a documentary with a knowledge system — a practical guide for documentary filmmakers and journalists to manage research
How to analyze customer feedback with a knowledge system — a practical guide for product managers to collect, organize, tag, synthesize, and act on
How to assemble evidence for due diligence with a knowledge system — a practical guide for investors and acquirers to organize research, document
How to build a competitive landscape map with a knowledge system — a practical guide for product managers and founders to research, organize, and maintain
How to build a course with a knowledge system — a practical guide to organizing research, developing curriculum, managing content assets, and creating