I used this photo on the Craigslist listing for my desk. I'd just returned from China and was moving to San Francisco, all in the same week.
2025 was a pivotal year for me. It was the year where the intellectual, professional, and personal aspects of my life fell into place. I hit my stride. Even my missteps played to my favor and informed my future decisions.
Early this year, I finished a project called TuneTree. TuneTree is basically Linktree mixed with Substack. The idea behind it is that musicians should have a hub to share their music and support their work through fan subscriptions. Tunetree did not pan out quite the way I imagined, but it was an incredible learning experience.
I wanted to take the "move fast and break things" philosophy to its logical extreme. One of the ways I practiced this was by writing no tests. The result was predictable as I grew progressively more fearful of my own code. Giant bugs lurked around every corner, and the only logical way to avoid regressions was to do less. I learned it is certainly possible to write too few tests, despite what the vibecoders on X would have you believe. I've also tried the 100% test coverage approach and found it too to be stifling. Turns out the ideal amount of tests depends on the situation, who knew?
It took me forever to get my app in front of my first user. I would write a "good-enough" version of a feature, revel in my genius, add a new feature, and rinse and repeat. The problem with doing things this way is that you get a giant ball of brittle features. I always expected to have to iterate on the features, but there are second-order issues when you don't build them robustly. Firstly, it takes a big toll on your ability to reason about your own codebase. I like to think my brain has a cache. When you are working on a feature, it takes time to populate the cache with your mental model of the problem. Mental models are evicted from the cache if they aren't recently used. If you half-ass a feature, you're necessarily delaying its completion. When you inevitably have to fix the bugs, your mental model has been evicted from the cache and you're going to waste time repopulating your mental cache. You're basically thrashing your cache. Secondly, it means it's going to take you forever to get an MVP out to users.
I fell victim to the fallacy of "if you build it they will come". I have a friend who is a musician and he has many musician friends. I worked it out with him where I would have TuneTree ready for him in time for his new album release. My thinking was that when he released his album, all his friends would see his page on TuneTree and want their own page. He released his album and then I waited patiently for the new signups to roll in. I ended up getting zero new signups after that.
I didn't test my code, I wrote a plethora of half-baked features, and I delayed marketing until the last possible moment. Each problem compounded the other problems. Although these mistakes caused me to lose motivation on the project, they taught me critical lessons which informed my future projects.
Taking what I learned from TuneTree, I spent some time working on various MVPs. Around this time, I met some cool internet people. @DefenderOfBasic introduced me to a project created by @exgenesis called The Community Archive. The community archive is an archive of X which is populated by user uploads. This has two major purposes. Firstly it is to replace the free Twitter APIs which were locked behind a paywall during the transition to X. Secondly, companies like Palantir and HFT firms are already conducting research into patterns of behavior of communities without our permission. This aims to turn that on its head, making the project opt in, and facilitating research in public. Check it out if you care about open-source research and data-sovreignty!
I joined the Community Archive discord server and had a bunch of fun brainstorming ideas. There were a ton of active users at the time, and many people would drop links to cool stuff happening in the world of online community research. I came up with the idea of building an app which would generate a newletter based on the links from the past week in the server. This would enable us to grow the community by sending out newsletters, and it would help me by giving me a "digest" of everyting that happened in the server in the past week.
I wanted to keep a human in the loop as much as possible. LLMs are still not good at filtering based on fuzzy human criteria such as "quality" or "relevance". The app would scrape the server for all of the links posted in the past week, and then present previews to the user. The user would then delete any low quality or irrelevant links. Once the user is happy with the collection of links, they could confirm and the app would scrape the contents of each of the links. The app would then take the content of each of the links, and a prompt describing the purpose of the newsletter and feed it to Gemini. This would produce some pretty high quality newsletters!
You can take a look at the project here. With some modification, you could probably get it working for any Discord server. It looked good and worked well. I took my experience with TuneTree and learned from my mistakes. I only spent about a month on the whole project, and I pushed out to users as soon as I could. The other members of the server seemed quite impressed. However there wasn't much interest in a Community Archive newletter outside the server, so nothing happened with it. Regardless I'm proud of my work, and it planted the seed for my current app.
My experience with the Community Archive exposed me to the concept of embeddings, and more specifically semantic vector search. Basically, words or sentences can be mapped onto a high-dimensional vector space which encodes the meaning. This can be used to compare the similarity between texts, which can also be used for search.
I've always been frustrated with most search solutions(excluding Google and kagi). In particular searching through my personal and work notes has always been a struggle. I know generally what I want, but I can't seem to get the right keyword to locate it. I needed a "vibe-search".
Additionally, I love using markdown for formatting my notes. But I haven't ever been particularly impressed with the existing options. Notion requires a subscription(so I can't use it at work), and uses Electron which makes the application resource-hungry. Obsidian is nice, but I prefer thoughtful and intentional design to customization, and Obsidian also uses Electron. Apple notes has been my go-to due to it's simplicity and ubiquity. But the search sucks, it has too many buttons, and it doesn't really support markdown.
I wanted a notes app which:
Naturally, I set out to build it myself.
I've spent the whole year working on it. I haven't released it to anyone but myself. You may be asking yourself:
Emmett, didn't you just tell us how you're a changed man, and how you're going to release your MVPs earlier so that you don't waste your time?
I did, but this is different. The reason it is important to release early is so you can get early feedback and work on the most important stuff, and also so you can stay motivated so that you don't abandon a ton of work. This time is different because I already have a user: myself! I've been using it as my daily driver for the past year, and I'm writing this blog post in it now! You don't need to worry about finding users if you always have a user(yourself). And you'll maintain your motivation to improve it because you don't want to use a bad product.
The notes app is not ready for prime-time quite yet. I hope to have it out to early users in the next few months. If you're interested in joining the alpha, shoot me an e-mail at firstname dot lastname at gmail. It only runs on Macs for now, unfortunately.
Next year, I hope to: