Why I Build One Small Thing Every Month (and What I Never Ship)

The short answer: a monthly deadline is the cheapest way I know to keep my design judgment honest. One small build a month forces me to take an idea from a vague itch to something another person can open and use, and to decide quickly what to leave out. Most of what I learn comes from that leaving out.

I'm a senior marketing designer, so building apps and AI tools isn't my day job. That's the point. Making things end to end keeps me close to the same questions I face in marketing work: who is this for, what's the one thing it needs to do, and what happens when a real person touches it.

Why monthly, and why small

Monthly is short enough that I can't hide in research and long enough to finish something real. A week tempts me to build a demo. A quarter tempts me to build a startup. A month sits in between, and it makes me choose.

Small matters just as much. A small build has a single job and a visible edge. When I look at the pieces on this site, like AutonautOS and Loopin Artist, the thing I care about is that someone can understand what each one is for without a long explanation. If I need a long explanation, the build is usually too big.

There's also a plainer reason. A portfolio of case studies tells you what I did inside a team. The monthly builds show what I do when nobody is handing me a brief. Both matter, and I try not to confuse them.

How I pick what to build

I don't keep a grand roadmap. Each month I look at the ideas I've jotted down and run them through a few questions. The idea that survives most of them gets the month.

1. Can I say it in one sentence? If the pitch needs an "and also," it's two projects. I pick one.
2. Is there a specific person who'd use it? "Creatives" isn't a person. A particular kind of designer with a particular annoying task is.
3. Does it teach me something about AI-driven creative? I want each build to leave me with a sharper opinion about what these tools are good and bad at.
4. Can I finish it in the month? If I can already see the part that will blow the schedule, I cut that part before I start.
5. Would I use it myself? If I wouldn't, I probably can't judge whether it's any good.

None of these are clever. Their value is that they're quick to apply and hard to argue with when I'm excited about a shiny idea.

Where projects get scrapped

Scrapping is part of the habit, not a failure of it. A few moments tend to kill a build, and I try to hit them early rather than late.

When the one-sentence version falls apart

Sometimes an idea sounds great in my head and turns mushy the moment I write it down. If I can't state who it's for and what it does after a bit of effort, I drop it. Better to lose an afternoon than a month.

When it's only a wrapper

If the whole project is a nice interface over an AI model with no point of view, no constraint and no decision I made, it isn't a product. It's a screenshot. I scrap those, or I keep going only if I can find the opinion that makes it mine.

When the polish is hiding the problem

As a designer, I can make almost anything look convincing. That's a risk. If I notice I'm spending the week on visual finish while the core thing still doesn't work, I stop and ask whether the idea deserved to exist in the first place.

What I never ship

• Anything I can't stand behind. If I wouldn't show it to a hiring manager or a founder and explain every choice, it stays off the site.
• Fake proof. I don't invent users, numbers or testimonials for a side build. A small build is a small build, and I say so.
• Half-finished things dressed up as finished. If it doesn't do its one job, it doesn't go out.
• Projects that only repeat a trend. If the sole reason to build it is that everyone else is, I skip it.
• Work that blurs what I did and what a team did. Builds are mine. Case studies are team efforts, and I try to say which parts were mine.

That last one is why I keep the builds separate from my client and in-house work. The ixigo email system, where click-through went from 4.2% to 18%, and the AI ad workflow that saves about seven hours per creative are results from real work with real constraints. The monthly builds are my lab. They inform how I work, but they don't borrow credit from those results.

What the habit does for my marketing design work

Shipping small things makes me a better collaborator. I understand what it costs to build what I've just designed, I'm quicker to cut scope, and I'm more honest about what an AI tool can and can't do in a creative workflow. That last part is the thing founders and teams exploring AI-driven creative seem most curious about.

It also keeps me a little humble. Every month I get reminded that the first version is rarely good and that finishing is its own skill.

What to do with this

If you're hiring for a senior marketing design role, look at the builds alongside the case studies and ask me about the choices behind them, especially what I cut. If you're a founder or team curious about AI-driven creative, tell me the one annoying task you'd want a small tool to handle. That's exactly the sort of sentence I look for when I pick the next month's build.