I spent December 2025 running the AI Advent Challenge. It was a hit. Over 600 people signed up, and engagement remained high for all 25 days. I didn’t get there with a dev team. I got there with Lovable, some tweaks with Cursor, and a clear vision of what I wanted to build.
I took that momentum into the SheBuilds buildathon. That is where campaigndays.io was born. I built the core idea in the first 48 hours using Lovable. Then I spent the next four days playing with the architecture to create a multi-tenant event app.
Everything looked good. It felt like I had cracked the code on building fast. Then a fellow Substack creator sent me this:
“It’s hard to manage every single day. I need something async like your advent challenge, but I don’t know where to start. What should each day look like? How do I structure it? How do I make sure people come back?”
He wasn’t asking about features. He was asking about the system.
That is when I realized vibe coding had gotten me 60% of the way. The other 40% was invisible. It was the thinking behind notification logic, content reveals, and the mental load of a 30-day journey. These are product decisions that are hard to track when you are just prototyping in the moment, especially while I run DraftKit on the side.
Raghav and Ashwin were hitting a similar wall with Cashin, their sponsorship portal. Different product. Different user. Same wall. Speed without strategy just created technical debt.
The Speed Trap: Why Faster Doesn’t Mean Better
Here is what happens when you build fast without thinking. You build features because they sound good, not because they solve real friction.
I included customizable domains because other platforms have them. I added advanced analytics dashboards because it sounds powerful. I planned for multi-contributor content because the AI said it was possible.
The Substack creator using my app needed none of that. He needed specific answers. Can I load a template? Can payments just work? Can I see if people are actually engaged?
The gap between what I thought the product needed and what the user actually needed got bigger the faster I built.
Raghav Mehra and Ashwin Francis found the same alignment gaps with Cashin. Features that looked good on a checklist didn’t solve the actual friction their users faced.
We both needed something that would let us:
Validate our assumptions about what creators actually need.
Document our decisions so we don’t rebuild the same feature twice.
Kill 80% of what AI suggests is “nice to have.”
Move fast on what matters.
That is when they introduced me to BMAD.
The System That Replaced Our Vibes
By Raghav Mehra and Ashwin Francis
Everyone is “vibe coding” now. It is the thrill of writing a feature in plain English and having it come to life instantly. Code bases, UI elements, and documentation generated in seconds.
But vibe coding only takes you so far.
We hit the same wall Elena did. We were building Cashin, a prototype for a newsletter sponsorship portal. The idea was complex: creators needed a self-serve portal to manage inventory, booking slots, and creative assets.
Vibe coding got us the prototype. But to make it monetizable and scalable, we needed to integrate payments, data storage, and backlog management without losing the thread. We needed to ensure that when we added a feature in the front end, it didn’t break the logic in the back end.
That is why we built BMAD (Breakthrough Method of Agile Development).
It’s Not a Methodology, It’s a Squad
Forget the corporate theory. BMAD is just a way to run a high-performance product team inside your AI chat window. It establishes distinct roles that force you to think before you build:
Mary (The Analyst): She checks if the market actually wants this.
John (The PM): He defines what we build (and what we kill).
Winston (The Architect): He decides how we build it.
Here is exactly how we used this squad to build Cashin prototype—and why it is the blueprint Elena is now using for campaigndays.io.
Phase 1: Mary Finds the Problem
For Cashin, we started with a vague idea: “Make sponsorships easier.”
If we had vibe-coded this, we would have just built a booking form. Instead, we fed Mary (our Analyst agent) context about the current state of newsletter sponsorships.
Mary’s Insight: Sponsorships are an operational “Wild West.” Creators struggle with fragmented email threads and spreadsheets, leading to revenue leakage and double-booking risks.
The Shift: We weren’t just building a booking form anymore. We were building a “workflow professionalization tool.” This insight changed our entire feature list.
Phase 2: John Defines the Solution
Next, we handed Mary’s research to John (our PM agent). His job was to turn “workflow tool” into a concrete set of requirements without feature creep.
John prioritized a dedicated self-serve portal where advertisers could view real-time inventory. But crucially, he identified a critical feature called “The Asset Jail.”
The Feature: An advertiser cannot book a slot without uploading valid assets (correct image size/word count) first.
The Logic: This prevents the back-and-forth emails that annoy creators.
A “vibe coder” might skip that validation to move fast. John ensured we built it in V1 because without it, the product fails its core promise of saving time.
Phase 3: Winston Builds the Blueprint
Finally, we brought in Winston (our Architect). We needed a tech stack that allowed us to maintain context over time, not just for one chat session.
Winston’s stack:
Gemini: For the heavy lifting of brainstorming and documentation (infinite context window).
Claude Code: For the implementation and file management.
Notion: As the “Persistent Context” repository.
By using Notion as a central brain, we ensured that every time we started a new coding session, the AI wasn’t guessing. It had the requirements (from John) and the market context (from Mary).
Why This Matters for campaigndays.io
We just walked through three phases of product development without writing a single line of final code.
Mary ensured we were solving the right problem (Revenue Leakage).
John ensured we had a lean feature list (Asset Jail).
Winston ensured our tech stack wouldn’t collapse (Persistent Context).
This is the “40% gap” Elena identified. Vibe coding skips these three people. It jumps straight to the developer.
By applying this same structure to campaigndays.io, Elena isn’t just getting a prototype. She is getting a product that has been stress-tested by an Analyst, scoped by a PM, and planned by an Architect—all before she opens Lovable.
The Toolkit: Run The Squad Yourself
You don’t need a complex CLI setup to start thinking like an architect. Here are the exact System Prompts we used to wake up Mary, John, and Winston.
Copy these into ChatGPT, Claude, or Gemini to simulate the squad on your next idea.
1. Mary (The Analyst) 👩🏼💻
“You are Mary, a Senior Business Analyst. Your goal is to kill bad ideas before we build them. I will give you a product concept. You will NOT generate features. You will generate a ‘Market Friction Report’ that analyzes: 1) Why this problem hasn’t been solved yet, 2) The operational ‘wild west’ currently solving it, and 3) Why a user would pay for a system instead of using a spreadsheet.”2. John (The Product Manager) 👨🏻💼
“You are John, a Ruthless Product Manager. Your goal is to prevent scope creep. Review Mary’s report and my feature list. Identify the ‘Vibe Coding’ features (things that look cool but add no value) and cut them. Then, identify the ONE feature that enforces a workflow (like the ‘Asset Jail’). Output a ‘V1 Spec’ that contains only the features required to solve the core friction.”3. Winston (The Architect) 👨🏻💻
“You are Winston, a Senior Technical Architect. Review John’s V1 Spec. Your goal is to ensure data integrity. Tell me: 1) How do we structure the database to support this workflow? 2) Where will the ‘Persistent Context’ live? 3) What is the risk of ‘vibe coding’ this in a prototype tool without a schema?”(Note: On Tuesday, I’ll be sharing the full technical breakdown, including the specific CLI commands and Notion templates for paid subscribers).
From Vibe Coding to Product Architecture
We started this article with a confession. Vibe coding feels great. It feels like magic. But magic doesn’t handle edge cases. Magic doesn’t manage database migrations. And magic definitely doesn’t help a creator managing a 30-day campaign without burning out.
The difference between a toy and a business isn’t the code. It is the decisions behind the code.
Raghav and Ashwin proved this with Cashin. Now, I am proving it with campaigndays.io. By using BMAD, I can switch contexts between this project and DraftKit without losing the thread. I don’t have to “reload” the context in my brain every time I switch tabs. The system holds the context for me.
The shift from “prompter” to “architect” is the most important leap a Product Manager can make in 2026.
It doesn’t mean you stop using AI. It means you stop letting AI lead.
You lead. The squad—Mary, John, and Winston—follows.
That is how we are building. And that is how we plan to win.
Thank you Elena for working cohesively with us to putting this together. It's been great learning from you and I am really looking forward to more such applications of PM theory in practice. Can't wait for our audiences to learn about the tech breakdown on Tuesday! 😊
Absolutely, Alena, the architecture relies on the objective and if you are building for public it always helps to outline what, why and how of the systems. Thank you for reading! 🤗