An executive coach who had never coded built an app that lets readers question

ACHIEVEMENTS **Where it started** When I began the AI Mastery course, I had never written a single line of code, and I had no idea of building an app in mind. It was by discovering the full potential of what one can do with artificial intelligence (AI) that the idea for this app came to me.   **The problem I set out to solve** As an Executive Coach, I am both an author and a reader of management books. People buy these books because they trust the author — but they rarely have the time to read 250 pages, and even after reading they struggle to find the one passage that answers a concrete, immediate situation ("I have to announce a difficult reorganization tomorrow"). Meanwhile, the publishing market is shrinking, and readers increasingly bring their management questions to generalist AI (ChatGPT, Claude), which answers from an average of the whole internet — with no identified source and a real risk of hallucination.   **What I built** I created "Ask Your Book" (working title): a live, working app that lets a reader ask a precise, real-life management question and receive an answer drawn exclusively from one identified, trusted book — quoted word for word, with its page reference, wrapped in a short conversational framing. It is a way to have a conversation with a specific author through their book, and it gives readers a second way into the content: read the book, and/or question it on the exact topic they need, right now. It also gives publishing houses a new way to reach their readers and sell books.   **Built on a real book, ready to pitch** I built the app on my own book, Overcoming Crisis — The Lobster Technique (AFNOR Éditions), so I could show it to my publishing house and negotiate the right to distribute the book this way myself, by acquiring its ePub format. To show how the model scales to a catalogue, I added the covers of other titles from the same collection. This is the MVP currently being pitched.   **The strategic and legal groundwork** Beyond the app itself, I have: mapped the offer against the market and its competitors (including a direct one, My Smart Book) through an ERRC / blue-ocean analysis; measured the real API cost per question (~US$0.27) to ground the business model in actual numbers; and prepared the commercial path — I have booked an appointment with an intellectual-property lawyer and plan to create a publishing subsidiary of my company, so I can also partner with self-published authors should my publishing house prove uninterested or too slow to decide.   **A second, further-stage prototype** I also built a separate personality quiz that lets a reader discover their leadership profile among the five "lobster" archetypes described in the book (Captain, Strategist, Connector, Structuring, Empathic), with an email capture that turns it into a lead-generation tool. It is deliberately kept outside the MVP. In a later version, combining this profile with "Ask Your Book" would let the app tailor each retrieved answer to the reader’s profile, making the book’s advice easier to apply.   **The result** A concrete demonstration that a reader can get a fast (an answer in seconds), faithful and fully sourced answer from a book they trust — behind a single shareable link, available in both French and English.   **Description of the app and flows in the app** The app is organised into five tabs: -         **Tab 1 — Library:** the reader finds their library. The first row, titled "My Books", shows the books they have already bought; below, the available books appear as small icons, including a "You may also like" row based on what they have already bought, with further suggestions underneath. Clicking a book cover opens that book’s page, which contains: an "About this book" link — opening the full table of contents and the book’s official information (ISBN, publisher, publication date, etc.); a button that leads to the "Ask this book a question" page; and the price of the service to purchase. This part still needs to be finalised. -         **Tab 2 — Current Book:** the reader finds the book itself in ePub format — that is, as on an e-reader such as a Kindle. -         **Tab 3 — Ask:** the reader can ask a question at any moment during reading, without having to go back through the Library tab. -         **Tab 4 — History:** the history of the answers to those questions. -         **Tab 5 — More:** additional sections about the app and the user’s account.   **Where I stand** I haven’t finished the app yet, it’s my first app and I need to finalise all the steps, I started it when Vishen did the lesson on the app and since then went to MVU so there was a pause. I probably have 1 more week of work to finalise the app design and functionalities.   **Next steps** -         Finalise the MVP (design and remaining bugs, etc) -         Meeting with the intellectual-property lawyer — set for September -         Market research on pricing (one-off price vs. monthly subscription) -         Finalise the business model, including the final cost-per-question figure once the engine has been fully tuned -         Meeting with my publishing house to present the POC — set for September   TOOLS - Claude Code (Anthropic) — the agentic coding environment used to build the entire project end-to-end (front-end, retrieval logic, test harness, documentation), driven in natural language. Model: Claude Fable and Claude Opus. - Claude Design — used to generate and compare several distinct colour directions for the interface, as a dedicated AI design step feeding into the visual identity. - Retrieval-Augmented Generation (RAG) — a retrieval pipeline restricted to a single closed corpus: the book's pre-press file (the "BAT", the final validated manuscript). No external data, ever. - Claude Artifacts — used to publish the working demo as a self-contained, shareable web page (a single link, openable on any phone). - HTML / CSS / vanilla JavaScript — the app itself: one self-contained file, no framework, real content (no placeholder text). - Git — version control used as a running logbook: a commit at every meaningful checkpoint. - Persistent memory files — structured notes that carry decisions, figures and constraints across working sessions, so nothing is lost between conversations. - Microsoft Word — used to review, annotate and rate the engine's answers batch by batch. - A custom evaluation harness — runs batches of real questions through the engine ("passes") and outputs the answers for human scoring of fidelity and relevance. - Vercel — planned deployment target for the production version.   METHODOLOGY 1. Framing before building. I started by writing a framing brief (the problem, the differentiating insight, the non-negotiable constraints), then ran a structured product-spec session (a PRD) to turn the idea into a build-ready specification before a single line of code.   2. Three non-negotiable constraints, fixed up front. Because the whole value proposition is trust in an identified source, I locked three rules the tool must never break: ·      exact quotations only — the book's text is returned word for word, with its page number; no paraphrasing (author's rights + fidelity to the authors' thinking); ·      no AI-invented coaching content — the tool retrieves and restitutes what the book says; it never improvises exercises or advice; ·      a closed corpus — retrieval never leaves the book. This is precisely the guarantee that answers a reader's fear of generic, source-less AI answers.   3. Real data, not mock-ups. I collected genuine managerial situations from managers (in everyday language, not the book's vocabulary), and built the app on my own book, Overcoming Crisis — The Lobster Technique (AFNOR Éditions). Covers of other titles from the same collection were added to show how the model scales to a catalogue.   4. Iterative testing loop. The engine was evaluated through successive "passes": a first batch of 40 real questions, then a refined batch, each answer read and scored in Word for fidelity (does the quote match the book exactly?) and targeting (does it find the right passage even when the question uses different words?). The engine was tuned between passes.   5. Economics measured, not guessed. I measured the real cost per question through the API (~US$0.27 per question) to ground the business model in actual numbers, and to size how many questions a subscription or one-off price must cover.    6. Positioning through market and competitive analysis, conducted with Claude. Using Claude, I researched the market and mapped the offer against competitors (including a direct one, My Smart Book) and built an ERRC / blue-ocean analysis to isolate what is genuinely differentiating — not the technology, but the format of the answer (a conversational, exact, sourced quotation) and the guarantee of a single trusted author. (See the ERRC grid attached.)   7. Design tested, then locked. The visual identity was built as real product screens, not throwaway mock-ups. Colours were actively tested: I used Claude Design to generate four distinct colour directions, and ran a parallel colour "test bench" of my own. The two independent approaches converged on the same palette — a vivid gold (#E8A317) and a forest green (#1E6B4A) — which gave me the confidence to lock it as a fixed charter, applied consistently across every screen so that book covers never fight the interface. 8. A disciplined AI-assisted working method. The project is run in themed sessions rather than one endless chat: decisions are written down as they are made (memory files + git commits), each session is announced and logged, and figures are always re-verified against the written record before being reused — a safeguard against acting on stale information. This is what makes "vibe coding" reliable over weeks: the durable state lives in what is written, never in the conversation.   9. Shipped a shareable demo. The result is a live, self-contained demonstration behind a single URL — fast (an answer in seconds where flipping through 250 pages would take tens of minutes), faithful, and conversational — used to pitch the publishing house and, if needed, self-published authors.   10. A second, complementary entry point: a personality-based quiz — not yet part of the MVP. Alongside the retrieval engine, I built a self-contained HTML/CSS/JavaScript quiz that lets a reader discover their leadership profile among the five "lobster" archetypes described in the book (Captain, Strategist, Connector, Structuring, Empathic). This is a prototyped, further-stage layer, kept separate from the Minimum Viable Product currently being pitched to the publishing house. The quiz is built from nine short situational questions about how someone instinctively reacts to a crisis; each of the four answer options carries a weighted score across all five profiles rather than mapping to a single one, since real behaviour rarely fits one archetype exactly. The reader's final profile is simply the one with the highest cumulative score once all nine answers are combined. The scoring was iteratively tested and rebalanced so that no profile is structurally harder to reach than the others, verified by exhaustively simulating every possible combination of answers.   11. Progressive reveal to build the email list. The result is designed in two layers: the profile name, a short description and the five capability scores appear immediately, while the profile's specific strengths, blind spots and a tailored self-coaching exercise are unlocked only once the reader leaves an email address. That address is captured through the Brevo API, together with the profile name as an attribute, turning the quiz into a lightweight lead-generation mechanism built on the same promise as the retrieval engine: one identified, trusted source, not a generic AI answer.   LEARNINGS ON VIBE CODING : - The biggest learning was about myself: I can build with AI even though I'm not a developer. At first I didn't dare open Claude Code — I have no technical background. But I started from something I knew intimately: my own need, as a reader and an author, for a service my publishing house doesn't offer yet. Starting from the need rather than the technology is what gave me the confidence to begin — and I discovered I could go much further than I thought. - You can build a real, working product without coding — by directing AI in plain language. I learned that "vibe coding" is a genuine skill: describing intent clearly, iterating, and letting AI agents do the implementation. The result is not a mock-up but a working demo. And to advance you need examples, don’t focus on perfection. - AI let me use professional tools I would never have touched alone. With Claude's help I got hands-on with more sophisticated environments than a chat assistant — GitHub for version control, Vercel for deployment — and learned to use them step by step. AI didn't just write code; it taught me the surrounding craft as I went. - Orchestrating several AI tools beats relying on one. I learned to pick the right AI for each job — Claude Code to build the app, Claude Design to explore colour directions — rather than expecting a single tool to do everything. - Framing before generating changes everything. A structured specification (a PRD) written before letting the AI produce anything gives dramatically better results than a prompt fired off in a hurry. Time spent framing is not lost time. - Constraining AI is what makes it trustworthy — this is the anti-hallucination lesson. I learned that grounding the model on a single, closed source (retrieval limited to one book) is precisely what eliminates hallucinations. The value isn't a smarter model; it's a tightly bounded, sourced one. - AI cannot be trusted blindly — it needs a human evaluation loop. Reading and scoring the tool's answers one by one, in successive test passes, was essential. I learned to treat AI output as something to verify, not to accept. - Managing the AI's memory and context is a skill in itself. the durable state must be written down, not left in the conversation. Working across many sessions, I learned that what must survive has to be written down (persistent notes, version-controlled logbook) — never left inside the conversation. My most concrete lesson: a figure measured in the morning, but never written to a persistent note, led to an evening calculation based on a wrong value. The fix was a disciplined method — persistent memory files, git commits at every checkpoint, themed sessions — so that what survives is always what is written, never the chat history. - I now understand the real cost of AI. Measuring the token/API cost of a single request changed how I think about the whole business model — AI is a real, quantifiable operating cost, not a free magic box. - Generic AI and sourced AI are not the same thing. I understood the difference between an answer averaged from the whole internet and one anchored in an identified, trusted source — and why that distinction is exactly what makes this project valuable. - Testing design directions, then locking them, prevents endless churn. Exploring several colour directions (with Claude Design and a parallel test bench) and seeing them converge gave the confidence to freeze the visual identity. Once locked, the charter stopped every later "what if we changed the colours" and let me focus on substance. ON THE PRODUCT AND ENTREPREUNEURSHIP: - The product is trust, not the technology. The retrieval technology is easy to reproduce — anyone in publishing could have the same idea. What is hard to copy, and what carries the value, is the promise: an answer that comes exclusively from one identified, already-trusted author, quoted word for word. I learned to pitch the source guarantee, not the "AI feature". The real short-term protection is speed to market, not the patent (which only secures a position already won). - Strict fidelity and a conversational feel are in tension — and both must be preserved. The hardest design problem was keeping the experience warm and conversational while never altering a single word of the book. The solution was to clearly separate two layers: an untouchable exact quotation, and a light conversational "wrapper" around it. Naming that boundary explicitly is what made the constraint workable. - You cannot trust the engine blindly — fidelity has to be measured. Building a human-in-the-loop evaluation harness (batches of real questions, answers read and scored one by one) was essential. It surfaced cases where the tool found the wrong passage or drifted from the exact text, which no amount of "it feels right" would have caught. - Real situations beat clever prompts. Testing with genuine managerial situations, phrased in everyday language rather than the book's vocabulary, was far more revealing than idealised test questions. The gap between how a manager describes a problem and how the book names it is exactly where the tool has to prove itself. - Ground the business model in measured numbers, not assumptions. Measuring the real cost per API question changed my thinking on pricing: at some price points, a generous question quota would actually lose money. The market analysis (what customers will pay) and the cost reality have to be reconciled before committing to one-off vs. subscription pricing. - And a market learning: while building, I found that similar AI-plus-publishing products already exist in less refined forms, launched 4 months ago — which confirmed there is a real, emerging market at the intersection of AI and book publishing, and that moving fast matters. - Scope discipline for a POC: show something that works, fast, to potential partners. Given that speed is the real moat compared to the evolution of the market, I deliberately favoured a working, demonstrable core over a complete-but-late product — a live demo behind a single shareable link that proves the concept in seconds.   RELEVANT URLS - Demonstration of the platform in French:   https://claude.ai/code/artifact/3c3a2c9b-a224-444d-9262-ad592e071bb7 - Copy of the demo in English for Mindvalley: https://claude.ai/code/artifact/d974a906-5dd9-48f9-8ba8-e8e7fe8cdda3 - Demonstration of the personality profile in English for MV : see html file in copy attached