Build What You Wish Existed: A Designer's Rule for Choosing Projects

Here is the rule I use: a side build only gets a month of my time if I wish it already existed and I would use it myself, even if nobody else ever did. Everything else goes on a list, not into a calendar. That one sentence has saved me from a lot of impressive-sounding ideas that I would have abandoned halfway.

The rest of this post is the filter behind the sentence: five questions, a way to size the commitment, and how I think about them when I look at my own small builds, [AutonautOS and Loopin Artist]. I will not walk through what each product does here. That is a separate story. This one is about the decision that comes before any pixels.

Why a rule at all

As a marketing designer, my day job is full of briefs where someone else defines the problem. Side builds are the opposite: nobody hands you a brief, nobody is waiting, and nobody will notice if you quietly stop. That freedom is exactly why they need a filter. Without one, the project that wins is the one that sounds best at dinner, not the one worth finishing.

A month is the unit I plan in because it is long enough to build something real and short enough that I can be wrong without it hurting. If an idea cannot justify a month, it is either too small to be interesting or too big to be a side build.

The five questions

1. Would I use it next week? Not someday, not if it were polished. If I cannot name the moment next week when I would reach for it, the wish is not real.
2. Does it sit on a problem I already feel in my own work? The best builds come from friction I have complained about more than once. Complaints are free research.
3. Can I get to something usable in the first week? If the first useful version needs everything to exist, I am planning a product, not a side build. I want a rough version I can actually try early.
4. Will building it teach me something my day job will not? A side build should stretch me. If I already know exactly how it will go, it is a chore.
5. Would I still be glad I built it if nobody ever saw it? This is the honesty check. If the only reason is how it will look in a portfolio, I will lose interest the moment it gets hard.

Notice that none of the questions ask whether the idea is original, trendy or likely to attract attention. Those are bad reasons to spend a month. Attention is a side effect of a project made for a real need, not a goal worth steering by.

Why "wish existed" beats "could be big"

When I build something I wish existed, I am both the first user and the toughest critic. I know within minutes whether it saves me effort or just looks clever. That feedback loop is the main advantage of a solo build, and it disappears the moment I start designing for an imagined audience.

It also keeps the scope honest. A tool built for a real, specific need tends to stay small because I can feel when a feature is not pulling its weight. A tool built for a hypothetical market tends to grow, because every imagined user wants something slightly different.

Running AutonautOS and Loopin Artist through the filter

Both sit on this site as small AI and app builds rather than client work, which makes them the right test cases: no brief pushed them forward, so the only thing that decides whether such a build gets a month is a filter like this one.

When I look at them now, I do not ask whether they are impressive. I ask the five questions in reverse. Would I have used each one the week it was done? Did each one start from friction in my own creative work? Was there a rough, usable version early? Did the build teach me something I could not have learned from a deck or a design file? And would I still be glad it exists if it had never been shown to anyone?

Try the same exercise with your own projects. Write the five questions down, answer them in a sentence each, and see which ones you hesitate on. The hesitation is the useful part. It usually points at the real reason an idea is not ready.

Sizing the month

Passing the filter earns an idea a slot, not a blank check. Before I start, I decide three things:

• What "usable" means. One sentence describing the smallest version I would actually use.
• What I am deliberately leaving out. A short list of tempting features I will not touch this month.
• What would make me stop. If a specific assumption turns out wrong, I want permission to walk away without guilt.

The stop condition matters most. A rule for choosing projects is only half useful without a rule for ending them. Walking away from a build that failed an honest test is a decision, not a failure, and it frees the next month for something better.

Where this overlaps with design work

The same instinct shows up in my professional work. When a workflow is painful enough that I keep wanting a better version of it, that is where a system or a tool is worth building. The AI ad workflow I work on is a good example of a payback worth chasing: it saves about seven hours per creative, which is the kind of return that makes the effort obvious. Side builds are where I practise spotting those moments, with nobody's budget on the line.

Your next step

Pick the idea you keep returning to. Write the five questions beneath it and answer each in one sentence, then define what "usable" would mean in a single week. If it passes, give it a month and a stop condition. If it does not, leave it on the list without guilt and pick the next one.

If you are hiring for a senior marketing design role, or you are a founder curious about AI-driven creative, this filter is how I choose what to build, and the builds on this site are the result. I am open to conversations, so get in touch if any of it sounds like the way you want your team to think.