Building an MVP

In this exercise, you're the engineer helping shape a new product idea into a real, shippable MVP. The product is a lightweight scheduling experience for small groups trying to coordinate social plans across organizations, calendars, and communication habits.

This is a realistic engineering scenario: the team has limited time, partial information, and strong pressure to "just build something." The risk is that speed without clarity creates expensive rework. Teams often discover too late that they optimized for the wrong audience, chose weak success signals, or made architecture choices that slow them down in week two.

Your job is to balance product discovery and implementation pragmatism. That means defining what "good enough for MVP" actually means, making tradeoffs explicit, and building in a way that leaves room for likely future needs without over-engineering day one.

You'll move through a practical decision sequence:

Clarify MVP outcomes and constraints
Run a stakeholder meeting to resolve unknowns
Select a starter architecture based on risk and future change
Implement the plan, then evaluate how closely execution matched intent

By the end, you should be able to explain:

which outcomes were intentionally in scope for MVP
which requirements were deferred and why
which risks were accepted vs mitigated
where implementation aligned with the plan and where judgment calls improved it

This exercise emphasizes engineering judgment over process theater. A strong result is not "perfect docs" or "maximum features." It is a focused MVP with clear tradeoffs, explicit assumptions, and a concrete understanding of why those decisions were reasonable at the time.