Find your build

You made it to Week 3. The map is in your head. Now the question is what to actually do with it.

This week is about your build, specifically the thing you want to make, not the thing somebody else made. The seven lessons here are the practical sequence we wish someone had walked us through before we spent our weekends on builds that did not survive a Monday morning. We start with the most important and most-skipped step.

You probably have three or four ideas right now. By the end of today, you will have one.

The is-it-worth-your-100-hours filter

Building a thing, even a small one, takes meaningful time. Not necessarily a lot of hours by software-engineer standards, but a real number of weekends or evenings, plus a real number of mental cycles. Call it 100 hours in total, optimistically, for a small useful thing you can ship.

Three tests, applied in order, will tell you whether a given idea is worth those 100 hours. If an idea fails any of them, drop it (for now). If it passes all three, that is your idea for the rest of the course.

Test 1. Does this idea solve a problem someone (preferably you) actually has?

Not "could solve." Not "would be cool if it did." Actually does, today. The person can name the problem, can name what they currently do instead, and can name why what they currently do is annoying enough to consider switching.

If the answer is "people probably have this problem somewhere," your idea fails Test 1. You are imagining the problem. Pick a different idea.

If you specifically, today, have the problem, even better. Building things for yourself is the highest-leverage thing a non-engineer can do with AI, because you are simultaneously the builder, the user, and the test market.

Test 2. Can you describe the smallest useful version in one sentence?

Not the whole vision. The smallest version of the idea that would, on day one, actually be useful to someone (preferably you).

"A tool that helps PMs run better retros" is not a smallest useful version. It is a category.

"A single page where I paste my team's retro notes and it returns the three patterns I should bring up in the next 1:1" is a smallest useful version.

If you cannot describe the smallest useful version in one sentence, your idea fails Test 2. The vision is too vague to act on. Keep narrowing.

Test 3. Are you actually willing to be the first user?

Most builds die at this step and the builder does not notice. The build is shipped. Nobody uses it, including the builder. The builder shrugs. The build gets archived.

If the answer is "I would use this every week," your idea passes. If the answer is "I would use this if I were a different kind of person," your idea fails. Build for who you actually are, not who you wish you were.

Apply it to your three or four ideas, right now

Take five minutes. Write down your three or four ideas in one column. In a second column, mark each one pass or fail for each of the three tests. Most ideas will fail Test 1 or Test 3.

You should end up with one or maybe two ideas that pass all three. If you end up with zero, your ideas are not bad, they are early. Go talk to people about what is annoying them this week and come back tomorrow.

If you end up with two that pass, pick the smaller one. Smaller things ship. Smaller things teach you more, faster, about whether you have something. You can always do the bigger one later, and the small one will have taught you what to do differently when you do.

Why this is the most-skipped step in beginner builds

Almost every beginner build skips this step. They go straight from "I had an idea in the shower" to "what framework should I use," and four weekends later they have something that nobody (including them) actually uses.

The reason is that the building is fun and the filtering is not. Filtering forces you to admit that some of your ideas are not as good as the shower made them sound. Filtering is brutal in a way that opening Claude and asking it to scaffold a Next.js app is not.

Do the filter anyway. The fifty hours you would spend on a build that fails the filter are better spent on almost any other use of those hours, including a nap.

Forward references

Day 16 takes your one chosen idea and asks whether it should be a web app, a mobile app, or actually a script. Day 17 asks where AI specifically fits in your idea, which is a more interesting question than "should I use AI" (the answer to that one is yes). Day 18 is when you start sketching the stack for the specific thing you picked today.

Day 15 wrap

The thing you can now say plainly. Not every idea is worth your 100 hours. Three quick tests (real problem, smallest useful version, you would actually use it) filter most of them out before you waste a weekend.

The thing you can now do. Pick your one idea for the rest of this course, on purpose, and write down why it passed all three tests.

The guardrail to remember. Building is fun, filtering is not, and skipping the filter is how most beginner builds end up archived.

See you on Day 16, where we ask what shape your build should be.