How I Built a Personal Knowledge Base for Myself
In this technical retrospective (2018), @stockkid shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Cloud & Mobile Era (2014–2019)
COMMUNITY SCORE 6 points
TOTAL DISCUSSIONS 2 comments
For one and a half year, I built and used a personal knowledge base that works in my terminal and a web browser. I have found some interesting things:
* if we go overboard, organizing, not learning, often becomes the goal in itself.
* searching is far more effective than organizing. My knowledge base became a buffer for my web search.
* a knowledge base needs to be local first and open source because learning is for life, and services and software come and go.
* we will never one day sit down and read our knowledge base.
* a personal knowledge base enables us to simply share a piece of knowledge with others. Doing so saves time when complex ideas need to be conveyed.
* adding ideas to a knowledge base is like committing to a source control, reducing my cognitive overhead.
Ultimately, having a personal repository of knowledge has helped me learn and save time.