How to build something small

Most people teach you how to build something big. But I think we should learn how to build something small.

Here are a few small things I’ve built. All of these were built as side projects for fun:

1. Frontend Slides (16k stars on GitHub): a skill that lets you create beautiful HTML slides with coding agents

2. Follow Builders (3.6k stars on GitHub): a skill that gives you a daily newsletter consisting of tweets and podcasts from a strictly curated list of AI builders

3. Tab Out (1.1k stars on GitHub): a Chrome extension that turns your New Tab page into a Mission Control where you can clearly see your open tabs and easily close them

Positioning is everything. Most products fail not because they were too narrow, but because they targeted too wide.

If you’re everything to everybody, you end up being nothing to nobody. You become a generic, bland thing that will be eaten by Claude.

Don’t take software too seriously.

Building software used to be a serious, utilitarian pursuit. People mostly did it to make money. This made sense when software was scarce and expensive.

But now that software is cheap and abundant, you can actually do it for fun. Vibe coding is basically my weekend hobby now, and some of my little skills feel more like art projects. We need to overcome the scarcity mindset for software. You’re totally allowed to build something useless.

Building something is also the best way to learn. In the traditional education system, you learned to build. In the AI era, this is now reversed: you build to learn.

Software is a form of self-expression. When you build a piece of software, you’re embedding a little piece of your soul in it: your unique way of thinking and doing something.

Now that AI can build anything really quickly, what makes people want to use your software, not somebody else’s?

Your product needs to have character. It needs to make people feel like “huh, I’ve never thought about it this way before, but it makes a lot of sense.” People will use it because the opinion behind it resonates with them.

If your product is just some generic, bland productivity tool, people may as well just use Claude.

Case in point: there are so many AI news fetching skills out there; my Follow Builders skill resonated with people because they liked the underlying philosophy of “follow builders, not influencers.”

Before AI, you couldn’t afford to build something small. Because the cost of software development was so high, you had to hire a team, convince other people, justify it to a committee.

Now, it’s literally just you and a coding agent. A coding agent doesn’t need to be convinced. It will readily build whatever crazy and weird idea you have. So go build something that would get rejected in every big tech company’s product review meeting.

A lot of people tell me “I have this pain point that I want to build a product for, but I’m worried it would be too niche.”

I want to tell them: sorry to break this to you, but you’re not as unique as you think you are.

Whatever super niche pain point you have, there are at least 10k people in the world who share the same pain point. Maybe not 10 million, but definitely 10k.

In the old world, a product with a 10k total addressable market was not worth building. In the new world, a product with a 10k user base is a very successful side project.

What you think might be an extremely niche need might not be as niche as you think. You just need to find those 10k people who are as weird as you.

For most of my projects, I actually didn’t start with the pain point. I started with the technology. Every day I browse X and bookmark cool new technologies and APIs that come out. Then I have a regular “playtime” where I just feed my coding agent these new technologies and we brainstorm what we can build with them. It’s a lot of fun.

Case in point: I built Tab Out because I first saw someone build something that reads their Chrome browsing history, and that’s how I found out your browsing history is saved locally in a database. So I brainstormed with Claude what we could do with it, and after lots of discussion and iteration, we ended up with a browser extension that helps you close your tabs.

Counterintuitively, it will often end up being cheaper than if you use a dumber model. With a dumber model, you end up not being able to do things correctly, and you spend more tokens and time fixing it.

I seldom start by giving a detailed product spec and asking my agent to execute. I just describe my problem extensively, and ask for my agent’s opinion. We bounce ideas off each other and come up with the solution together. It’s a co-creation process.

Bring the problem, not the solution.

Have an unreasonably high standard. Keep pushing the agent to its limits. Try crazy ideas and see what it does. You can’t usually get away with this when working with humans, so make the most of it.

LLMs are very good at adding things, but not very good at subtracting things. They often end up adding unnecessary features that look plausible at first but turn out to be useless in practice. As humans, your most important job is to subtract, simplify, and cut.

Build something small and elegant. Software is a medium for storytelling. Go tell a great story.