For Your Next Side Project, Make a Browser Extension

One feature I found ridiculously useful was /follows, which would search tweets from people you follow. This let me treat Twitter as a personal search engine, where I could see opinions from people I trusted about any topic. This keyword was simply a shortcut for an existing Twitter search keyword, filter:follows—but saving the few extra keystrokes made a big difference in usability. personal search infrastructure

In hindsight, this manual distribution strategy turned out to be a great idea, because DMs were the perfect way to gather early feedback. The majority of early users actually sent meaningful feedback, and I suspect it’s because we already had a casual messaging channel opened when I originally sent the app. I also found that informal DMs were an efficient way of gathering feedback compared to calls or formal emails; I could easily keep conversations going with dozens of users without much overhead

Easy operations

I had a strict rule for this project: no operational stress. This meant no servers, and no data storage.

The tool was shipped as a purely client-side browser extension, using Twitter’s backend for search. I didn’t have my own user accounts; the extension would just send requests from the user’s browser using their authentication credentials.

I also avoided building any features that would require storing data on my end. Data is a liability; it requires careful handling to preserve privacy, and to avoid data loss. If I had built data storage features, I probably would have tried a local-first approach to avoid operational stress.

These rules made it far easier to keep the project running without investing much ongoing effort. Of course, these aren’t necessarily reasonable constraints for a larger or more serious project, but they worked for this one.

One feature I found ridiculously useful was /follows, which would search tweets from people you follow. This let me treat Twitter as a personal search engine, where I could see opinions from people I trusted about any topic. This keyword was simply a shortcut for an existing Twitter search keyword, filter:follows—but saving the few extra keystrokes made a big difference in usability.

In hindsight, this manual distribution strategy turned out to be a great idea, because DMs were the perfect way to gather early feedback. The majority of early users actually sent meaningful feedback, and I suspect it’s because we already had a casual messaging channel opened when I originally sent the app. I also found that informal DMs were an efficient way of gathering feedback compared to calls or formal emails; I could easily keep conversations going with dozens of users without much overhead

Easy operations

I had a strict rule for this project: no operational stress. This meant no servers, and no data storage.

The tool was shipped as a purely client-side browser extension, using Twitter’s backend for search. I didn’t have my own user accounts; the extension would just send requests from the user’s browser using their authentication credentials.

I also avoided building any features that would require storing data on my end. Data is a liability; it requires careful handling to preserve privacy, and to avoid data loss. If I had built data storage features, I probably would have tried a local-first approach to avoid operational stress.

These rules made it far easier to keep the project running without investing much ongoing effort. Of course, these aren’t necessarily reasonable constraints for a larger or more serious project, but they worked for this one.