Howard learns Claude by building Markster
Six weeks, 15β20 hours a week, two tracks. On the technical track (weekdays) you build the real Markster product with Claude doing the heavy lifting, learning to give good instructions and challenge the answers. On the business track (Saturday mornings) you learn to analyze a business idea the way it's done at BONO β need-first, scored, with a verdict. By week 6: a working Markster app on a real URL, and a full business verdict on it β plus one on an idea of your own.
The one principle
You are not learning to code. You are learning to direct β the way a producer directs a film crew. Claude writes every line of code, sets up every account step by step, and explains every concept as many times as you want. Your job is to know what you want, say it completely, and never accept an answer you don't understand. That skill is the whole curriculum.
Two tracks, one plan
βοΈ Technical β how Claude works
Monday to Friday. Artifacts, Projects, Claude in Chrome, Claude Code, git, databases, deployment β learned by building Markster for real. Every task trains the same two muscles: complete prompts in, challenged answers out.
64 tasks Β· ~87h Β· the app ships in week 6.
π Business β how Markster wins
Saturday mornings, ~2.5h. The business-idea analysis method Bogdan built at BONO: reframe from product to need (Jobs to Be Done), talk to customers without polite lies (the Mom Test), score the problem and the market (Y Combinator, Sequoia, MIT), audit the unfair advantage, run the profit math and the Revenue Reality Check β and end with a scored verdict: GO / REFINE / PIVOT / PARK. You learn it on Markster; you graduate by running it on an idea of your own.
12 tasks Β· ~15h Β· the full method is in the Business tab.
π The PRD thread β from reader to co-author
A short third thread, on Fridays: the PRD (the product's source-of-truth document, readable in the PRD tab) slowly becomes partly yours. Week 1: question it (P01). Week 3: correct it with redlines from what building taught you (P02). Week 5: rewrite it as v2, with a changelog carrying your name (P03). Week 6: your version is the one Prodi receives.
3 tasks Β· ~2.5h Β· you propose, Bogdan approves β always.
π Start here
- Read the Markster tab β what we're building, for whom, and your role in it.
- Read the Question Playbook tab β the prompt recipe and the 12 questions you'll use every single day. You'll come back to this page constantly.
- Open The 6 Weeks to see the shape of the journey, then go to All Tasks and start with T00 β creating your Claude account, guided step by step. An hour later, T01 puts something you made on the screen.
- One more thing: anywhere in this plan, a dotted word is clickable β tap it for a plain-English definition and an example. The full list lives in the Vocabulary tab.
π How this plan runs in practice
- Where the plan lives: right now at hlb.bgn.ro, hosted by Bogdan. That page also holds your two downloads: the Markster PRD in English (you attach it in T02 and upload it to your Project in T03) and the plan as a text file (the version Claude reads best). Click each link once, and save both into a folder called Markster on your computer β everything you will ever attach comes from that folder. In week 6 you buy a domain of your own, move the plan there (T55), and publish your learning journal at a subdomain (T59).
- Your Claude can read all of this: in T03 you upload this plan and the PRD to your Markster Project's knowledge base β from then on, ask your Claude anything about any task, term, or prompt in here: "what does T28 want from me?", "explain this week's challenge again". You can also just give any Claude the hlb.bgn.ro link and ask it to read the plan.
- Ticking tasks: in weeks 1β3 you click the checkboxes in your tracker yourself (from week 3 it lives at hlb.bgn.ro/tracker β a real website, with Bogdan View one link away). From week 4 (T41), Claude Code can tick them for you through the tracker's own API β but only after you explicitly say so. That rule gets written into your project's rulebook, in your own hand.
- What you need: a computer with Chrome and a Claude subscription (Pro is fine to start; weeks 4β6 lean hard on Claude Code β if you hit usage limits, upgrading to Max fixes it). Every other account β Supabase, Vercel, Loom, your domain β gets created along the way, free or cheap, with Claude guiding every click and you typing every password.
βοΈ The daily ritual: one brave question
Every day, before your first task, ask Claude one question you'd be slightly embarrassed to ask a person. "What actually is a file?" "What's the difference between the internet and a browser?" "What does 'deploy' mean?" Claude has no eyebrows to raise. Ten minutes a day of brave questions, for 30 days, will do more for you than any course β because the questions you're embarrassed about are exactly the ones blocking you.
π ΏοΈ The word parking lot
New words will arrive faster than they can be explained β that's by design, not an accident. The rule: an unknown word never blocks a task. If it's dotted, click it for the one-line idea. If it still feels foggy, drop it into your parking lot β a running note called "Parking lot" in your Markster Project. You empty it twice a week: Wednesday's brave-question hour and Friday's review both start with "Claude, here's my parking lot β explain each word using something I built this week as the example." By then you'll have used each word for days, and the explanation lands ten times better than it would have on day one.
How the training wheels come off
The plan has three levels. The point of the whole plan is to move you from level 1 to level 3.
Prompts provided β and explained
Every task gives you the exact prompt to paste, plus a "Why this prompt works" note that takes the recipe apart. You're not just copying β you're studying the anatomy.
Fill in the blanks
You get the skeleton of the prompt; the [HIGHLIGHTED PARTS] are yours to write. The blanks are always the parts only a human can supply: intent, taste, priorities.
You write it yourself
Tasks give you a mission and a checklist of what your prompt must cover. A reference prompt is hidden behind a click β write yours first, then compare. The comparison is where the learning happens.
Challenge the answer
Every task ends with a π₯ Challenge β a specific question that pokes at Claude's answer. Claude is brilliant and confidently wrong sometimes. Spotting the difference is a skill, and you'll practice it daily until it's a reflex.
What you'll be able to do at the end
π¬ Write complete prompts
Context, goal, format, constraints β from scratch, without templates, for any task: writing, research, building, debugging.
π₯ Interrogate any answer
Ask for sources, assumptions, and confidence. Catch Claude when it's wrong, correct it without drama, and know when to verify at the source.
π¨ Build interfaces in Claude.ai
Artifacts, multi-screen prototypes, iterating without breaking what works. Your own tracker app with a real cloud backend.
π Research with Claude in Chrome
Competitor analysis and API documentation extracted by Claude driving your browser β with you as the skeptical supervisor.
β‘ Command Claude Code
Real files, git save-points, plan mode, project rules in CLAUDE.md. The difference between chatting with AI and directing a builder.
π Ship a real product
The Markster app β landing page, AI chat flow, pricing, dashboards, Supabase database β deployed to a public URL, plus your first custom skill.
A typical day (~3 hours)
- 10 min β the brave question ritual.
- 2 tasks β 1β2 hours each. Each task: do it, read the why, run the challenge.
- 5 min β tick the tasks off in your tracker app (you build it in week 1 and use it every day after).
When you're stuck: tell Claude you're stuck and paste exactly what you see β that's not cheating, that's the skill. If you're still stuck after 3 honest attempts, call Bogdan. Every Friday: a review call with Bogdan. From week 5: a short Loom demo to the team.
Markster: what we're building, and your part in it
π₯ Get the PRD now: this tab is the summary; the full document is markster-prd-en.md β click to download it, and save it in your Markster folder. You will attach it to a chat in T02 and upload it to your Project in T03. (If the link does not work where you are reading this, ask Bogdan to send you the file β it lives next to this page on hlb.bgn.ro.)
One-liner: Markster is an AI platform that registers an EU trademark for a small business in 15 minutes instead of 2β4 weeks with a lawyer β for β¬939 all-in (β¬89 service + β¬850 EUIPO fee), versus β¬1,500β3,000 the traditional way.
Who it's for
A founder or owner of a small EU business β SaaS, e-commerce, an agency β who just settled on a brand name and wants it protected fast, without lawyer drama.
Job to be done: "Register my trademark across the EU without paying β¬2,000 and without chasing a lawyer who doesn't answer email."
Why it can win
EUIPO (the EU trademark office) publishes free, complete APIs for searching, classifying, and filing trademarks β and almost nobody in the market uses them. Markster combines those APIs with a conversational AI. Cheaper, faster, and 10Γ friendlier than the alternatives.
~197,000 EU trademark applications per year, and growing.
How it works β the customer's journey
- Chat with the AI (3β5 min): name of the brand, what products/services it covers, logo or text-only.
- Availability check (automatic): EUIPO's search API returns similar existing marks; the AI scores the risk π’ clear / π‘ moderate / π΄ high.
- Classification (automatic): the AI suggests the right "Nice classes" (the official categories of goods and services); the customer confirms.
- Checkout & filing: β¬89 + β¬850 EUIPO fee β the application is filed through the EUIPO API, with a legal representative β and the team's lawyer is you, Howard.
- Dashboard: the application moves through 12 statuses (Draft β Filed β Published β Registeredβ¦), with an email at every step.
| Person | Role | What they mean for you |
|---|---|---|
| Isi | CEO / operations | Gets your Loom demos from week 5. The operator dashboard you build in week 5 is for her. |
| Bogdan | Product & strategy | Your reviewer and unblocker. Friday calls. Call after 3 stuck attempts. |
| Prodi | Professional developer | Takes what you build and hardens it for production. Your week-6 README is written for him. |
| Howard | Lawyer Β· coordinator Β· builder | Three hats. As the team's lawyer, you review what the AI flags β the expert queue you build in week 5 is literally your own future desk. As coordinator, you run the project. And through this plan, you build the whole working foundation: every screen, real data, EUIPO and payments mocked. |
What "mock" means β your most important vocabulary word
Some parts of your app will be mocks: realistic fakes. The EUIPO search returns invented results; the payment button pretends to charge a card. Mocks are not a lesser version of the work β they're how professionals build: prove the experience first, connect the real services after. Whenever you ask Claude to build something, saying "mock" vs "real" is one of the highest-leverage words in your prompt.
The stack (the technologies β Claude handles all of them)
Claude.ai for chat, artifacts and Projects Β· Claude in Chrome for research Β· Claude Code for building the real app Β· Supabase as the database (free tier) Β· Vercel to put the app on the web (free tier) Β· Stripe / EUIPO APIs β mocked. You will create the free accounts yourself (you own them); Claude guides every click.
The Markster PRD
Part 1 tells the whole idea in plain words β read it until it makes sense, then confirm or question each of the 14 decisions it's built on. Part 2 is the technical specification of the app you'll build; the plan sends you there when it's time. Dotted words are clickable, here as everywhere. And this document will become partly yours: you question it in week 1 (P01), redline it in week 3 (P02), and rewrite it as v2 in week 5 (P03) β with your name in the changelog.
π₯ Need the file? Download markster-prd-en.md β you attach it in T02 and upload it to your Project in T03.
Part 1 β The idea, in plain words
The person with the problem
Picture Maria. She runs a small online shop in Portugal selling handmade ceramics under the name TERRACOTA VIVA. The shop is finally working β repeat customers, an Instagram following, a wholesale deal in the making. And then a friend asks a question that ruins her week: "Is the name protected? What if someone registers it before you?"
Maria does what everyone does: she searches. She learns that to protect a brand across the EU you register a trademark β the legal claim on a name or logo, valid for 10 years. Then she hits the wall everyone hits:
- A specialized lawyer wants β¬1,500β3,000 and 2β4 weeks of back-and-forth emails.
- The official route β filing herself at EUIPO, the EU's trademark office β is free of middlemen but terrifying: legal terminology, 45 "classes" to choose from, forms that assume you already know the answers, and real money lost if you get it wrong (the office keeps the fee even when it rejects your application).
So Maria does what most small founders do: she postpones. And every month she postpones, the risk quietly grows.
There are roughly 197,000 EU trademark applications a year, growing every year, and about 60% come from small businesses like Maria's. Behind many of them β and behind the ones never filed β is this exact story.
What people do today
Three options, none good for Maria:
- The lawyer β safe but expensive and slow, and mostly performing a standardized procedure that doesn't need β¬2,000 of judgment.
- Do it yourself at EUIPO β cheap but intimidating; one wrong class choice or a "descriptive" name and the fee is gone.
- Online services (Trama and others) β cheaper than lawyers at ~β¬1,050 all-in, but still built like slow paperwork with a website in front.
The insight
Here's the part almost nobody knows: EUIPO publishes free, complete APIs β for searching existing trademarks, for choosing the right classes, even for filing the application itself. The official machinery is open. Practically nobody in the market uses it.
Combine that with what AI conversation is now capable of β asking a founder friendly questions and translating the answers into correct legal categories β and a different product becomes possible: not a cheaper lawyer, and not a form-filling helper, but a done-for-you service at a fraction of the price.
What Markster does
Markster registers Maria's trademark across the whole EU in about 15 minutes of her time, for β¬939 all-in β β¬850 of which is the official EUIPO fee that everyone pays, and β¬89 of which is Markster's service fee. Here's her experience, start to finish:
- She talks to the AI (3β5 minutes). Not forms β a conversation: what's the brand called, what do you sell, do you have a logo? The AI translates her plain answers into the official categories (the Nice classes) with the correctly worded list of goods and services.
- The availability check (30 seconds, free). Markster searches EUIPO's real database for identical or confusingly similar existing marks, and shows a traffic light: π’ clear path, π‘ moderate risk, π΄ high risk. If it's red, Markster says so plainly and suggests alternatives β even though that loses the sale.
- She reviews and pays (5 minutes). One summary screen: the mark, the classes, the itemized price. She pays β¬939, signs a power of attorney digitally (authorizing a licensed IP professional to file on her behalf), and she's done.
- Markster files and watches. The application goes to EUIPO through the official API. From here, everything is waiting β and Markster turns the waiting into transparency: the application moves through 12 clearly named stations (Filed, Published, Registeredβ¦), and Maria gets a plain-English email at every step. About 5β6 months later, if all goes well: "Your trademark is registered π" β protection for 10 years.
One safety mechanism runs underneath: the AI never files alone when it's unsure. Every application gets a confidence score; anything ambiguous is routed to a human expert who reviews it before money or filings move β and that expert is Howard, the team's lawyer. Confident cases flow straight through; doubtful ones land on his desk.
How the money works
- The customer pays β¬939 once: β¬850 passes straight through to EUIPO (their fee for one class; a second class adds β¬50, each further class β¬150), and β¬89 stays with Markster.
- The β¬89 must cover everything: the AI costs, payment processing, the lawyer's review time on flagged cases, support, and finding the customer in the first place. That's a thin margin β which is why the business only works if most customers arrive cheaply (word of mouth, content, partnerships) and most applications need no human touch.
- A gift from good timing: the EU's SME Fund reimburses small businesses 75% of the EUIPO fee (up to β¬700) in 2026. Markster tells every eligible customer how to claim it β effectively making the customer's true cost dramatically lower.
Who does what
| Role | Who | What they do |
|---|---|---|
| The customer | Founders like Maria | Talks to the AI, pays, signs, then just watches the dashboard |
| The machine | Markster's AI + EUIPO's APIs | Conversation, classification, search, filing, status tracking |
| Lawyer, coordinator β and builder | Howard | Three hats. As the team's lawyer, he reviews every application the AI flags β the expert review queue is literally his desk. As coordinator, he runs the project. And through this plan, he builds the entire product as a working foundation (EUIPO and payments mocked). The review screen he builds in week 5 is his own future workbench. |
| The Operator | Isi | Watches volume, revenue, and problems on an operations dashboard |
| Product owner | Bogdan | Owns this document; approves every change Howard proposes to it |
| Production developer | Prodi | Hardens the foundation for real customers, guided by Howard's README and PRD v2 |
What can go wrong (and what Markster does about it)
Honesty section β a trademark journey has real hazards, and the product's job is to handle them without hiding them:
- The name is taken or too similar β the traffic light says so before any money moves.
- Someone opposes the application during the 3-month public window β the customer is notified immediately and offered expert help (a separate service, not included in β¬89).
- EUIPO rejects it (for example, names that merely describe the product can't be trademarks) β the customer is told plainly why; the AI's job is to catch these before filing, which is exactly what the confidence check and expert review exist for.
The decisions to confirm
The idea above is built on a chain of decisions. Before you build any of it, go through them one by one β the same way this document's ancestors were built at BONO: decision by decision, each one confirmed or challenged. For each: if you're convinced, confirm it; if something bothers you, mark it with a question β your questions are exactly what Friday's review with Bogdan is for (and they're your P01 material).
Part 2 β How the app works (the technical specification)
This part describes what you will actually build. Come back to it throughout the plan β it's the reference for the screens (week 3 and 5), the state machine (week 5), and the architecture below.
The application's journey β the state machine
An application is always in exactly one of 12 states, and only certain moves between them are legal:
| # | Status | Description | From | To | Auto/Manual | Customer sees |
|---|---|---|---|---|---|---|
| 1 | Draft | Customer chats with the AI; the application is being assembled | β | AI Complete | Auto | "Preparing your application" |
| 2 | AI Complete | Application generated, self-check passed | Draft | Ready to Pay / Expert Review | Auto (confidence above threshold β straight on; below β review) | "Your application is ready" |
| 3 | Expert Review | Howard reviews (only AI-flagged cases) | AI Complete | Ready to Pay / Needs Info | Manual (Howard) | "Expert review" |
| 4 | Needs Info | Howard or the AI needs a clarification | Expert Review | AI Complete / Expert Review | Manual (customer answers) | "We need one clarification" |
| 5 | Ready to Pay | Validated; awaiting payment | AI Complete / Expert Review | Paid | Manual (customer pays) | "Pay and we file" |
| 6 | Paid | Payment received; awaiting signature | Ready to Pay | QES Signed | Manual (customer signs) | "Sign the power of attorney" |
| 7 | QES Signed | Power of attorney signed; preparing the filing | Paid | Filed | Auto (API filing) | "Filing your application" |
| 8 | Filed | Filed at EUIPO; awaiting publication | QES Signed | Published | Auto (~7 days) | "Filed at EUIPO" |
| 9 | Published | Published; 3-month opposition window | Filed | Registered / Opposition | Auto | "Published β opposition period" |
| 10 | Opposition | Someone opposed the application | Published | β (expert service upsell) | Manual | "Opposition received β we'll contact you" |
| 11 | Registered | Registered! Certificate issued | Published | β | Auto | "Your trademark is registered! π" |
| 12 | Rejected | EUIPO refused (absolute grounds) | Filed / Published | β | Auto | "The application was rejected" |
Rules: no going back from Paid to Draft (nothing changes after payment) Β· unpaid for 7 days β email reminder; 30 days β expires Β· opposition β notification + separate expert service offer Β· states 8β11 are driven by EUIPO's own progress, monitored via its API.
The AI conversation, step by step
- "Tell me about your brand" (2β3 min) β name (text or logo upload), what the business sells, which EU country, legal form. The AI derives: mark type (word vs figurative), recommended Nice classes, and the correctly worded goods/services list from EUIPO's harmonised database.
- "Checking availability" (30 sec) β search via the Trademark Search API for identical and similar marks in the chosen classes; similarity scoring produces π’ / π‘ / π΄ with plain-English explanation and, on red, alternatives.
- "Your application is ready" (1 min) β the summary: mark, type, classes with goods/services, the two required languages, applicant details, itemized price (β¬89 + β¬850, +β¬50 class 2, +β¬150 class 3+). Customer confirms or edits.
- The invisible self-check β before anything reaches payment: classes validated via the API, terms from the harmonised database, mark not descriptive/generic, applicant data complete. Confidence above the threshold (default 80%) β Ready to Pay; below β Expert Review.
The screens
| # | Screen | For | Its one job |
|---|---|---|---|
| 1 | Landing page | Visitor | Get one click on "Start your free check" |
| 2 | AI conversation | Customer | Turn a chat into a correct application |
| 3 | Summary & review | Customer | Full clarity before money: mark, classes, itemized price |
| 4 | Checkout | Customer | Pay β¬939 (mocked in your build) |
| 5 | QES signing | Customer | Sign the power of attorney, understanding what it is |
| 6 | Client dashboard | Customer | Always answer "where is my application, and what's next?" |
| 7 | Operator dashboard | The Operator (Isi) | All applications, filters, volume/revenue/flagged counts, alerts |
| 8 | Expert review queue | Howard (lawyer & coordinator) | Flagged applications with the flag reason; approve / needs-info / reject β the screen Howard builds for himself |
Every screen must answer, in every state: what is happening, and does the customer need to do anything? Empty states and error states are part of the specification, not decoration.
Configurable parameters
| Parameter | Default |
|---|---|
| Service fee | β¬89 |
| EUIPO fee: class 1 / class 2 / class 3+ | β¬850 / +β¬50 / +β¬150 per class |
| AI confidence threshold for expert review | 80% |
| Payment timeout | reminder at 7 days, expiry at 30 |
| Conversation language | any (AI matches the customer) |
| UI language | EN |
Communication
One email per state transition, in plain language, always with a next step: application ready β pay Β· payment reminder Β· payment received β sign Β· filed (with the EUIPO application number) Β· published (with the opposition end date) Β· registered π (with certificate number and 10-year expiry) Β· opposition received Β· rejected (with the reason) Β· expired Β· clarification needed Β· SME Fund guidance for eligible customers (how to claim the 75% reimbursement).
Success metrics
| Metric | Month 1 | Month 3 |
|---|---|---|
| AI conversations started / day | 50 | 200 |
| Applications completed / day | 5 | 20 |
| Applications paid / day | 2 | 10 |
| Visitor β conversation | >20% | >25% |
| Conversation β completed | >40% | >50% |
| Completed β paid | >30% | >40% |
| % escalated to expert review | <20% | <10% |
| Revenue | ~β¬5,000/mo | ~β¬25,000/mo |
Alerts: any step converting under 10% β investigate Β· expert queue over 10 β tune the AI threshold Β· opposition β immediate notification Β· EUIPO API down β manual fallback.
Integrations β real vs mocked in your build
| Service | Used for | In the real product | In Howard's build |
|---|---|---|---|
| EUIPO Trademark Search API | Availability check | P0, live | Mocked β invented mark database + similarity logic |
| EUIPO Goods & Services API | Nice classification | P0, live | Mocked β small curated class list |
| EUIPO Filing API | Filing the application | P0, live, via legal representative | Mocked β status simply advances |
| EUIPO Portfolio / Mailbox APIs | Status monitoring | P1, live | Mocked β Howard's queue and time drive transitions |
| Claude API | The AI conversation | P0, live | Scripted β the week-3 conversation script |
| Stripe | Payment | P0, live | Mocked β a pretend checkout |
| QES provider | Power-of-attorney signature | P0, live | Mocked β a pretend signing step |
| Supabase | Database | Live | Real β your applications live in a real database |
| Vercel | Hosting | Live | Real β your app is truly on the web |
Every mock is a documented gap: the gap list lives in the repo's docs and goes to Prodi with the README.
Architecture β how the pieces fit
Plain-language map of the system you build:
- The frontend β everything the user sees: the eight screens, running in the browser. Built as a web app, deployed on Vercel, reachable at a real URL. It holds no data of its own.
- The database (Supabase) β the single source of truth: one row per application, its status, its status history, the mock trademark database. The frontend reads and writes it through Supabase's API using the anon key, with access rules on the server side.
- The mock EUIPO module β a clearly separated corner of the code that pretends to be EUIPO: search, classification, filing, status progression. Separated on purpose: when Prodi replaces it with the real APIs, nothing else should need to change. This boundary is the most architecturally important decision in your build.
- The state machine β one module that owns the 12 statuses and the legal transitions; every screen and every mock consults it. Nothing changes a status except through it.
- What's deliberately absent in v1 β no login system (email + unique link instead), no real payment processing, no server of our own beyond what Supabase and Vercel provide. Each absence is a decision, not an accident.
- The seams for the real version β where Claude's API plugs into the chat, where Stripe replaces the mock checkout, where the QES provider replaces the pretend signature. Each seam is documented in the README.
What we deliberately do NOT build (v1)
Monitoring/watching services Β· opposition management (expert service instead) Β· WIPO/national trademarks Β· 3D/sound marks Β· customer accounts Β· automatic refunds Β· a mobile app Β· renewal reminders (marks last 10 years). The architecture leaves room for all of them; v1 builds none of them.
How this gets built β the six-week map
| Weeks | PRD parts involved |
|---|---|
| 1β2 | Part 1 (read, question β P01) Β· screen 1 (landing page) |
| 3 | Screens 2β3 as a clickable prototype Β· the traffic light Β· PRD redlines (P02) |
| 4 | The real app skeleton Β· screens 1β2 for real |
| 5 | The state machine Β· screens 3, 6, 7, 8 Β· Supabase Β· PRD v2 (P03) |
| 6 | Polish Β· deploy Β· the full journey end-to-end Β· handover to Prodi |
The Question Playbook
Everything in this plan practices two skills: writing complete prompts and challenging answers. Here is the whole theory, on one page. In week 6 you'll write your own version of this playbook β that's the graduation exam.
The prompt recipe
A complete prompt has four parts. Not every prompt needs all four written out β but when a result disappoints you, the fix is almost always one of these four being missing.
| Part | Answers the question | Example |
|---|---|---|
| Context | What does Claude need to know? | "I'm building Markster, a trademark registration site. Here's the PRD. I'm not technical β explain terms." |
| Goal | What exactly do I want, and why? | "A landing page whose only job is to get a visitor to click Start." |
| Format | What shape should the answer take? | "One HTML file. / A 10-row table. / Three options with trade-offs, then your recommendation." |
| Constraints | What must be true β or must NOT happen? | "Pink #E8386F, Inter font. Keep everything that already works. Don't use jargon. Under 200 words." |
The golden rule: every detail you leave out is a decision Claude makes for you. Sometimes that's fine β Claude decides well. But when the result isn't what you pictured, don't say "wrong" β ask yourself which of the four parts did I leave out?
The 12 questions that always work
Learn these the way you'd learn phrases in a foreign country. Each one is attached to a task in the plan, so you'll practice all of them.
- "What did you assume that I didn't tell you?" β reveals the invisible decisions.
- "What's the weakest part of your answer?" β Claude critiques itself surprisingly well, but only when asked.
- "Explain it simpler. Again." β repeat until it's actually clear. You are allowed to say "still not clear" five times.
- "What should I have asked you that I didn't?" β the question that finds the questions.
- "Give me 3 options with trade-offs, then recommend one." β turns Claude from an oracle into an advisor.
- "Before you do anything β what's your plan?" β for any big request. Approve the plan, then let it build.
- "What did you actually test, and what did you assume works?" β for every "done β ". Done is a claim, not a fact.
- "How confident are you, and what should I verify at the source?" β makes uncertainty visible. Numbers, dates, prices, laws: verify.
- "Explain what was wrong before you fix it." β if the explanation doesn't make sense, the fix probably doesn't either.
- "What did you change that I didn't ask you to change?" β after every edit to something that was working.
- "What could go wrong if I share / publish / delete this?" β before anything irreversible or public.
- "What would a skeptic say about this?" β for anything you're about to believe because you want it to be true.
The courage rules
No stupid questions exist here
Claude doesn't judge, doesn't sigh, doesn't remember you asked the same thing yesterday. The embarrassing question is always the most profitable one β it's the one that's been blocking you.
You can always start over
A conversation gone sideways costs nothing to abandon. Open a fresh chat, paste the last good version, ask for one thing. Starting over is a professional move, not a failure.
Being corrected is the product
When Claude corrects your understanding, you just learned something. When you correct Claude, you just practiced the most important skill in this plan. Both are wins; neither costs anything.
You are the supervisor
You never have to accept the first answer, approve a plan you don't understand, or keep up with a pace that's too fast. "Stop β explain that step first" is always allowed, forever.
Signs Claude might be wrong
- Specific numbers with no source β prices, dates, statistics, legal fees. Claude states them fluently even when unsure. Ask question #8.
- Too smooth β a perfectly confident answer to a genuinely hard question deserves question #2 or #12.
- Agrees with your pushback instantly β Claude sometimes folds under pressure even when it was right. If it concedes too easily, ask: "were you actually wrong, or just agreeing with me?"
- "Done β " on anything complex β ask question #7, then check yourself.
Six weeks, from first prompt to shipped app
Foundations & first wins
First artifact in 30 minutes. Read the PRD with Claude as your guide. Set up your Markster Project (Claude with memory). Build the tracker app v1 β an app with memory of its own. Learn the prompt recipe, practice being questioned, and catch Claude being wrong for the first time β on purpose.
π Business Saturday: the product-to-need reframe (Jobs to Be Done) and the Mom Test rules. You write Markster's job statement.
Prompt craft: landing page & research
Build the Markster landing page and make Claude its harshest critic. Set up Claude in Chrome and run real competitor research and an EUIPO API reconnaissance β then interrogate every source. Tracker v2 gets richer data and export. You start writing the key parts of every prompt.
π Business Saturday: the beachhead customer and the next-10-customers test, then a live Mom Test interview against Claude-as-customer.
The clickable prototype
A three-screen Markster prototype: landing β AI chat β summary, with the traffic-light risk check. Debug Day teaches you what to do when things break (they will, on schedule). Tracker v3 moves to the cloud with Supabase β your first real backend β and goes live at hlb.bgn.ro/tracker, your first published app. Cowork desktop gets installed.
π Business Saturday: scoring the problem with YC's six traits, picking Markster's Sequoia archetype, and answering "why now?" against a devil's advocate.
Claude Code: commanding a builder
The big shift: from chatting in a browser to directing an agent that creates real files on your computer. Install Claude Code, learn git save-points (so you can always undo β and therefore always dare), write your project's rulebook (CLAUDE.md), use plan mode, and scaffold the real Markster app with the landing page and chat screen inside. On Friday, you teach Claude to tick your own tracker through its API β with your confirmation as the only law.
π Business Saturday: the unfair advantage audit ("a bit better" scores zero) and the pre-mortem: how Markster dies, ranked.
Markster end-to-end
The app grows every screen from the PRD: summary & pricing, the 12-status state machine, client dashboard, mock EUIPO search, and the team's dashboards β Isi's operations view, and your own expert review queue. Supabase stores real application data. Friday is bug-hunt day, and your first Loom demo goes to Isi.
π Business Saturday: unit economics of one customer (the β¬89 question) and the Revenue Reality Check against the team's real targets.
Ship it
Polish pass, deploy to a real URL, and put down roots: buy your own domain, move this plan from Bogdan's site to yours, and publish your six weekly notes as a learning journal at learn.your-domain. Build your first custom skill (an email drafter for Markster's status notifications), write the handover README for Prodi, deliver the final demo, and write your own Question Playbook β the proof that the training wheels are off.
π Business Saturday: the verdict β Markster on the full scorecard, as a memo to Isi and Bogdan. Then the capstone: your own idea through the same machine.
| Week | Focus | New Claude capability | Markster deliverable | Hours |
|---|---|---|---|---|
| W1 | Foundations | Artifacts, Projects, prompt anatomy | Tracker v1 + knowledge base | ~17.5 |
| W2 | Landing page + research | Claude in Chrome, critique loops | LP v2 + verified research | ~16.5 |
| W3 | Prototype | Multi-screen artifacts, Supabase, debugging | 3-screen prototype + tracker cloud | ~18 |
| W4 | Claude Code | Files, git, CLAUDE.md, plan mode, APIs | Real app scaffolded | ~17 |
| W5 | Full build | Database, verification habits | All screens + Supabase | ~18 |
| W6 | Shipping | Deploy, own domain, skills, handover | Live URL + journal + skill + README | ~19 |
All 80 tasks
Two tracks in one list: weekday tasks are the βοΈ technical track; π Business tasks are the Saturday-morning business track (filter with the chips below). Click any task to open it. W1 gives you the prompt and explains it. W2β3 gives skeletons with [BLANKS] you fill in. W4β6 gives a mission and a checklist β write your prompt first, then peek at the reference. Every task ends with a π₯ challenge: run it, don't skip it.
How to analyze a business idea
This is the method Bogdan built at BONO for taking any idea from vague to verdict. The twelve Saturday tasks walk you through it on Markster; this page is the reference you come back to.
The philosophy: challenger, not validator
Most idea-analysis tools accept the idea as given and hand back a flattering report. This method does the opposite: it challenges the idea β starting with the one move that matters most: never start from the product; start from the need. "Who has a problem, and what is it?" If there's no need, the analysis finds that out fast, and that's a success, not a failure. Nine out of ten founders start from the product. The method exists to make you the tenth.
The six Saturdays
| Week | Question | Frameworks | Tasks |
|---|---|---|---|
| W1 | What's the need β and how do we talk to the people who have it? | Jobs to Be Done (Christensen) Β· Mom Test (Fitzpatrick) | B01βB02 |
| W2 | Who exactly is the customer β can we name 10? | Beachhead + DMU (Aulet/MIT) Β· Mom Test live | B03βB04 |
| W3 | Is the problem big, urgent, and well-timed? | 6 problem traits (YC) Β· PMF archetypes (Sequoia) Β· why-now | B05βB06 |
| W4 | Why do WE win β and how could we die? | 5 unfair advantages (YC) Β· pre-mortem Β· assumptions (Torres) | B07βB08 |
| W5 | Does the money work? | Unit economics, LTV β₯ 3ΓCAC (Aulet) Β· Revenue Reality Check (BGN) | B09βB10 |
| W6 | The verdict β and can you do it alone? | The full scorecard Β· GO/REFINE/PIVOT/PARK Β· your own idea | B11βB12 |
The scorecard
Five dimensions, 1β5 each. The score measures the quality of the thinking, not the size of the dream.
| Dimension | What it asks |
|---|---|
| A Β· Need | Is it clearly defined, with evidence? How painful? How frequent? |
| B Β· Customer | How specific? ("Everyone" scores 1.) Can you reach them β can you name 10? |
| C Β· Market | Big enough for the ambition? Growing? Timed right? |
| D Β· Differentiation | What do you know that others don't? Why are today's alternatives not enough? |
| E Β· Profit formula | Who pays, how much, how do you reach them? LTV β₯ 3Γ CAC? |
Deal-breakers β regardless of the total score, any of these means PARK: no identifiable need Β· the customer is "everyone" Β· no plan for how you reach customers.
The Revenue Reality Check
Accessible customers Γ conversion rate Γ price = year-1 revenue
Always bottom-up ("I can reach 2,000 founders through these channels"), never top-down ("just 1% of a huge market"). Then compare the estimate with the ambition: π Lifestyle (β¬50β300K/yr) Β· π Growth (β¬300Kβ3M) Β· π VC-scale (β¬3M+). Every category is valid β the check exists so ambition and math meet before launch, not after.
Reference conversion rates: cold outreach 1β3% Β· content/SEO 2β5% Β· warm referrals 10β25% Β· partnerships 15β30%.
The verdicts
| Verdict | Meaning | The action it demands |
|---|---|---|
| π’ GO | Strong opportunity | Validate for real: customer interviews, Mom Test questions ready. |
| π‘ REFINE | Potential, pieces missing | Fix the weakest dimension first, then re-score. |
| π PIVOT | The core is weak | Go back to the need and rebuild from there. |
| π΄ PARK | The opportunity isn't there | Say it out loud, keep the learning, spend the energy elsewhere. |
An analysis that doesn't end in an action β an experiment, a fix, a turn, or a stop β is decoration. Every verdict comes with its next step attached.
Vocabulary
Every technical term in this plan, in plain English, with an example. You don't need to study this page: everywhere in the plan, the first time a term appears in a section or task it's dotted like this β click it and the definition pops up right there. This page is the full list, for browsing and revisiting.
The rule that beats any glossary: if a word isn't here, or a definition doesn't land β ask your Claude. "What does X mean? Explain it simpler. Give me an example from Markster." That loop is better than any dictionary, and it's the whole point of this plan.
Success criteria & honest boundaries
β At the end of week 6, all of these are true
- Markster is live β a public URL anyone on the team can open, with the full customer journey working (EUIPO and payments mocked).
- Howard writes complete prompts unaided β context, goal, format, constraints β verified by the week 4β6 tasks done without the reference prompts.
- Challenging answers is a reflex β in the final demo, Howard can show three concrete moments where he caught or corrected Claude.
- The tracker app tells the story β used daily for six weeks, synced to the cloud, visible to Bogdan β and from week 4, ticked by Claude only on Howard's explicit confirmation.
- The plan and the journal live at Howard's own address β a domain he bought himself, the plan moved over from hlb.bgn.ro, and the six weekly notes published at learn.his-domain.
- One custom skill exists and works β the Markster email drafter, built and tested by Howard in Claude Code.
- Prodi can take over β the README honestly documents what's real, what's mock, and what he'd criticize.
- The personal Question Playbook is written β Howard's own top questions, each with a story from these six weeks attached.
- Howard can take a business idea from vague to verdict, alone β reframe to the need, customer, market, advantage, profit math, scorecard β proven by the B12 capstone on his own idea.
- PRD v2 lives in the repo β questioned in week 1, redlined in week 3, rewritten in week 5, with Howard as co-author in the changelog, and handed to Prodi as the source of truth.
- Two verdict memos exist β Markster on the full scorecard, delivered to Isi and Bogdan in plain language, and Howard's own idea, verdict accepted whatever it says.
Weekly checkpoints
- Every Friday: review call with Bogdan β demo, best prompt of the week, one thing Claude got wrong.
- Weeks 5β6: Loom demo to Isi & the team.
- Stuck rule: 3 honest attempts with Claude, then call Bogdan. Never lose a day to being stuck.
If the pace is wrong
The plan bends, it doesn't break. Any task can take two sessions instead of one. Supabase too much in week 3? Stay on localStorage and do it in week 5. A 6-week plan finishing in 8 weeks is a success; a plan abandoned in week 2 because it felt like a race is not. Adjusting is not failing β say it out loud on the Friday call and re-cut the plan.
π« Honest boundaries β what this plan is not
- Howard doesn't learn to write code by hand. He learns to read a little, and to direct a lot. That's the point, not a limitation.
- Nothing real gets filed at EUIPO and no real money moves. All legal and payment operations are mocked in the build β though the legal side is, fittingly, Howard's own profession: the real filing process will be his to coordinate. Prodi owns the production build.
- The app is a working foundation, not production software. Security hardening, real API contracts, and payment integration are Prodi's job, on top of Howard's foundation.
- Accounts and access stay in Howard's hands. He creates every account (Claude, Supabase, Vercel, GitHub) himself, with Claude guiding β passwords are typed by Howard, never by Claude.