Most MVP scoping processes are broken. A founder shows up with an idea—sometimes still in the brainstorming phase—the dev team writes a 40-page requirements document over three weeks, everyone signs off, and then halfway through build the team realizes they misunderstood the core domain. Weeks wasted. Budget burned. Trust eroded.
At Meld, we replaced that entire cycle with a single technique: Event Storming. In two days, we go from a fuzzy product idea to a clear, buildable architecture—with the founder in the room the entire time. No telephone game. No surprises.
Here's exactly how we do it, and why it works.
What Is Event Storming?
Event Storming is a workshop-based modeling technique invented by Alberto Brandolini in the early 2010s. It comes from the Domain-Driven Design (DDD) world, but you don't need to be a DDD practitioner to benefit from it. The core idea is deceptively simple:
Get the right people in a room, give them sticky notes, and have them map out everything that happens in the system as domain events—things that have already happened, written in past tense.
"Order Placed." "Payment Failed." "Flight Plan Approved." "User Invited to Workspace."
That's it. You start with events, and everything else—commands, aggregates, policies, read models—emerges from the conversation. The magic isn't in the sticky notes. It's in the shared understanding that forms when domain experts and engineers model reality together.
Why Traditional Scoping Fails
Traditional scoping follows a waterfall-ish pattern even in shops that claim to be agile:
- Week 1-2: Discovery calls, stakeholder interviews, competitor analysis
- Week 3-4: Requirements document, user stories, wireframes
- Week 5: Estimate, negotiate scope, sign contract
- Week 6+: Start building, immediately discover gaps
The problem isn't effort—it's translation loss. The founder explains their domain. A business analyst translates it into requirements. A designer translates requirements into wireframes. An engineer translates wireframes into architecture. At every hop, nuance evaporates.
By the time code gets written, the team is building a telephone-game version of the original vision. And the feedback loop to correct it is measured in weeks, not hours.
Event Storming collapses those hops to zero. The founder and the engineer are literally standing at the same wall, pointing at the same sticky notes, arguing about the same domain concepts in real time.
Meld's 2-Day Workshop Format
We've refined our Event Storming process into a tight two-day format that works exceptionally well for MVP scoping.
Day 1: Big Picture Event Storming
Goal: Map the entire domain at a high level. Identify boundaries and hotspots.
The session starts with a single prompt: "Tell me everything that happens in your system, from the moment a user first touches it to the moment they get value."
Everyone writes domain events on orange sticky notes and places them on a long paper timeline. We encourage chaos first—get everything on the wall, don't worry about order. Then we sort, group, and start asking hard questions.
Key activities on Day 1:
- Chaotic exploration: Everyone writes events simultaneously. Duplicates are fine. Contradictions are great—they surface misunderstandings early.
- Timeline ordering: We arrange events left-to-right chronologically. Gaps become obvious. "Wait, what happens between 'Flight Plan Submitted' and 'Flight Plan Approved'? Who reviews it?"
- Hotspot identification: We mark areas of confusion, disagreement, or complexity with pink "hotspot" stickies. These are the areas that will sink the project if left vague.
- Bounded context identification: Natural clusters emerge. The billing events group together. The flight planning events group together. The crew management events group together. These clusters become our first sketch of system boundaries.
By end of Day 1, we have a wall-sized map of the entire domain, marked with hotspots and rough boundaries. The founder can see their business reflected back as a system for the first time—and they always spot things they forgot to mention.
Day 2: Design-Level Event Storming
Goal: Zoom into the core bounded contexts and model them precisely enough to derive architecture.
Day 2 is where we go deep. We pick the 2-3 most critical bounded contexts (the ones that make or break the MVP) and model them at the design level using the full Event Storming vocabulary:
- Commands (blue stickies): Actions users or systems take. "Submit Flight Plan." "Approve Payment."
- Events (orange stickies): Things that happened as a result. "Flight Plan Submitted." "Payment Approved."
- Aggregates (yellow stickies): The domain objects that receive commands and emit events. "FlightPlan." "Subscription." "Workspace."
- Policies (lilac stickies): Reactive logic. "When Payment Failed, then Retry After 24 Hours." "When Flight Plan Submitted, then Notify Reviewer."
- Read Models (green stickies): The views and projections users need. "Dashboard showing active flight plans." "Billing history."
- External Systems (pink stickies): Third-party integrations. "Stripe." "FAA NOTAM API." "SendGrid."
This level of detail gives us everything we need to derive a technical architecture. Aggregates map to database models. Commands map to API endpoints or server actions. Policies map to background jobs or event handlers. Read models map to queries and UI screens.
From Sticky Notes to Architecture
The transition from Event Storm to architecture is remarkably direct:
- Bounded contexts become modules or services. For an MVP, these are usually modules within a monolith—not microservices. We're not over-engineering.
- Aggregates become Prisma models and the core domain logic around them.
- Commands become server actions with validation and authorization.
- Events become the backbone of async flows—whether that's simple function calls in a monolith or a message queue at scale.
- Policies become event handlers or background jobs.
- Read models become database queries optimized for specific UI views.
We document all of this in a concise architecture decision record (ADR) that travels with the project. No 40-page spec. Just a clear map from domain concepts to code structure.
Real Example: AeroCopilot
One of the clearest examples of Event Storming in action was our work on AeroCopilot, an AI-powered flight planning platform.
The flight planning domain is deceptively complex. A pilot doesn't just "create a flight plan." They check weather, review NOTAMs (Notices to Air Missions), calculate fuel requirements, assess weight and balance, file with the FAA, and adapt in real-time if conditions change. Regulations vary by airspace class, aircraft type, and flight rules (VFR vs IFR).
In our Day 1 Big Picture session, we mapped over 80 domain events across the flight lifecycle. Critical hotspots emerged immediately:
- Weather integration timing: When do you fetch weather? At plan creation? Before departure? Continuously? The answer turned out to be "all three, but differently"—which led to a clear Weather bounded context with its own refresh policies.
- Regulatory compliance: The rules for VFR vs IFR flight plans are fundamentally different. This surfaced as two distinct flows on the wall, which validated the decision to model them as separate aggregates sharing a common flight plan shell.
- AI copilot boundaries: Where does AI assist vs. where does the pilot retain authority? Event Storming made this visible. AI could suggest routes and flag risks, but commands like "File Flight Plan" had to remain human-initiated with explicit confirmation.
By end of Day 2, we had a clean architecture: four bounded contexts (Flight Planning, Weather, Regulatory, and AI Assistance), clear aggregate boundaries, and a precise list of integrations. The MVP scope was obvious—we could build the core flight planning loop with AI suggestions in 6 weeks, deferring the full regulatory filing integration to Phase 2.
Without Event Storming, this project would have taken weeks of back-and-forth requirements gathering, and we almost certainly would have gotten the AI boundary wrong—either giving the copilot too much authority (safety risk) or too little (no value proposition).
The DDD Connection
Event Storming is powerful even if you never read a DDD book, but it becomes even more valuable when connected to core DDD concepts:
Ubiquitous Language is the single most important outcome—and it's one of the core principles of Domain-Driven Design for startups. After two days, everyone—founder, designer, engineer—uses the same words to describe the same things. A "Flight Plan" means the same thing in conversation, in Figma, in code, and in the database schema. This eliminates an entire category of bugs: the ones caused by misunderstanding.
Context Maps emerge naturally from the bounded context boundaries. You can see where contexts communicate, what data crosses boundaries, and where you need anti-corruption layers to keep one context's model from bleeding into another.
Strategic Design becomes tangible. You can point at the wall and say: "This bounded context is our core domain—it's where our competitive advantage lives, and we'll invest heavily here. That context is supporting—we'll use off-the-shelf solutions. And that one is generic—we'll integrate a third-party service."
Why This Matters for Your MVP
If you're a founder about to build an MVP, the scoping phase is the highest-leverage moment in your entire project. Get it right, and your $30K investment builds exactly what you need. Get it wrong, and you burn $30K learning what you should have learned in two days.
Event Storming compresses weeks of traditional discovery into 48 hours. It puts founders and engineers in the same room, speaking the same language, looking at the same model. It surfaces complexity, disagreement, and risk before a single line of code is written.
At Meld, every project starts here. It's why we can confidently scope MVPs for $15-50K and deliver in 4-8 weeks from idea to revenue. We're not guessing. We're building from a shared map that everyone in the room helped create.
Want to run an Event Storm for your product? Reach out to Meld—we'll have your architecture mapped before the sticky notes lose their adhesive.