Final Demo Plan

Final Demo Plan

Demo Overview

Property	Detail
Total Duration	8 minutes
Scenarios	2 (Web + Mobile)
Deployment	Live on public HTTPS URL
Platforms	React web app + React Native mobile app

---

Demo Structure

The demo is split into two back-to-back scenarios. Scenario 1 (Web) covers the recommendation engine, the social feed, and messaging. Scenario 2 (Mobile) picks up on the operational side of an active mentorship: scheduling, task assignment, progress, and feedback on submitted work.

#	Scenario	Platform	Perspective	Duration	Key Features Covered
1	Recommendation, Social, Messaging	Web	Mentee	4:00	Recommendation system (scoring and explanations), keyword search, mentor detail view, social feed (For You vs Following), like and follow actions, messaging history, real-time message sending, notification badges.
2	Scheduling, Tasks, Progress	Mobile	Mentor	4:00	Availability management, meeting details with external links, reschedule request handling, task assignment with deadlines, progress timeline and milestones, task submission review with structured feedback.

Why this flow? In the MVP demo we showed how a match gets made. In the Final Demo we are showing what happens once two people are already connected. Skipping registration lets us spend the full eight minutes on the features that took us the longest to build, and the cross-platform handoff also doubles as a live test of state synchronization between the web and mobile clients.

---

User Scenarios

Scenario 1: Recommendation, Social, Messaging (Web)

Persona: Elif Yılmaz — Mentee. She has been on the platform for a while, is verified, and already has an active mentorship, but is looking to expand her network and engage with the community.

Story: Elif opens the web app and goes straight to her recommendations. Each suggested mentor comes with a compatibility score and a short explanation of why they were suggested. She uses the search bar to narrow the list to a specific topic, opens a mentor's detail page, and checks current capacity and availability. Then she switches to the social feed, compares the For You tab against Following, likes a post, and follows a new mentor in her field. Finally she opens her messaging inbox, scrolls through her history with Dr. Bulut, and sends a quick note about tomorrow's session.

Features Demonstrated:

1. Recommendation system with explanations and scoring
2. Keyword-based mentor search filtering
3. Mentor detail view (expertise, availability, capacity limits)
4. Social feed (For You vs Following)
5. Interactive community actions (like and follow)
6. Messaging inbox and chat history
7. Notification badges

---

Scenario 2: Scheduling, Tasks, Progress (Mobile)

Persona: Dr. Ahmet Bulut — Mentor. He has an active, ongoing mentorship with Elif and is managing his workflow on the go.

Story: Dr. Bulut opens the mobile app and starts with his schedule. He sees his weekly availability, taps tomorrow's meeting with Elif, and reviews the external video link and confirmed status. Back on the schedule view, he sees a reschedule request from another mentee and approves it. He moves on to Tasks: he creates a new weekly task for Elif with a deadline, glances at the progress view to see where the mentorship currently stands, then opens a task Elif submitted the night before and leaves structured feedback for the next iteration.

Features Demonstrated:

1. Availability calendar
2. Meeting details, including external video link
3. Reschedule request approval
4. Task creation and deadline assignment
5. Progress timeline and milestones
6. Task submission review and structured feedback

---

Demo Script

The script keeps the original feature-by-feature timestamping so evaluators can verify coverage at a glance, with a Beat column that names the narrative arc each row contributes to.

Scenario 1: Recommendation, Social, Messaging (Web) — 4:00

Setup: Browser is open on the deployed React web application. Pre-authenticated session as "Elif Yilmaz" (Mentee). The dashboard is fully populated with realistic, in-progress data.

Time	Beat	Speaker	Operator	Action and Narration
0:00 - 0:20	Intro	Amin	Muhammet Sami	Amin: "In the MVP demo we showed you how a match gets made. Today we want to show you what happens after that — how a mentorship actually runs day to day. We're starting with Elif, who's already on the platform and already has one active mentor."
0:20 - 1:30	Why this match	Amin	Muhammet Sami	Recommendations. Sami opens the Recommendations page. Amin: "This is Elif's recommendations page. The main thing we wanted to do differently was not give her a black-box ranking. If she hovers any card she gets the score and the reason behind it: which skills overlap, which career goals line up, whether they're in the same city. That's the part most platforms skip, and it's what makes a mentee actually trust the suggestion enough to reach out."
1:30 - 2:10	Why this match	Amin	Muhammet Sami	Search and mentor detail. Sami types "NLP" in the search bar; the list filters live. He opens a mentor card. Amin: "Of course Elif might want to filter further. The search bar narrows the recommendations as she types — here she's looking for someone with NLP background. When she opens a profile she sees what actually matters before reaching out: how many mentees the person currently has, whether they have any free slots this week."
2:10 - 3:10	Community in motion	Amin	Muhammet Sami	Social feed. Sami navigates to the Social Feed. Amin: "Past the recommendations, Elif also has a feed. Two tabs. For You is what the platform thinks she'll like based on her interests. Following is just the people and tags she's already opted into." Sami switches between the tabs, likes a post, follows a new mentor; the notification badge ticks up. Amin: "She likes a post, follows a new mentor, and you can see the notification badge update. Same kind of interactions she'd expect from any other social app, just inside the mentorship platform."
3:10 - 3:50	Direct line	Amin	Muhammet Sami	Messaging. Sami clicks the notification badge and opens the inbox; he selects Dr. Bulut's chat. Amin: "Last thing on the web side. Messaging is in the platform, not in email. Elif opens her chat with Dr. Bulut, scrolls through what they talked about last week, and sends a quick note: 'Looking forward to our session tomorrow.'" Sami types and sends. Amin: "That message shows up immediately on Dr. Bulut's side, which we'll see in a second on mobile."
3:50 - 4:20	Transition	Amin	Muhammet Sami	Amin: "That's Elif's side. She's found the right person, made an introduction, and sent a message. The other half of the question is what Dr. Bulut sees on his end. In a lot of platforms this is where things fall apart — the mentor has to open an email, open a calendar, open a separate task tool. We wanted to keep all of that in one mobile flow. Over to Burak." During the bridge, Sami switches the screen-share to mobile and Ovgu picks up the device.

Selling points (for the team to keep in mind, not to read aloud):

• The recommendation engine is not a black box; every match comes with a stated reason.
• The search filter and the chat both update instantly — a quick proof of frontend responsiveness.
• The social feed turns a directory into something users come back to.

---

Scenario 2: Scheduling, Tasks, Progress (Mobile) — 4:00

Setup: Mobile app is running on a physical device (with a backup device on standby). Pre-authenticated as "Dr. Ahmet Bulut" (Mentor). A pre-recorded 15-second clip of the Progress timeline is queued in the operator's secondary tab in case the live feature is not stable on demo day.

Time	Beat	Speaker	Operator	Action and Narration
4:20 - 4:40	Intro	Burak	Ovgu Su	Burak: "So this is Dr. Bulut on the mobile app. Web is mostly for discovery — finding mentors, posting, following. Mobile is where the day-to-day actually happens, when you have ten minutes between meetings and you need to move things forward. Starting with the schedule."
4:40 - 5:30	Schedule	Burak	Ovgu Su	Availability. Ovgu opens the Schedule tab. Burak: "His week is already laid out. The slots he marked available, the meetings already booked on top of those. Tomorrow he has Elif at 3pm."
5:30 - 5:55	Schedule	Burak	Ovgu Su	Meeting details. Ovgu taps the meeting. Burak: "If he taps in, he gets the meeting card. Link to the video call, status confirmed, time. Nothing else to chase down."
5:55 - 6:25	Schedule	Burak	Ovgu Su	Reschedule approval. Ovgu navigates back; a reschedule notification is waiting. Burak: "There's a notification waiting. Another mentee can't make her slot tomorrow and wants to move it to Wednesday. Dr. Bulut sees the new time, taps approve, and the calendar updates on both sides — no one has to re-type anything."
6:25 - 7:10	Driving the work	Burak	Ovgu Su	Task assignment. Ovgu navigates to Tasks and taps + to create a new one. Burak: "Tasks tab. Dr. Bulut wants Elif to review some API documentation before their next session, so he creates the task here and sets the deadline for Friday. From this point on, Elif and Dr. Bulut are looking at the same item with the same deadline — there's no separate to-do list and no 'wait, what was I supposed to do.'"
7:10 - 7:25	Driving the work	Burak	Ovgu Su	Progress glance (de-risked, see Backup Plan). Ovgu opens the Progress tab briefly. Burak: "Quick check on Progress before he reviews her last submission. What's done so far, what's still in flight. About six weeks in, three of the agreed milestones complete." If the live tap is unstable, Ovgu plays the queued 15-second clip while Burak narrates the same line; the demo continues without skipping a beat.
7:25 - 7:50	Driving the work	Burak	Ovgu Su	Task feedback. Ovgu opens a "Submitted" task from Elif. Burak: "Last thing. Elif submitted the previous task last night. Dr. Bulut opens it, reads through, leaves feedback on the specific points he wants her to revisit. Elif sees this the next time she opens the app, and the next task builds on it."
7:50 - 8:00	Closer	Burak	Ovgu Su	Burak: "And that's the picture. Recommendations to introductions, schedule, tasks, progress, feedback — all in one place, all moving the same mentorship forward. Thanks for watching."

Selling points (for the team to keep in mind, not to read aloud):

• The mobile app covers the entire operational surface of a mentorship in a single session.
• Feedback isn't a comment box — it's a system that ties submissions back into the progress view.
• The message Elif sent on the web side already showed up on mobile without a refresh.

---

Demo-Data Strategy

Our database is seeded with an intentional, in-progress state that exercises specific edge cases and algorithms — not random mock data.

User Accounts and State

• Elif Yilmaz (Mentee): Verified and active. Profile configured with Data Science goals and an Istanbul location to test the recommendation engine's weighting logic.
• Dr. Ahmet Bulut (Mentor): Active, mature mentorship with Elif. Capacity set to 2/3 so he is still available but visibly engaged.
• Mehmet Yilmaz (Mentor — Edge Case): Maximum capacity (3/3). Appears in the search, but his "Send Request" button is disabled to prove enforcement of the capacity limit.
• Zeynep Arslan (Mentor — Edge Case): Candidate mentor in the feed and search. Her surname and profile photo are dynamically hidden to prove our privacy requirement (Rule 1.1.2.5) for non-connected users.

Pre-Populated Ecosystem

• Recommendation explanations: the recommendation list is seeded with diverse explanation texts (e.g. "95% Match: Shared interest in Machine Learning and proximity in Istanbul") to prove both skill-based and location-based matching.
• Social feed inputs: posts are seeded with specific hashtags (e.g. #DataScience) so we can show that Elif's For You tab actually filters by her interests, in contrast to the chronological Following tab.
• Mentorship history: Elif and Dr. Bulut's connection has past completed tasks, resolved meetings, and older messages, so the Progress view actually shows a journey with milestones and not a blank slate.

Dynamic Edge-Case Data

• Pending reschedule: an unresolved reschedule request from another mentee is pre-loaded in Dr. Bulut's calendar so we can demonstrate the approval workflow without creating it live.
• Overdue task: one task is intentionally seeded with a past deadline so the red warning badges fire on the UI.

---

Role Assignments

The demo has eight people. Two of the Q&A roles double as observer and timekeeper during the live run, since Q&A only fires once the demo is over.

Role	Person	Responsibility
Web Narrator	Amin Abu-Hilga	Narrates the web scenario.
Web Operator	Muhammet Sami Cakmak	Drives the browser; performs clicks, types messages, owns the screen-share.
Mobile Narrator	Burak Ogut	Narrates the mobile scenario.
Mobile Operator	Ovgu Su Afsar	Drives the device; queues the pre-recorded progress-timeline clip on the secondary tab and plays it if the live tap fails.
Backend Q&A + Timekeeper	Mehmet Bora Sarioglu	Q&A on API design, authentication, and data model. During the live run, keeps time against the script and gives silent hand signals to the active narrator at the 30-second warning before each beat boundary.
Backend Q&A	Ibrahim Kayan	Q&A on business logic, recommendation logic, and request flow.
DevOps + Customer Observer	Beratcan Dogan	Q&A on deployment, CI/CD, and database sync. During the live run, watches audience reactions, flags confusion or strong-interest moments to the note-taker, and feeds these into the post-demo debrief.
Note-taker	Ibrahim Kayan	Records customer/evaluator feedback during and after the demo, including reactions surfaced by the observer.

---

Feature Coverage Matrix

#	Final Demo Feature	Web (Mentee)	Mobile (Mentor)	Backup ready?
1	Recommendations and explanations	X		live
2	Keyword mentor search	X		live
3	Social feed (For You / Following)	X		live
4	Post interaction (like and follow)	X		live
5	Real-time messaging	X		live
6	Schedule and availability view		X	live
7	Meeting details and external links		X	live
8	Reschedule approval		X	live
9	Task creation and deadlines		X	live
10	Task submission and feedback		X	live
11	Progress timeline and milestones		X	Pre-recorded 15s clip queued by mobile operator

---

Backup Plan

Risk	Likelihood	Mitigation
Internet connection drops	Low	Pre-recorded full demo video on the desktop. Play it and narrate live over the top.
Web app error mid-flow	Medium	Secondary browser tabs pre-loaded at stable states (open chat, open feed) to switch into if a click fails.
Mobile app crashes	Low	Backup physical device on standby, ready to swap in. Worst case: switch to a screen recording.
Specific flow regresses	Medium	Operator skips the affected step and pivots to an alternative feature in the same view, narrator covers the gap without breaking the flow.
Progress Timeline view not stable	Medium	15-second pre-recorded clip queued in the mobile operator's secondary tab. If the live tap fails, narrator says the same line while the operator plays the clip. If the feature is missing entirely on the day, the operator skips the aside cleanly — Beat 2 still lands on tasks and feedback, and the closer is unchanged.

---

Rehearsal Plan

The two biggest risk surfaces are the web-to-mobile screen-share handoff and time overruns on individual beats. The cadence below is designed to surface issues at points where there is still time to fix them.

When	What	Who	What we're verifying
2 days before	Full run-through #1 in the actual deployed environment with the real seeded data. Time each row against the script.	Four presenters and one stand-in evaluator (any teammate not in a presenting role)	Live deployment behaves correctly, seeded edge-cases trigger as expected, total runtime fits within 8 minutes.
1 day before	Full run-through #2 with a backup-plan dry-run — deliberately fail one feature mid-run (e.g. disable WiFi for 5 seconds, force a click on a broken button) and have the operator pivot live. Practice the progress-timeline clip handoff specifically.	Four presenters	Operators can recover gracefully, narrators have one-line covers ready, the team has actually rehearsed pivoting before needing to do it for real.
Demo morning	Abbreviated run-through: introduction, transition, closer, and the progress-timeline aside only.	Four presenters	Voice warm-up, screen-share and device handoff timing, opener and closer landed cleanly.
30 minutes before demo	Sanity check on the deployed app, seeded data state, pre-recorded clip plays from the operator's machine, notification states correct (e.g. unread badge actually showing).	DevOps and both operators	No last-minute surprises.

---

Lessons Implemented from MVP Demo

(These bullets are written content for the document and the report-side audience; they are not read aloud during the demo itself. The narrator script stays in user-value language.)

• Product-focused (value over setup): in the MVP we focused on checking off basic requirements. For the final milestone we evaluated every feature by asking what problem it actually solves for the mentor or mentee. That is why we are skipping the onboarding setup and dedicating the full eight minutes to higher-value features like scheduling, structured feedback, and recommendation explanations.
• End-to-end realism via UI testing: we learned that automated tests alone can miss UX friction and state-management bugs. The seamless flow you see today is the result of manual UI testing across both web and mobile, against the same realistic mentorship data we are demoing.
• Vertical slicing for cross-platform synergy: to reduce integration chaos, we shifted from horizontal layers to vertical slices. The instant cross-platform handoff — an action on the React web app immediately reflecting on the React Native mobile app — is the result of API, web, and mobile being developed and validated in parallel iterations, not in sequence.
• Purpose-driven UI (prototyping first): before writing code for views like the Progress Timeline we used paper prototypes and UI mockups. That is why those interfaces visualise the journey rather than just listing raw data.