Don't Start From Scratch: Build Compounding Projects
Within the digital realm, everything you’ve ever built should be a resource you can tap into at any time. If it is, you’ll never reinvent the wheel, you’ll never repeat past mistakes, and you’ll ship 10-100x faster.
If you manage to actually finish a project in the first place (well done, you 1%-or-less crowd!), typically you’ll move on and start the next one from scratch. Somewhere along the way, the lessons you learned might disappear, or even your past work might itself get lost buried on an old hard drive or lost to a platform that doesn’t exist anymore. Unless you went out of your way to document your whole experience, whatever you figured out through painful trial and error is gone.
I’ve been thinking about this for a long time across the different projects I’ve been involved in, from Smash Bros. modding to Obsidian plugins to various website builds, I keep seeing the same patterns in the way projects relate to each other. I’ve distilled them down to three types: atomic projects, emergent projects, and compounding projects.
Atomic Projects
An atomic project is self-contained. Its scope is tightly defined: it solves one problem, and it works on its own.
Some examples from my own past and present work:
- A standalone tournament stage mod for Project M
- An Obsidian plugin like File Name History
- A single video in a broader “What If?” Smash Bros. YouTube series
The key quality of an atomic project is that it’s complete. It’s not a half-finished piece waiting for something external to function; it works, people can use it today.
But atomic projects become way more powerful when they connect to each other. For example, lots of tournament stage mods for Project M can be included in a build and become a stage list at a tournament. Or many individual Obsidian plugins can be combined into one opinionated Obsidian Vault. These are both examples of emergent projects.
Emergent Projects
An emergent project is what happens when atomic projects combine into something bigger. The whole becomes greater than the sum of its parts.
I’ve noticed two modes of emergence.
Organic Emergence
These arise bottom-up, without a predefined end-state. You’re solving problems, and at some point you look up and realize you’ve built a system.
Vault CMS is a good example. It started because I wanted Obsidian to work as a CMS for my personal site. Eventually I built Astro Composer to automate creating new posts, Bases CMS to use a grid view of my content, and it just kept going.
Plugin by plugin, the whole publishing ecosystem emerged. I didn’t have a master plan for Vault CMS when I started or anything, I just kept solving the next problem, and eventually there was a full CMS sitting in front of me.
Architected Emergence
These are top-down: you have a vision from the start, and you deliberately build a series of atomic projects to fulfill it.
Legacy TE was this kind of project. I wanted a premier, customizable tournament build for Project M, the premiere Super Smash Bros. Brawl game mod. The vision was clear from the beginning: a base build that was great on its own but easy for tournament organizers to make their own. Every atomic project my team built around it (1<1> stages, costumes, quality-of-life fixes) was in service of that vision. Other community members contributed their own atomic projects too, like costumes, stage mods, and external tools, and they all rolled up into the emergent whole.
Animelee m-ex was similar. Using Animelee, the aesthetic game modification for Super Smash Bros. Melee as a base, it combined stuff I made plus community contributions. For example, a set of HD assets, the m-exTool’s modular system, Uncle Punch’s dynamic stage loading, Professor Randall’s custom Animelee effects, a remastered HUD, new costumes, and even the base Animelee build itself. Each piece was useful on its own, but together they created the most complete, customizable Animelee experience available, even beyond the default version.
I made a video about atomic and emergent projects where I walked through these examples in more detail.
Compounding Projects
This is where things have really accelerated!
Compounding is different from emergence. Emergent is additive: parts combine into a whole. Compounding is multiplicative: each thing you build makes the next thing faster, cheaper, or more powerful because it inherits what already exists.
Compounding gets its power from three sources:
- Learnings: pitfalls you now know to avoid or breakthroughs you can repeat. These must be stored somewhere future-accessible.
- Base or template: infrastructure, code, conventions, or systems you’ve already built that the new project stands on top of.
- References: existing projects, atomic or emergent, that you can point to, draw from, or plug into.
Compounding Project Example: yeet.md
yeet.md is a markdown sharing tool I built just last week. Paste markdown, get a link. It has a split-pane editor with live preview, Obsidian-flavored markdown support, KaTeX math rendering, Mermaid diagrams, syntax highlighting, YouTube and X embeds, a browser extension, PDF export, Discord markdown support, and a print stylesheet.
I shipped the initial version in a single day. This is the initial demo video I created for it.
This is the result of a series of compounding projects. It was built on the backs of several other key atomic and emergent projects I’ve completed or am currently working on.
Here’s how each feature built on the last:
- Editor + live preview + share was built on Astro which I already knew well from building this website, Astro Modular, Axis, lilAgents’ website, and every single lilAgents’ clients’ websites.
- Obsidian callouts, highlights, KaTeX, mermaid all slot into the remark and rehype plugins I had developed specifically for each of my Vault CMS-optimized Astro themes.
- The browser extension took one afternoon because (1) the site already had a clean
/api/shareendpoint and a URL-based handoff, and (2) I had already created lilHelper so I had the source code available to reference as a base. - Discord markdown (timestamps, mentions, spoilers, underline, subtext) although technically new territory for me to work with - was able to drop it in as more marked extensions, slotting into the same rendering pipeline that already handled Obsidian syntax.
- Copy as Markdown, HTML, or rich text reused the same render pipeline with three different output formats.
- PDF generation piggybacked on the same render pipeline, just handing the HTML output to pdfmake.
- The print stylesheet was CSS only - zero new JavaScript. It reused the existing
.markdown-bodystyles.
Each feature compounded on the last. The infrastructure I built for the first feature became the foundation the eighth feature stood on. The tenth feature was faster than the first, not because I was cutting corners, but because I’d been building compounding infrastructure the whole time.
Vault CMS And Compounding Web Theme Projects
The yeet.md story played out in hours, but the Vault CMS arc plays out the same way across years.
It started with a simple desire: I wanted a free website with my own domain name, without ads. That got me from hacky Weebly tricks (using Google Optimize to hide their branding) to standard HTML on Netlify, to Hugo for blogging, and to eventually discovering Astro.
Once I was on Astro, I wanted to use Obsidian to write my posts. That’s what kicked off Vault CMS: a one-off fix to tag formatting, then one plugin to automate post creation, then another plugin to solve another problem, then another, and another, until the whole CMS emerged.
The Astro Modular theme was a direct product of that work. And Astro Modular, along with everything I’d learned building the current davidvkimball.com, made it possible to build Axis, my premium theme. Axis compounded on the learnings of both. What took weeks of figuring out the first time took days the second time.
Legacy TE: Compounding Across Communities
The compounding goes even deeper than a single person’s projects. Legacy TE was based on Project M, which was the culmination of the efforts of hundreds, if not thousands, of Brawl modders1. Every tool, every technique, every convention those modders established was infrastructure that Legacy TE inherited.
And it didn’t stop with Legacy TE; Project+ continued that compounding progression. The Cosmetic Standardization Project, which was a pipeline I spearheaded for rendering consistent costume portraits in Brawl mods using Blender, had its methods and approach influence how new character portraits (like the updated Samus costumes) were made for an update to Project+. An atomic project’s process compounded into the broader community’s workflow.
The power of compounding is that it doesn’t stop at one project’s boundary, it runs through communities and across generations of work - and can radically accelerate future projects.
Thinking in Systems
The pattern behind all of these examples is systems thinking. Maintain a mindset of structuring your work so that your past projects stay alive and useful.
Here’s what that looks like in practice:
- Structure projects to be portable. If your work is locked inside one platform or tool, it can’t compound into the next thing trivially that might be within a different platform or tool.
- Document your conventions and decisions. If you’re using an artificial intelligence tool as a partner, it can be as simple as asking it to do it for you - just make sure the key points and easy-to-miss details are stored somewhere.
- Keep your past work accessible. Store your projects somewhere you can actually search and reference.
- Build things that can be built upon. When you’re making a decision about how to structure something, ask: could a future project stand on top of this? Picking consistency over one-off hacks or sticking to clear conventions over undocumented “whatever works” solutions.
- Pay attention to what’s emerging. Sometimes the compounding is already happening and you just need to recognize it. Vault CMS was half-built before I realized it could be a proper standalone CMS! The sooner you see the pattern, the sooner you can be intentional about it and make something excellent that solves a real problem.
AI Makes This Absurd
To be clear, these principles predate artificial intelligence. Compounding projects were being built long before large language models existed - but AI magnifies the benefit of project compounding.
The bottleneck with compounding projects used to be slow extraction and re-use application: maybe you had the knowledge on-hand and the past work was there, but pulling the relevant pieces out and applying them to a new context was all manual. You had to remember what you built, extract the right resource, and re-apply your old work by mentally mapping it onto the new problem.
AI reduces that bottleneck substantially. I can point Claude at a repo and say “look at how I structured this” or give it a video transcript to a rough walkthrough video I made and say “follow these rules.” Most commonly, I tend to show it an existing project and say “build the next one like this, but with these changes.” The AI can read, understand, and act on the structure I’ve been building over decades.
Every convention I documented, every project I kept structured and accessible, and every decision I wrote down becomes something an AI can pick up and run with. The more intentional you were about building compounding infrastructure, the more AI multiplies that investment.
And it works in the other direction, too. AI can help you create the documentation and structure that makes future compounding possible! It’s a virtuous cycle.
Build Like Your Future Self is Watching
Your past projects should be resources you can tap into at any time. The way to make that happen isn’t wildly complicated, but it does require intentionality:
- Keep your projects structured and organized
- Document the decisions and the learnings, not just the code
- Use tools and formats that you control and can always access
- Think in systems, not isolated deliverables
Do this, and every project you take on benefits from every project you’ve completed before. Your body of work becomes a compounding asset, not a graveyard of stale digital relics.
I’ve been doing something like this across my side projects and my writing, and the momentum you gain from it is exhilarating. I can confidently say, as long as it’s in a somewhat similar realm, the next thing I build will be faster than the last. Not because I’m working faster necessarily, but because I’m able to more efficiently leverage anything I’ve made in the past.
Footnotes
-
Not to mention that Project M itself was a mod of Super Smash Bros. Brawl, a product published by Nintendo that built off of two previous titles. ↩