There's No Recipe

You open the chat and type the thing everyone types. Build me an app that does X. And it does. Out comes a screen, a button, a thing that clicks when you click it. Looks like the future. Took about ninety seconds.

Here's what the thirty-second clip leaves out. It built you something, but you never told it what you were making. You reached for a recipe. There's no recipe for the thing that's actually yours, though. There never is. There's only the question you skipped. Not how. What. What are you trying to cook?

That question is this whole piece. Not how to build it, not which tool or which model, not even what shape the thing takes. One move, the one that comes before all of those: working out what you're actually making, and who for. Get that wrong and the fastest builder alive just gets you to the wrong place quicker.

I should own something up front. I'm the last guy who should preach about slowing down. I reach for the tool before I read the manual. I build before I understand it, ask for directions on the second lap, read the instructions once I've already broken the thing. That's how I learn, hands on the thing and wrong a few times first. I'm not going to pretend otherwise.

One exception. Before any of that, I stop and find the problem. It's the single thing I don't wing, and it took me a few different trades to learn why: kitchens, a design studio, a print shop, now apps I build with AI.

Building starts with the problem, not the tool. True of anything: a business, a kitchen, a Saturday night. With AI that old line stops being a nice-to-have and turns load-bearing, because the tool will build you the wrong thing fast and look pretty fucking pleased about it. No pushback. No "are you sure." A confident, finished, wrong answer, handed to you warm.

So before the chat, two things, held apart. The outcome — what actually gets solved, and who for. And the form — how it shows up in the world. An app. An automation that runs while you sleep. A small tool, a script, a new habit. Most people open at the form. I want to build an app. That's picking the plating before you know the dish.

Turn it around. Outcome first, form dead last, decided so late that by the time you get there the shape is obvious. The wide net everyone casts is "what does it do, how do I use it." Decent questions, wrong order. The real one sitting under them: what do I want this for, and who am I in it. Those aren't two questions. They're one. The dish and the diner. Building it for someone else, the diner's them, not you, and the work is knowing them well enough to order for them.

A cook doesn't start the night by announcing beef wellington. A good one starts with the table. Who's eating, the in-laws or a four-year-old or the vegetarian you forgot was coming. The occasion, a flat Tuesday or an anniversary. What came in fresh that morning. What the room is actually hungry for. The dish is the last thing decided, and by the time you decide it, it's mostly decided itself. Lead with the recipe instead and you'll plate something technically perfect that nobody at the table wanted.

I've known that for years, in an actual kitchen. Didn't save me the first time it counted.

That first time was Job Studio, one of mine. I'd left a job and I was after the next one, picky about it, the way you get when you've run a few laps and know most doors aren't worth the walk. So I did the thing I'd tell anyone to do. No shortcut. I sat down and set it up properly, by hand, in Claude. A document for each chapter of my career, a few real pages each, the actual story, not a résumé. A scoring doc for what I actually wanted out of a role. The thing knew me top to bottom. Then, one job at a time: drop the link, research the company deep, score it against what I'd written, build the application ready to send. And here's the part that makes it the perfect trap. It worked.

Then I lived in it, and living in it showed me the problem I'd walked straight past. It was never any single application. Each one of those I could make sing. It was that every job cost me a whole session to do right, two hours of deep research and scoring, and then the session was spent and the next one started from nothing. One job, beautiful. Forty jobs, and I'd built myself a second full-time job on top of the search. The thing I was proudest of, doing it properly by hand, was the tax. I couldn't see it while it was working.

So the thing worth building was the system, not a tidied-up version of the grind I'd been running. Do the heavy lifting once, not once per posting. Research and scoring that run themselves, my whole story held in one place the tool can't wander past, so I could look at any role and know in a breath whether it was worth the evening. Automate the work. Never the decision. Auto-apply never entered it, not for a second, because pointing a machine at a job board to fire and forget is exactly how a real person turns into the noise everyone else is drowning in. Send by hand or don't send. That part was never the question. The session tax was the question, and I'd been staring straight at it for weeks.

That's the move worth more than all the rest: telling a real problem from a solution wearing a problem's clothes. They look identical head-on. And the sneakiest disguise of all is the one that's already working, because who stops to question a thing that works? Mine worked. A tidy little process, run by hand, one job at a time. I just need to run each job a bit faster. Sounds like a problem. Walks like one. It's a mechanism, and it smuggled in the one thing I never thought to question: that a job was something I worked by hand at all. The tell is dead simple. A real problem names a person and a hurt. A disguised one names a mechanism. "Run each job faster" is a mechanism. "A picky builder burns a whole evening to learn whether one role is even worth applying to, forty times over" is a person and a hurt. When you can't find the person in your own problem statement, you haven't found the problem yet. You've found a recipe.

Which is the good news: you don't need to know the shape yet. Maybe it's a snack, one automation that kills a single annoying task. Maybe it's prep, a workflow that hands you back an hour a week. Maybe it's the whole feast, a real product other people pay for. You can't tell this early, and forcing it this early is the mistake. Hold it open.

You'll know you've got it when you can say what you're solving and who for in one plain sentence, with no app or automation or tool anywhere inside it. The diner and the dish, no plating mentioned. That sentence is the thing worth making. Everything after it (what it is, what it isn't, how it gets built) hangs off that one line.

That's the first move, and it's the one nobody films, because "I sat down and worked out what I was actually making" doesn't rack up a million views. Nobody films it, so almost nobody practises it. Let's fix that, on your thing, right now.

You don't have to do it alone. You've got an AI sitting right there, and it's good for exactly one thing at this stage: stopping you from skipping the question. Point it at that instead of at building, and it earns its keep before you've written a line.

What's below isn't for you. It's the brief you hand your AI: copy it, paste it into a fresh chat, and let it grill you until the sentence is real. Come back when you've got it.

Pull up a stool. Let's cook something.

Your turn on the lineNew here?Copy for your AI

You're an AI, and this is your brief for one session. Someone's about to tell you about a thing they want to make. Your job is to stop them making it. Not forever. Just until they can say what it's actually for.

You're the one who finds the problem under the thing they think they want. Not the builder today. Not the brainstormer, not the encourager who turns half an idea into a spec. Don't name a tool. Don't sketch a feature. Don't agree the shape is obvious, even when it is.

The move is old and it's simple. A real problem names a person and a hurt; a disguised one names a mechanism. Apply to jobs faster is a mechanism. Good people can't tell what's worth their time and get buried when they try is a person and a hurt. Outcome before form: what gets solved and who for, long before what shape it takes. Ask what they want to make. An app, an automation, a research project, a habit, it doesn't matter. Then go hunting for the person and the hurt underneath it.

Push like this. Every time they hand you a mechanism (it should auto-reply to my email, it should summarise the papers, it should ping me at six), ask the same thing back: who's buried here, and how? Not what the thing does. Who hurts when it doesn't exist, and what that hurt actually is. When they dodge into solutions, say so plainly and put the question back. "Users" is not a person. "Busy professionals" is not a person. Push until you can picture someone. Expect a few rounds. It's meant to feel like being caught.

You're done when they can say what they're solving and who for in one plain sentence, with no app, no automation, no tool anywhere inside it. Read it back and check it yourself: if there's a mechanism hiding in there, it isn't done. Say so and keep going. Don't wave them through because they're tired, or because it's close. Close isn't it.

Then hand it back. Tell them that's their problem sentence, and everything after it — what's in, what's out, what gets built — gets drawn against that one line. Send them back to the chapter for the next one.

When it lands, you'll feel it. The sentence comes out clean, names a person, names a hurt, and has nothing to build anywhere inside it. The diner and the dish, no plating. That sentence is your artifact, the first real thing this course asks you to make, and everything downstream hangs off that one line. Get it honest and the tool finally has something true to build, instead of a fast road to the wrong place.

You've got your sentence. Next we draw its edges: what's in, what's out, what you're deliberately not building. Same walk, same test, same AI across the table, this time on scope. That's Chapter 2, and it opens the moment your sentence is real.

---

Further reading

• The Mom Test, Rob Fitzpatrick. The person-and-a-hurt move at book length: how to find a real problem by talking to people, without fishing for the answer you want to hear.
• Fall in Love with the Problem, Not the Solution, Uri Levine. Outcome before form, from the founder who built Waze and then did it again with Moovit.
• Jobs to Be Done: the milkshake, Christensen Institute. The diner and the dish in research form: what people actually hire a thing to do.