Watch Me Build
What Users Asked For

Every one of these notes made sense. That’s the problem. Here is what each person asked for:

Someone wanted to bring their own key: many people already pay for a picture or video tool and want to use those credits here too. Totally fair. Someone missed TikTok. Someone wanted a screen that shows their strategy, and someone else wanted research into which posts go viral in their own niche. And one founder wanted two profiles, one per co-founder, each talking about different things in a different way.

I sorted them into three piles:

TikTok was a no-brainer, so I built it. The tone of voice per channel hit me the moment I heard it: of course, naturally. Big feature, built straight away. The rest went on the shelf, each for its own reason. The strategy screen is a strong idea, but I’m not sure it’s at the core of the product. Bringing your own key touches how I’ll make money, so it’s a pricing decision, not a weekend feature.

And one note, in red, stuck: model choice. When a model writes your content from your taste, you might not like the result, and a lot of that comes down to which model is writing. Some people prefer Anthropic’s Sonnet, some prefer OpenAI’s models, others like the quirkier tone of Grok. So why not let them choose?

When I get feedback from customers, I tell myself two things at once. First: I’m open to it. Second: this is the part I want to build. I’m solving a problem of my own, and I weigh that in.

I’m keen on feedback I hear again and again. But what I’m really looking for is feedback that resonates deeply with me. Just because you give people the chance to give feedback doesn’t mean you have to follow it.

My favorite example is World of Warcraft. I’m replaying the Classic version with Christina right now: the 25-year-old game, built without player feedback, with only the best quality-of-life changes added. Meanwhile the main version went in a direction nobody wants, because its developers listened too much to their players. It pulled them in every direction at once. They had something beautiful worth protecting.

You can listen to users, but you have to bring your own taste. That is the core of Zawq: the Persian word means cultivated taste, a sense of what’s good. And sometimes it takes a bit of confidence, maybe even arrogance, to say: this is what I think should be built.

Model choice won for exactly that reason. I built Zawq because the tools I tried didn’t let me pick the model. They put me in an expensive subscription, often a hundred euros or more, and then decided for me. I know why: it saves them money. It’s like a restaurant that won’t take cards because the fees are too high. Let me pay for it. If a user wants to spend more on a better model, or save with a faster one, that’s their choice, within limits. If you’re still deciding what to build, the your-idea chapter of the Builder Codex starts right there.

I’m not a developer. I use Claude Code for everything, and every project has one roadmap session that starts all the others. So I told it, out loud:

“I want to develop a new feature for which I want you to create a new sub-session. This feature should be called something like model choice, in which I first want to evaluate where in this app I want to give the user model choice and how I’m going to do this best, given our existing tech stack.”

The new session looked around first, and that matters: it read the code and our past decisions before suggesting anything. It found nine jobs in Zawq that call an AI model. Eight ran on one model, Sonnet; the pictures came from Google’s Nano Banana. It also found that some jobs should not follow a user’s choice: the ones that judge quality, like the check on a design, stay on a model Zawq picks.

Then it asked me questions, multiple choice, each with a recommended answer. Its recommendation was careful: start small, Claude only, the best model for testers only. Here is what it recommended, and what I decided:

I went with my own answer far more often than its recommendation. The session itself summed up what that meant: had I taken every recommendation, a user would see three levels today, Claude only, and only as a tester. No picture choice, no OpenAI, no privacy switch.

Some of those answers came from conviction. A dial with three levels, fast, standard and best, resonated immediately: the fastest and cheapest, a good balance, and quality without compromise. Others came from honesty. Bringing your own key affects how I make money, and I don’t know yet if I want it. So I asked for it to be built and switched off, ready for the day I decide.

The same goes for data. Every model call in Zawq promised to keep nothing. For content marketing, without personal data in the prompts, I relaxed that: wherever a model offers both, Zawq picks the one that keeps nothing, even if it costs about 10% more. Users who want the strict version get a switch that hides every model that keeps data. It limits their choice, and it’s their call.

And when I didn’t understand a question, I said so. One of my most frequent sentences to an agent is: “I don’t know. I don’t have enough context. Explain this to me further.” You don’t need to understand every implication to decide well. You need to know which decisions are yours. If you want your agent to ask better questions, it starts with the rules you give it.

Then I let it build. The recording runs over two hours, and my own part in it was small. Here is the afternoon on the recording’s clock:

While it worked, I set up an ad campaign for our next event. There is not much to do while the model is hustling, so do something useful.

The biggest time saver in my setup is one instruction: the agent clicks through everything itself before I click anything. It opened the app in the browser, created a test brand, wrote posts on each level, then checked the screens on an iPhone and an iPad, in English and German. I want everything to work on an iPhone and an iPad, horizontal and vertical, a normal laptop and a big screen. It costs tokens. I optimize for human time, not the agent’s.

It caught real things before I saw them. A label ran off the edge of an iPhone screen. A draft written by Opus could end up labeled as written by Haiku. It found that one in the database, wrote a test that failed on the old code, then fixed it. A code review before the release found six more issues. The worst: “Write again on Best” was meant for one draft, but for ten minutes it would have quietly run everything on the most expensive model. All six were fixed before the merge.

Then it handed me a test guide: it opened the right page and gave me a step-by-step plan. That’s my favorite part, because it also tells me what happened while I was busy elsewhere.

It worked. Every draft now says which model wrote it, and one click rewrites it on the best level. When I turned on the strict switch, the list showed only the models that keep nothing. I asked myself the question I always ask: is this okay as a first version? Yes. I asked for two small improvements I’d noticed while testing, then for the database change and the release.

One moment I want you to see. Before changing anything, the agent wanted to take a read-only look at the live database. I declined at the permission prompt. It stopped, didn’t try another way, and asked how to go on. Only after my explicit go did it apply the change. Its own lesson, in its words: “An agent that’s told no should stop and ask, never find a back door.” That brake is yours to use. More on that in zero trust.

Do I trust the tests an agent writes for itself? No. Have I seen reliability go up since it writes them? Yes. And it went up much more once it clicked through everything before me. The whole session took my usage from 8% to 15% on my Claude Max plan. Not a lot for a feature that is now live in Zawq for every team: open a brand, then AI models in the sidebar.

You have more features than you can build, from your users and from your own head. This is the whole process, in five steps:

Decide the things only you can decide: who gets it, who pays, what you’re willing to risk. Let the agent prove everything else to you before you look at it. And if you’re unsure which of your users’ wishes to follow, check what to improve first.

Better still, bring them along. On Wednesday, 4 November, Vibe Coding Cologne meets at STARTPLATZ, the same building as that Product Night. Bring what you’re building and your users’ post-its, and we’ll sort them together.