Discovery Took Longer Than Development - What BMAD Taught Me

I self-published a dessert cookbook this year. It sells on Amazon, to people who already know about it. What it doesn't have is a home on the open web - the QR code on the back cover points to nothing, and Google searches for the title return nothing.

So I decided to build a landing page. And I decided to use BMAD to plan it.

I've seen the pattern before: someone opens Cursor, describes a website, and thirty minutes later has a working prototype with lorem ipsum, a stock hero image, and every design decision made by whatever the LLM thought "modern cookbook site" meant. It ships fast. It ships wrong. Two weeks of "just tweak this" turn into a rewrite.

I wanted to try the opposite: spend real time upfront, get the questions right, then build.

This post is what I learned from the before-you-code half of that experiment - the part I usually try to skip. A session here means one sitting at the keyboard, typically 45 to 90 minutes, not a single prompt.

One note before I start: this isn't a how-to with code in it. It's what six sessions of AI-assisted discovery actually looked like, including the parts that didn't go smoothly. If you're evaluating BMAD or a similar agentic planning workflow, this is for you - the build itself is a separate post, and I'll report back on whether the two-session estimate below actually holds.

What BMAD actually is

BMAD (Breakthrough Method for Agile AI-Driven Development) is a set of skills you plug into Claude Code, or any similar agentic environment. Instead of one general-purpose assistant, you get named agents: Mary does business analysis, John writes the PRD, Sally runs UX, Winston does architecture, Amelia implements stories. Each has a distinct persona, method, and output, and each pass writes into a shared working document - what BMAD calls the design spine - that later agents and reviewers read directly instead of starting from a blank context.

The trick isn't the personas - it's what they force you to do before they let you build anything. The UX pass won't render a mockup until it's asked about accessibility. The PM pass won't write a user story until you've argued out the target persona. The analyst won't stop asking "why" until you have a clean problem statement.

For most of my career, that upfront phase happened in a Confluence page nobody reads. With BMAD, it happens in a conversation, and produces artefacts I can actually feed to the next step.

Worth flagging early: the discovery half - analyst, PM, UX - doesn't require any development experience to run. You're having a structured conversation and reading what comes back, not writing code. A product owner, a founder sharpening a business idea before it's a project, or anyone who wants a rigorous brainstorming partner could run through Mary, John, and Sally's passes on their own. The architecture and implementation agents are where engineering knowledge becomes necessary - discovery itself is not gated behind it.

The prompts I didn't have in my head

I opened bmad-agent-analyst and typed something close to "I want a landing page for my cookbook." Mary, the business analyst, didn't build one. She asked who scans the QR code on the back of the book. And who else. And what happens if the site convinces them but Amazon is out of stock. And, uncomfortably, what my actual metric is: page visits, or books sold.

I hadn't thought about half of these - not because I'm careless, but because when you're the person writing the book, packing the boxes, running the ads, and trying to remember to eat lunch, strategic questions get pushed into "later."

The most useful thing an outside voice - human or model - does is ask the questions you don't ask yourself.

By the end of the analyst pass I had a written brief that said, plainly:

"The website has one job: convert warm QR-code traffic and title-search traffic into Amazon clicks. It is not a store. It is not a blog. It is not a discovery engine. Discovery is Amazon's job."

I've read many books about focus. Writing that sentence taught me more than any of them, because I had to defend it against Mary asking why for twenty minutes.

Personas that aren't marketing personas

Every "how to write personas" article I've read says to describe your target user's demographics and pain points. I always thought that was a bit much for a landing page.

The UX pass doesn't do that. Sally asked me to describe one specific person, in one specific moment, doing one specific thing with my site. Not "moms aged 25–45 who want healthy desserts" - a name, a scene, a time on the clock.

I ended up with Anna, 34, two kids, colleague of one of my first buyers. She's standing in the office kitchenette at 3:20 pm, book in her left hand, coffee in her right, three minutes before her next meeting. She scanned the QR code because she flipped through the recipes twenty minutes earlier and now she wants to know who made this before she orders her own copy.

Once Anna existed, every design decision had a real judge.

• Should the Amazon CTA be sticky? Would Anna, at second 42, find it without scrolling back up?
• Should the About section come before or after the book-preview teaser? Which answers Anna's question faster?
• Do we need a burger menu? Anna has three minutes. A menu is one more thing to close. The recommendation from the brief was already "no burger menu." But it was Anna who made it obvious.

Anna stayed the one persona the design was built for. What came next was a stress test, not a second persona: Elena, on the sofa Sunday night, has twenty minutes; Peter, googling a gift for his wife, has twenty-five seconds. Neither got their own design decisions - Anna's constraints were simply the tightest, so a page that worked for her worked for them too.

SEO and marketing decisions I would have skipped

When John, the product manager, walked me through the brief, we ended up talking about things I would have parked in "figure it out later":

• What goes in the <title> tag versus the <h1>.
• Whether the site publishes JSON-LD Book schema so Google can render a rich result.
• Whether I run Meta Pixel (no - it requires a cookie banner, which slows the page and disrupts the QR-scan moment).
• Whether I use Plausible or Umami for analytics (either works, both cookieless).
• Whether amazon_click is the single conversion metric, or if I also measure scroll depth (single metric - everything else is noise). None of these are technical decisions. They're strategic ones that shape the code - and they're exactly the decisions that get made implicitly if you skip discovery. You end up with Google Analytics because it's the default, then a cookie banner because Google Analytics needs one, then dropped Core Web Vitals because of the banner, then Anna bouncing before the hero even renders.

User journeys as a design ruler

Anna's journey isn't a nice-to-have. It's the thing every page decision gets checked against.

The UX pass wrote it down as a table with a seconds column. Second 0–2: page loads. Second 2–5: cover recognition. Second 25–45: the trust moment - Anna sees my kitchen photo, reads the origin story, decides she's real. Second 55–60: Amazon click.

Every homepage section maps to a second in that table. Every section that couldn't earn its place got cut. The About section isn't three paragraphs of biography - it's one photo, three sentences, a link, because Anna doesn't have time for more, and Elena has her own detail page to visit.

This is where I felt the biggest shift. In a normal project, I'd have written the homepage as "here are all the things I want to say." With Anna at my shoulder, I wrote it as "here is what needs to be true for her to click."

Ruthless. Kind of freeing.

Picking colors, fonts, and a layout without guesswork

Colors and typography are where the wheels usually come off with LLM-driven design. Ask for "warm and minimalist" and you get every warm-minimalist tailwind theme ever generated - a beige rectangle.

Here the UX pass's default behavior surprised me. Before making any decision, it rendered a self-contained HTML file with four theme variations side by side - color chips, token names, computed WCAG contrast ratios, and a small mockup using real content from my brand instead of lorem ipsum or stock photography: my actual book title, my origin-story sentence, the CTA copy I'd chosen. The palettes weren't invented, either - all four were built from colors pulled directly off the actual cover I'd uploaded, so every option already matched the book instead of just coordinating with it.

I clicked the one I wanted. No back-and-forth about hex values, no trying to describe "a rosé that isn't too pink but not too red." I saw the palettes, picked, moved on.

Same for typography. I named the fonts myself rather than having them guessed: Courgette for the wordmark and hero, Libre Baskerville for everything else. That wasn't arbitrary - both fonts are already used on the book cover and interior, so the website reads as the same object as the book, not a separate thing wearing its name.

The mockup itself followed the same logic. Once we had a palette and fonts, it was rendered as a single HTML file with an iPhone frame on the left and a MacBook frame on the right, both scrollable independently, both showing the same page, built from real assets: the cover from my print-PDF, my kitchen photo, three crops of an actual recipe spread.

Two things stand out here. First, seeing mobile and desktop at the same time - not "here's desktop, imagine mobile," but actual mobile, right there - is obvious in hindsight, but I'd never seen a design tool default to it. Second, testing every layout decision against real content, down to where my face gets cropped in a circular photo, catches problems that lorem ipsum simply hides.

Catching a trademark violation and a header conflict

At the end of the UX phase I ran the built-in Reviewer Gate - a set of agents that each re-read the finished design spine looking for a different class of problem.

The rubric walker (an agent that checks the brief's stated rules against the actual design for contradictions) found one real conflict: the SEO rule required the book title to appear in the <h1>, but the H1 I'd chosen was the sales tagline instead. We ended up with a two-line H1 - book title in Courgette script, tagline in italic serif below, one <h1> element in the DOM.

The same pass also got something wrong. The brief has a rule that the site shouldn't function like a store - no cart, no product listings, no checkout. The rubric walker misapplied that rule to a single button: it flagged the CTA text "View on Amazon" as violating it, treating the words themselves as store-like. But the rule was about what the site does, not what a link to a retailer is called. I had to explain the distinction and override the flag - about ten minutes I hadn't planned for. Worth knowing going in: not every flag is correct, and you still have to make the judgment call yourself.

The legal reviewer - because this site sits in a regulated food domain - walked every user-facing German string against the brief's red/yellow/green vocabulary list. No health-claims violations, but it flagged one thing I'd missed: a recipe name in the mockup referenced a registered brand, so it got renamed before launch. A rule that generalises to every future recipe with a brand name in it.

None of the real catches would have surfaced from a "does the design look good" review. It needed independent lenses looking for specific classes of failure - but it also needed me, reading each flag and deciding which ones were right. Every agent pass still produces text you have to actually read, line by line, not skim. The reviewers catch real mistakes, but only the classes of mistake they're built to look for, and they'll occasionally flag something that isn't actually wrong. You're still the one steering. What BMAD is reliably good at is naming constraints you forgot you had, and asking questions sharp enough that a bad answer becomes visible as a bad answer. That's real value. It's not the same as "it did the thinking for me."

Conclusion: discovery took longer than the actual page will

Here's the honest ratio. Discovery - brief, personas, UX design, mockups, parallel reviews, revisions - took about six sessions. The actual page, once I hand it to Winston and then Amelia, is estimated at two.

That looks backwards. The bet is that it isn't: with DESIGN.md and EXPERIENCE.md finished, an engineer shouldn't need to ask what color the CTA button is, guess whether the hero image loads eager or lazy, or invent an alt-text policy on the fly. It's all supposed to be decided, defensible, and - because a reviewer already went through it - consistent.

Discovery isn't overhead. It's the load-bearing structure of everything that comes after - or at least that's the claim this project is testing. BMAD didn't invent the idea; good product and UX practice has known it for decades, when it's done right. What BMAD did was force it onto a project at the size where I'd normally have skipped it, because "it's just a landing page, how hard can it be."

The real test isn't whether discovery felt thorough - it's whether the build actually takes two sessions like I'm expecting, or turns into five once real constraints show up in code. I'll follow up with the number either way.