From Pitch Deck to MVP: Building In My Corner

A pitch deck is a story about a product. It is not a build plan, and treating it like one is how founders end up scoping the wrong things first. In My Corner came to us as a deck; we turned it into functional requirements, an architecture recommendation, and a working MVP.

In My Corner is a two-sided marketplace connecting professionals with mentors and coaches for paid, live 1:1 sessions — the same category of problem Calendly, Codementor and Uber's own booking-rating-payment loop have each solved in their own domain. That was actually good news: none of the requirements called for new technology, so the real work was disciplined scoping, not invention.

Turning a deck into requirements

We extracted the functional requirements directly from the pitch deck's own narrative slides and product mockups — how the platform works, the mentor search and booking flow, the target market, the business model — and flagged, explicitly, every place the deck implied a requirement without stating it outright. That distinction matters: a founder should know exactly which requirements came from their own deck and which ones we inferred, so nothing gets built on an assumption nobody actually signed off on.

The two core roles came straight out of the deck: the Mentee, a professional seeking career advice, coaching or problem-solving help, who searches for mentors, books and pays for sessions, and rates mentors afterward; and the Mentor/Coach, an experienced practitioner who manages their own profile, sets rate and availability, accepts bookings, and rates mentees in turn. Every requirement was tagged Must, Should or Could against the MVP scope, so the build plan could prioritise honestly instead of trying to ship everything from the deck at once.

The three decisions that had to happen before any code did

The deck's own SWOT analysis surfaced three open product questions that shape the data model itself — so they couldn't be deferred to "figure it out during the build":

• Disintermediation risk — what stops a mentee and mentor from moving off-platform after their first session? The platform has to make staying on it meaningfully easier than leaving it, not just ask people nicely.
• Mentor vetting — are mentor profiles manually approved before they go live, or is it self-serve? This decides whether an approval queue exists in the data model at all.
• Cancellation and refund policy — this has to be settled before payment and credit logic can be finalised, not bolted on afterward.

Answering these first, rather than defaulting to whatever was fastest to build, is what keeps a rewrite (or in this case, a first build) from locking in the wrong assumptions.

The recommended architecture — and why it's deliberately unoriginal

The build plan recommends a React (Next.js) mobile-responsive web app on the frontend, matching the deck's own mockups without the cost of a native app; a Node.js API on the backend; scheduling and split payments handled through proven, off-the-shelf integrations (Zoom for video delivery) rather than building either from scratch. For a two-sided marketplace at MVP stage, the goal isn't novel technology — it's getting a real pilot in front of actual mentors and mentees as fast as possible, and every recommendation in the plan is judged against that, not against what's technically interesting to build.

From plan to MVP

With the requirements, the architecture, and the three open product decisions answered, the build moved straight into an MVP: mentor discovery and booking, scheduling, and the payment split, built to the Must-have requirements first. Native mobile apps, in-app video, and expansion beyond the initial professional market were explicitly deferred to future scope, exactly as the deck's own SWOT suggested — not cut arbitrarily, but sequenced deliberately.

The takeaway

The gap between "we have a pitch deck" and "we have an MVP" isn't really a coding problem — it's a scoping and decision-making problem. Get the requirements extracted honestly, get the open product questions answered before they're baked into the data model, and pick boring, proven technology for a marketplace that doesn't need to reinvent booking or payments. That's what turns a deck into something mentors and mentees can actually use.