# The Solo Builder Blueprint — worked example **Fictional example.** Nadia, her business, the hosts she talks to, every conversation, price, count and date on this page are made up to show the method end to end. None of it describes a real person, client, sale or result. Version 2 · Last reviewed 9 November 2026 ## The starting point **Nadia (fictional), Lisbon.** She spent four years as an assistant to an interior designer, mostly sourcing furniture and preparing client boards. She has no business of her own yet. She has eight hours a week, a laptop, a free Claude account and a Google account. She has never written code. Her raw idea, in her words: "Something with AI and interiors. Maybe an app that designs rooms?" That's a tool, not a problem. So she starts with Stage 1. ## Stage 1 — Choose ### Her three problems - When a host is preparing a small apartment for short-term rental, they need it to look good in listing photos, but they don't know what to buy or where to put it. Today they copy saved photos or ask a friend. - When a young couple moves into a first flat, they need to furnish it on a budget, but they get overwhelmed by choice. Today they buy piece by piece and regret half of it. - When a small café redoes its interior, it needs a look that fits the brand, but designers quote for a full project. Today the owner decides alone. **Evidence (fictional notes):** two hosts she knows from her old job asked her for "a quick list of what to buy" in the past three months; one sent photos of a half-finished bedroom. The couple problem comes from her own move. The café is a hunch. ### Prompt 1 output (abridged) | Problem | Pain | Pay | Reach | Edge | Deliver | Total | Weakest link | |---|---|---|---|---|---|---|---| | Hosts preparing a listing | 2 | 1 | 1 | 2 | 2 | 8 | Pay: nobody has paid for this yet | | First-flat couples | 1 | 1 | 1 | 1 | 2 | 6 | No one asked her for help | | Café interiors | 1 | 1 | 0 | 1 | 1 | 4 | No evidence, no access | Each 2 for the hosts cites her notes: Pain ("asked for a quick list", "sent photos of a half-finished bedroom", so they've already tried to fix it), Edge (four years sourcing furniture) and Deliver (a plan she could write by hand next week). The two 1s are where the AI pushed back: - **Pay = 1, labelled "assumption".** "Hosts spend money on furnishing, so budget exists elsewhere. Nothing in your notes shows anyone paying for planning help or a workaround. Ask each host what they last paid for when setting up a listing." - **Reach = 1.** "You know two hosts. Your notes don't show how you'd reach twenty this week." That weakest link is why the validation conversations come next. They're the cheapest way to turn "assumption" into evidence, or into a reason to stop. **Buyer:** the owner of one to three short-term rental apartments who is preparing a new listing or refreshing a tired one, usually right after buying or inheriting a property or after a run of average reviews. **First question to ask:** "Tell me about the last time you got an apartment ready for guests. What did you do first?" ### Offer Card (Prompt 2, after one round of corrections; abridged: validation script and risks omitted) - **Offer name:** Listing-Ready Room Plan - **For:** hosts with 1-3 apartments preparing or refreshing a listing - **Outcome they want (their words, described, not promised):** "a quick list of what to buy" (two hosts, her notes) - **Promise:** a room-by-room plan you can buy and set up yourself, delivered within five working days of our call - **Deliverable:** styling plan for up to two rooms; shopping list within your stated budget, with links; layout sketch per room; photo shot list for the listing; 30-minute walkthrough call - **Scope out:** buying or installing anything; structural or renovation advice; managing the listing itself - **Format and timeline:** 20-minute intake call, photos and measurements by email, plan delivered as a shared document within five working days - **Price hypothesis (fictional):** €240 per apartment. Reasoning: one host was quoted a full design package she called "far over budget"; the others used free help that didn't finish the job; delivery takes her about four hours per apartment with AI drafting the documents - **Pilot:** €120 for the first three hosts, in exchange for honest feedback and permission to describe the work (no photos of the guest-facing space without written consent) - **Kill criteria after ten conversations:** fewer than three people describe a real recent instance; nobody asks the price or when she could start; three or more say a free checklist would be enough The first draft promised the plan would "help you get more bookings". Prompt 2's self-check removed it and listed it under "Removed:". Nadia controls the plan and the deadline, not the bookings. The outcome hosts want still sits on the card, in their words, so her page can speak to it without guaranteeing it. ### Validation debrief (Prompt 3, after five conversations) | Person | Last real instance? | Workaround | Already paying? | Reaction to offer | Signal | |---|---|---|---|---|---| | Person A | Yes: "last spring, studio flat" | Saved photos | No | "Nice idea" | Weak | | Person B | Yes: "listing goes live next month" | Friend helping | No | Asked the price and when she could start | Strong | | Person C | Yes: "after two reviews said it felt bare" | Bought decor online, returned half | Yes, returns and delivery | Asked if photos were included | Strong | | Person D | Yes: "new one-bed, empty" | Nothing yet | No | Sent photos unprompted | Strong | | Person E | No: sold the apartment | n/a | n/a | "Would have loved this" | None | **Patterns:** three of five care most about how the listing photographs, more than the décor itself; two asked about photos directly. Pay is still the weakest link: only Person C pays for a workaround today (returns and delivery), and nobody has paid for planning help yet. **Offer change:** move the photo shot list to the top of the deliverable and say so in the promise; update "Outcome they want" with Person C's words, "a listing that doesn't feel bare". **Kill criteria:** not met; not enough data (five of ten). **Verdict:** CHANGE, then continue to ten conversations. **Decision log:** "2026-10-13 — Promise now leads with the photo shot list. Reason: 3/5 conversations raised photos first." ## Stage 2 — Set up ### Folder ```text listing-ready/ PROJECT.md inputs/ 2026-10-12_validation-notes.md, 2026-10-13_writing-samples.md outputs/ drafts/ accepted/ reports/ 2026-W43.md run-log.csv ``` ### PROJECT.md (Prompt 4, excerpt) ```text # PROJECT ## Offer Listing-Ready Room Plan. Outcome they want (their words; describe, never guarantee): "a listing that doesn't feel bare", "what do I actually buy". Promise (what I control): a photo shot list and room-by-room plan for up to two rooms, delivered within five working days of our call. Scope out: buying, installing, renovation advice, managing the listing. Price hypothesis: EUR 240; pilot EUR 120 for 3 hosts (hypothesis). ## Buyer Owner of 1-3 short-term rental apartments, preparing or refreshing a listing. Trigger: new property, or reviews that mention the space. Words they use: "feels bare", "what do I actually buy", "for the photos". ## Voice - Short and practical. Do: "Send me two photos per room and I'll tell you what's missing." Don't: "Transform your space into a sanctuary." - One idea per sentence. ... ## Proof rules Can claim: four years assisting an interior designer (source: me). Never claim: client results, booking increases, reviews, "designer" title, numbers of clients. ## Known facts / Assumptions / Unknowns Fact: 3 of 5 hosts raised listing photos first (validation notes). Assumption: hosts will send usable photos and measurements. Unknown: whether EUR 240 is acceptable after the call. ... ``` The Voice section came from three of her own WhatsApp messages to past clients, pasted with names removed. Her first attempt used adjectives ("warm, elegant"); the reject-if list caught it. ### Staffing (Prompt 5) | Seat | v1 | Must deliver | Acceptance check | Reviewer | Level | |---|---|---|---|---|---| | Strategist | On | Offer Card, boundary | Kill criteria are countable | Me | Have | | Product & UX | On | Enquiry → call → pay → intake flow | Each step has one next action | AI reviewer | Learning | | Brand & Visual | On (light) | One colour, one font pair, photo style | Readable on phone | Me | Have | | Copy & Content | On | Page copy, reply templates | Every claim traces to PROJECT.md | AI reviewer + me | Have | | Frontend | On | One page in a no-code builder | Keyboard and 360px checks | Me | Learning | | Backend & Data | On (light) | Form, sheet, booking link, payment link | Minimum fields only | AI reviewer | Gap | | 3D & Motion | Off | — | — | — | — | | AI Features | Off | The product doesn't call AI; she uses AI to deliver | — | — | — | | Security & Privacy | On | Data map, privacy notice, consent for photos | Notice reviewed before live payments | Qualified person | Gap | | QA & Accessibility | On | Test plan for page and flow | Three dry-run cases recorded | Me + AI reviewer | Learning | | Launch & DevOps | On (light) | Builder subdomain, backup export | Page reachable, copy exported | Me | Learning | | Growth & Marketing | On | Distribution starter | Ten first-touch messages sent | Me | Learning | **Gaps:** Backend → simplify: booking tool plus a payment link, no custom code. Security → qualified review of the privacy notice and photo-consent wording before any live payment. **Build order:** Strategist → Copy → Product & UX → Brand → Frontend → Backend (light) → Security → QA → Launch → Growth. ## Stage 3 — Build v1 is three things: the plan template she'll fill for each pilot, the offer page, and the first-touch message. ### The Copy seat, first run (Prompt 7) The first run stopped instead of guessing: ```text OS-REPORT status: needs-input produced: restatement of deliverable and checks; no copy yet checks: not run decisions-needed: Should the page show the price, or only after the intake call? PROJECT.md has a hypothesis but no decision. next: Founder decides price visibility; then I write the page copy. ``` **Decision log:** "2026-10-14 — Show the pilot price on the page; full price stated as 'from the fourth host'. Reason: Person B asked the price first." Second run: ```text OS-REPORT status: done produced: outputs/drafts/2026-10-14_offer-page-copy_v1.md (hero, what you get, how it works, scope out, pilot terms, FAQ, form intro) checks: - every claim traces to PROJECT.md: pass (sources listed under each section) - states promise, deliverable, scope out, next step: pass (sections 1-4) - form asks only name, email, apartment size, listing date: pass (form intro section) - readable at 360px: not run (copy only, no layout yet) decisions-needed: Is "five working days" counted from the call or from receiving photos? next: Product & UX seat maps the enquiry-to-intake flow using this copy. ``` ### The reviewer catches one line (Prompt 8, fresh session) The QA lead found one unsupported claim in the FAQ: "Most hosts see a difference in their reviews." Nothing in `PROJECT.md` supports it. Fix: delete it and replace with what she controls: "You'll have a plan you can follow, and a shot list for your photographer or your phone." The sceptical buyer's first question was "What if my budget is tiny?", which became a new FAQ entry: the plan works to the budget the host states, and says what to skip first. The timing question went into the log: "five working days from receiving photos and measurements". ### Distribution starter (Prompt 9, abridged) - **Primary channel:** her own network of hosts from her old job, then local host communities she already belongs to. **Backup:** a simple profile on one platform where hosts ask for help. - **First-touch message (fictional):** "Hi, I saw your new one-bed listing went live in September. The bedroom photo has great light but it looks a little bare. I'm testing a room plan for hosts, focused on what to buy and how to shoot it. Would a 15-minute chat about how you set it up be useful? No pitch if not." - **Content seeds:** "The three things hosts buy first and return later" (from Person C's story, anonymised); "Why I start with the photo shot list, not the furniture"; "What I ask a host before I suggest anything". - **Weekly rhythm:** Monday and Thursday, 45 minutes each: ten messages, reply to everyone, log counts. All three v1 pieces passed their checks and are in `outputs/accepted/`. ## Stage 4 — Automate She handled her first three enquiries by hand before writing the recipe. She told Prompt 10 her AI access was "chat plan only" (her free Claude account has no API), so it kept the reply-draft step manual, along with the intake call and the plan itself. She follows the default no-code path: no automation tool, no AI step running on its own. ```text Page form (name, email, apartment size, listing date) → the form tool writes a sheet row: date, source, first name, size, listing date, status=new [automatic, free] → twice a day, Nadia pastes first name + need and the PROJECT.md sections into her Claude chat with the reply helper [manual] → she edits the draft and sends it from her own email [Nadia approves] → reply includes the 15-minute booking link → after the call: pilot payment link created in the payment provider's dashboard, test mode [Nadia approves] → she updates status by hand: replied / booked / paid / lost → no reply in 4 days: sheet highlights the row; she drafts the follow-up in her chat and sends it herself [Nadia approves] → paid: kickoff checklist (photo request, consent form, delivery date) ``` **Personal data:** name, email, apartment size, listing date. Stored in one sheet only she can access. Only first name and need ever go into the chat. Photos are requested after payment, with a consent line, and stored in one folder per host that is cleared after delivery plus 30 days. **Duplicates:** a sheet column flags any email seen in the previous 14 days as "repeat"; a repeat gets no new reply, she updates the existing row. **Limits:** two batches a day (9:00 and 17:00); nothing runs on its own, so there's no run cap or spending cap to set yet. **Manual stop:** set the form to stop accepting responses. **Rollback:** not needed; every step after logging is already manual. **What she deliberately didn't automate:** drafting. Prompt 10's COSTS section noted the upgrade path: an automation tool with an AI step, running on API access or the tool's AI credits (billed separately from any Claude plan), creating each reply as an email draft that she still sends herself. She logged it as "revisit when two batches a day stop being enough". ### Dry run (fictional enquiries, payment in test mode) | Case | Expected | Actual | Pass / fail | |---|---|---|---| | Ordinary enquiry | Row added; reply drafted in chat, approved, sent to her own test address | As expected | Pass | | Missing email | Row has no contact, no reply possible; she marks it "no contact" | As expected | Pass | | Duplicate within 14 days | Row flagged "repeat", no second reply | No flag; she nearly drafted a second reply | Fail | The repeat flag missed because the test enquiry was typed as ` Host@example.com` (leading space, capital H) and the formula compared raw text. Fix: a helper column that trims spaces and lowercases the email, and the repeat flag reads that column. Re-run: pass. The test-mode payment link was opened and completed with the payment provider's test card; the payment showed in the provider's dashboard and she set the row to `paid`. Live payments stay off until the privacy notice review is done. ```text OS-REPORT status: done produced: first-sale recipe v2 (manual drafting); dry-run table; fixed repeat-flag column checks: - ordinary enquiry: pass (row 2 logged; reply drafted in chat, approved, received at her test address) - missing email: pass (row 3 marked "no contact", no reply sent) - duplicate: pass after fix (row 4 flagged "repeat", no second reply) - payment in test mode: pass (test payment visible in the provider's dashboard; row 2 set to "paid") decisions-needed: Switch payments to live after the privacy review, or keep sending manual invoices for the three pilots? next: Book the privacy-notice review; keep payments in test mode. ``` ## Stage 5 — Improve ### Week 1 counts (fictional) | Count | Value | Measured or estimated | |---|---|---| | First-touch messages sent | 14 | Measured | | Replies | 6 | Measured | | Conversations held | 4 | Measured | | Offers made | 2 | Measured | | Pilots booked | 1 | Measured | | Pilots paid | 0 | Measured | ### Weekly review (Prompt 11, abridged) - **Shipped:** offer page copy v2, plan template v1, first-touch message v1, first-sale recipe v2 (all in `accepted/`). - **Stuck:** privacy-notice review, 3 days old. - **Check quality:** one report marked "readable at 360px: pass" with no evidence. Listed as unverified; she checked it on her phone and logged a screenshot. - **Kill criteria:** not met; 9 of 10 conversations so far across both weeks. - **Decision:** FIX. Two of four conversations stalled on "when could you start?", and neither the page nor the reply template gives a start date. - **Next iteration:** add "next available start: [date]" to the page and the reply template. Check: every reply draft for a week includes a start date. By: Friday. - **Decisions-needed:** keep the pilot price for the fourth host, or move to the full hypothesis? **Decision log:** "2026-10-20 — FIX: start date on page and replies. Reason: 2/4 conversations stalled on timing." ## What this example shows, and what it doesn't It shows the method: a tool idea turned into an observed problem, an offer tested in conversations before anything was built, a brief the AI could actually work from, seats run in order with checks, a reviewer catching an invented claim, a first-sale system dry-run in test mode, and a weekly decision based on counts. It doesn't show a real sale, real income or a real customer. Every number here is invented for teaching. Your counts will be your own, and "stop" is as valid a result as "keep". Back to the [guide](/blueprint/) · Next tool: [Offer Lab](/free/offer-lab/)