Update verbage

Author: kentcdodds

exercises/01.building-an-mvp/02.solution.stakeholder-meeting/discovery-brief.md

@@ -6,7 +6,7 @@ answers and decisions before implementation begins.
 ## Objective to validate
 
 - Confirm the MVP outcome this release should optimize for
-  - Confirmed: optimize for finalized plans, not just polls created
+  - Confirmed: optimize for finalized plans, not just schedules created
 - Confirm the user workflow this MVP should improve first
   - Confirmed: reduce coordination friction for friends across different
     organizations
@@ -70,10 +70,10 @@ answers and decisions before implementation begins.
 - What primary metric defines MVP viability?
   - Finalized-plan rate
 - What secondary signals help interpret progress?
-  - Poll response completion rate
-  - Median time from poll creation to finalized time
+  - Submission completion rate
+  - Median time from schedule creation to finalized time
 - What failure signal indicates the MVP is not working?
-  - Many polls created, but few result in a confirmed plan
+  - Many schedules created, but few result in a confirmed plan
 - What UX quality bar should support the success metric?
   - Availability selection should feel spreadsheet-fast: like selecting
     time-slot cells in Excel on desktop, with clear visual state and low
@@ -119,8 +119,8 @@ answers and decisions before implementation begins.
   - Confusion between host and attendee links causing incorrect sharing or lost
     host control
 - What evidence would indicate each risk is becoming real?
-  - Polls with low completion
-  - Low response rates despite poll creation
+  - Schedules with low submission completion
+  - Low response rates despite schedule creation
   - Growing backlog of out-of-scope requests
 - What mitigation options are available if a risk materializes?
   - Mobile-first UX for response completion (thumb-friendly controls, clear
@@ -158,7 +158,7 @@ answers and decisions before implementation begins.
     attendee response visibility
 - If existing scheduling tools already work, why build this?
   - We need a differentiated UX for reliable plan completion plus AI-agent
-    orchestration via MCP, not just another availability poll
+    orchestration via MCP, not just another scheduling link
 - Where are we drawing UX inspiration and which competitors should guide
   baseline expectations?
   - when2meet.com, whenavailable.com, and Doodle

exercises/01.building-an-mvp/02.solution.stakeholder-meeting/discovery-meeting-transcript.md

@@ -25,15 +25,15 @@ simple availability collection, but they break down for our target flow:
 cross-organization friend groups coordinating in messy chat threads with no
 clear owner and no reliable "final plan" moment.
 
-💼 Brett: Our advantage is not "another poll." It is a completion-first
+💼 Brett: Our advantage is not "another scheduling link." It is a completion-first
 coordination loop: low-friction participation, explicit finalization, and host
 controls that work without forcing everyone into account creation.
 
 🐨 Kody: So the justification for building is that we are targeting a specific
 gap existing tools do not solve well, and we can define success against that
 gap.
 
-💼 Brett: Exactly. If we cannot outperform the default chat-plus-poll behavior
+💼 Brett: Exactly. If we cannot outperform the default chat-plus-scheduling-link behavior
 on finalized plans, we should stop and not keep investing.
 
 🐨 Kody: Where are we going to draw inspiration for the user experience? Which
@@ -92,7 +92,7 @@ first release, which one tells us this is working?
 because we can ship faster, reduce risk, and learn from real behavior sooner.
 
 💼 Brett: If I force myself to pick one, it is finalized plans. We can get
-excited about poll creation, but if people still do not lock a time, we have not
+excited about schedule creation, but if people still do not lock a time, we have not
 actually solved anything. So yes, finalized plans first.
 
 🐨 Kody: Who is the first user segment?
@@ -139,7 +139,7 @@ you are asking for workflow signals, not growth signals.
 🐨 Kody: Useful later. For this workflow specifically, what secondary signals
 help explain finalized-plan rate?
 
-💼 Brett: For workflow, poll response completion and time-to-finalized-plan.
+💼 Brett: For workflow, submission completion and time-to-finalized-plan.
 
 🐨 Kody: What failure pattern should we watch for?
 
@@ -150,7 +150,7 @@ value, even if activity looks okay. For example, if people keep abandoning the
 flow before they submit availability, that is a failure pattern.
 
 💼 Brett: The bad pattern is lots of activity that looks healthy on the surface
-but no real outcomes. In this case: lots of polls created, very few confirmed
+but no real outcomes. In this case: lots of schedules created, very few confirmed
 plans.
 
 🐨 Kody: Where does today’s workflow fail most?

exercises/01.building-an-mvp/03.problem.select-starter-architecture/discovery-brief.md

@@ -6,7 +6,7 @@ answers and decisions before implementation begins.
 ## Objective to validate
 
 - Confirm the MVP outcome this release should optimize for
-  - Confirmed: optimize for finalized plans, not just polls created
+  - Confirmed: optimize for finalized plans, not just schedules created
 - Confirm the user workflow this MVP should improve first
   - Confirmed: reduce coordination friction for friends across different
     organizations
@@ -70,10 +70,10 @@ answers and decisions before implementation begins.
 - What primary metric defines MVP viability?
   - Finalized-plan rate
 - What secondary signals help interpret progress?
-  - Poll response completion rate
-  - Median time from poll creation to finalized time
+  - Submission completion rate
+  - Median time from schedule creation to finalized time
 - What failure signal indicates the MVP is not working?
-  - Many polls created, but few result in a confirmed plan
+  - Many schedules created, but few result in a confirmed plan
 - What UX quality bar should support the success metric?
   - Availability selection should feel spreadsheet-fast: like selecting
     time-slot cells in Excel on desktop, with clear visual state and low
@@ -119,8 +119,8 @@ answers and decisions before implementation begins.
   - Confusion between host and attendee links causing incorrect sharing or lost
     host control
 - What evidence would indicate each risk is becoming real?
-  - Polls with low completion
-  - Low response rates despite poll creation
+  - Schedules with low submission completion
+  - Low response rates despite schedule creation
   - Growing backlog of out-of-scope requests
 - What mitigation options are available if a risk materializes?
   - Mobile-first UX for response completion (thumb-friendly controls, clear
@@ -158,7 +158,7 @@ answers and decisions before implementation begins.
     attendee response visibility
 - If existing scheduling tools already work, why build this?
   - We need a differentiated UX for reliable plan completion plus AI-agent
-    orchestration via MCP, not just another availability poll
+    orchestration via MCP, not just another scheduling link
 - Where are we drawing UX inspiration and which competitors should guide
   baseline expectations?
   - when2meet.com, whenavailable.com, and Doodle

exercises/01.building-an-mvp/03.problem.select-starter-architecture/discovery-meeting-transcript.md

@@ -25,15 +25,15 @@ simple availability collection, but they break down for our target flow:
 cross-organization friend groups coordinating in messy chat threads with no
 clear owner and no reliable "final plan" moment.
 
-💼 Brett: Our advantage is not "another poll." It is a completion-first
+💼 Brett: Our advantage is not "another scheduling link." It is a completion-first
 coordination loop: low-friction participation, explicit finalization, and host
 controls that work without forcing everyone into account creation.
 
 🐨 Kody: So the justification for building is that we are targeting a specific
 gap existing tools do not solve well, and we can define success against that
 gap.
 
-💼 Brett: Exactly. If we cannot outperform the default chat-plus-poll behavior
+💼 Brett: Exactly. If we cannot outperform the default chat-plus-scheduling-link behavior
 on finalized plans, we should stop and not keep investing.
 
 🐨 Kody: Where are we going to draw inspiration for the user experience? Which
@@ -92,7 +92,7 @@ first release, which one tells us this is working?
 because we can ship faster, reduce risk, and learn from real behavior sooner.
 
 💼 Brett: If I force myself to pick one, it is finalized plans. We can get
-excited about poll creation, but if people still do not lock a time, we have not
+excited about schedule creation, but if people still do not lock a time, we have not
 actually solved anything. So yes, finalized plans first.
 
 🐨 Kody: Who is the first user segment?
@@ -139,7 +139,7 @@ you are asking for workflow signals, not growth signals.
 🐨 Kody: Useful later. For this workflow specifically, what secondary signals
 help explain finalized-plan rate?
 
-💼 Brett: For workflow, poll response completion and time-to-finalized-plan.
+💼 Brett: For workflow, submission completion and time-to-finalized-plan.
 
 🐨 Kody: What failure pattern should we watch for?
 
@@ -150,7 +150,7 @@ value, even if activity looks okay. For example, if people keep abandoning the
 flow before they submit availability, that is a failure pattern.
 
 💼 Brett: The bad pattern is lots of activity that looks healthy on the surface
-but no real outcomes. In this case: lots of polls created, very few confirmed
+but no real outcomes. In this case: lots of schedules created, very few confirmed
 plans.
 
 🐨 Kody: Where does today’s workflow fail most?

exercises/01.building-an-mvp/03.solution.select-starter-architecture/discovery-brief.md

@@ -6,7 +6,7 @@ answers and decisions before implementation begins.
 ## Objective to validate
 
 - Confirm the MVP outcome this release should optimize for
-  - Confirmed: optimize for finalized plans, not just polls created
+  - Confirmed: optimize for finalized plans, not just schedules created
 - Confirm the user workflow this MVP should improve first
   - Confirmed: reduce coordination friction for friends across different
     organizations
@@ -70,10 +70,10 @@ answers and decisions before implementation begins.
 - What primary metric defines MVP viability?
   - Finalized-plan rate
 - What secondary signals help interpret progress?
-  - Poll response completion rate
-  - Median time from poll creation to finalized time
+  - Submission completion rate
+  - Median time from schedule creation to finalized time
 - What failure signal indicates the MVP is not working?
-  - Many polls created, but few result in a confirmed plan
+  - Many schedules created, but few result in a confirmed plan
 - What UX quality bar should support the success metric?
   - Availability selection should feel spreadsheet-fast: like selecting
     time-slot cells in Excel on desktop, with clear visual state and low
@@ -119,8 +119,8 @@ answers and decisions before implementation begins.
   - Confusion between host and attendee links causing incorrect sharing or lost
     host control
 - What evidence would indicate each risk is becoming real?
-  - Polls with low completion
-  - Low response rates despite poll creation
+  - Schedules with low submission completion
+  - Low response rates despite schedule creation
   - Growing backlog of out-of-scope requests
 - What mitigation options are available if a risk materializes?
   - Mobile-first UX for response completion (thumb-friendly controls, clear
@@ -158,7 +158,7 @@ answers and decisions before implementation begins.
     attendee response visibility
 - If existing scheduling tools already work, why build this?
   - We need a differentiated UX for reliable plan completion plus AI-agent
-    orchestration via MCP, not just another availability poll
+    orchestration via MCP, not just another scheduling link
 - Where are we drawing UX inspiration and which competitors should guide
   baseline expectations?
   - when2meet.com, whenavailable.com, and Doodle

exercises/01.building-an-mvp/03.solution.select-starter-architecture/discovery-meeting-transcript.md

@@ -25,15 +25,15 @@ simple availability collection, but they break down for our target flow:
 cross-organization friend groups coordinating in messy chat threads with no
 clear owner and no reliable "final plan" moment.
 
-💼 Brett: Our advantage is not "another poll." It is a completion-first
+💼 Brett: Our advantage is not "another scheduling link." It is a completion-first
 coordination loop: low-friction participation, explicit finalization, and host
 controls that work without forcing everyone into account creation.
 
 🐨 Kody: So the justification for building is that we are targeting a specific
 gap existing tools do not solve well, and we can define success against that
 gap.
 
-💼 Brett: Exactly. If we cannot outperform the default chat-plus-poll behavior
+💼 Brett: Exactly. If we cannot outperform the default chat-plus-scheduling-link behavior
 on finalized plans, we should stop and not keep investing.
 
 🐨 Kody: Where are we going to draw inspiration for the user experience? Which
@@ -92,7 +92,7 @@ first release, which one tells us this is working?
 because we can ship faster, reduce risk, and learn from real behavior sooner.
 
 💼 Brett: If I force myself to pick one, it is finalized plans. We can get
-excited about poll creation, but if people still do not lock a time, we have not
+excited about schedule creation, but if people still do not lock a time, we have not
 actually solved anything. So yes, finalized plans first.
 
 🐨 Kody: Who is the first user segment?
@@ -139,7 +139,7 @@ you are asking for workflow signals, not growth signals.
 🐨 Kody: Useful later. For this workflow specifically, what secondary signals
 help explain finalized-plan rate?
 
-💼 Brett: For workflow, poll response completion and time-to-finalized-plan.
+💼 Brett: For workflow, submission completion and time-to-finalized-plan.
 
 🐨 Kody: What failure pattern should we watch for?
 
@@ -150,7 +150,7 @@ value, even if activity looks okay. For example, if people keep abandoning the
 flow before they submit availability, that is a failure pattern.
 
 💼 Brett: The bad pattern is lots of activity that looks healthy on the surface
-but no real outcomes. In this case: lots of polls created, very few confirmed
+but no real outcomes. In this case: lots of schedules created, very few confirmed
 plans.
 
 🐨 Kody: Where does today’s workflow fail most?

exercises/01.building-an-mvp/04.problem.implementation/docs/planning/discovery-brief.md

@@ -6,7 +6,7 @@ answers and decisions before implementation begins.
 ## Objective to validate
 
 - Confirm the MVP outcome this release should optimize for
-  - Confirmed: optimize for finalized plans, not just polls created
+  - Confirmed: optimize for finalized plans, not just schedules created
 - Confirm the user workflow this MVP should improve first
   - Confirmed: reduce coordination friction for friends across different
     organizations
@@ -70,10 +70,10 @@ answers and decisions before implementation begins.
 - What primary metric defines MVP viability?
   - Finalized-plan rate
 - What secondary signals help interpret progress?
-  - Poll response completion rate
-  - Median time from poll creation to finalized time
+  - Submission completion rate
+  - Median time from schedule creation to finalized time
 - What failure signal indicates the MVP is not working?
-  - Many polls created, but few result in a confirmed plan
+  - Many schedules created, but few result in a confirmed plan
 - What UX quality bar should support the success metric?
   - Availability selection should feel spreadsheet-fast: like selecting
     time-slot cells in Excel on desktop, with clear visual state and low
@@ -119,8 +119,8 @@ answers and decisions before implementation begins.
   - Confusion between host and attendee links causing incorrect sharing or lost
     host control
 - What evidence would indicate each risk is becoming real?
-  - Polls with low completion
-  - Low response rates despite poll creation
+  - Schedules with low submission completion
+  - Low response rates despite schedule creation
   - Growing backlog of out-of-scope requests
 - What mitigation options are available if a risk materializes?
   - Mobile-first UX for response completion (thumb-friendly controls, clear
@@ -158,7 +158,7 @@ answers and decisions before implementation begins.
     attendee response visibility
 - If existing scheduling tools already work, why build this?
   - We need a differentiated UX for reliable plan completion plus AI-agent
-    orchestration via MCP, not just another availability poll
+    orchestration via MCP, not just another scheduling link
 - Where are we drawing UX inspiration and which competitors should guide
   baseline expectations?
   - when2meet.com, whenavailable.com, and Doodle

exercises/01.building-an-mvp/04.problem.implementation/docs/planning/discovery-meeting-transcript.md

@@ -25,15 +25,15 @@ simple availability collection, but they break down for our target flow:
 cross-organization friend groups coordinating in messy chat threads with no
 clear owner and no reliable "final plan" moment.
 
-💼 Brett: Our advantage is not "another poll." It is a completion-first
+💼 Brett: Our advantage is not "another scheduling link." It is a completion-first
 coordination loop: low-friction participation, explicit finalization, and host
 controls that work without forcing everyone into account creation.
 
 🐨 Kody: So the justification for building is that we are targeting a specific
 gap existing tools do not solve well, and we can define success against that
 gap.
 
-💼 Brett: Exactly. If we cannot outperform the default chat-plus-poll behavior
+💼 Brett: Exactly. If we cannot outperform the default chat-plus-scheduling-link behavior
 on finalized plans, we should stop and not keep investing.
 
 🐨 Kody: Where are we going to draw inspiration for the user experience? Which
@@ -92,7 +92,7 @@ first release, which one tells us this is working?
 because we can ship faster, reduce risk, and learn from real behavior sooner.
 
 💼 Brett: If I force myself to pick one, it is finalized plans. We can get
-excited about poll creation, but if people still do not lock a time, we have not
+excited about schedule creation, but if people still do not lock a time, we have not
 actually solved anything. So yes, finalized plans first.
 
 🐨 Kody: Who is the first user segment?
@@ -139,7 +139,7 @@ you are asking for workflow signals, not growth signals.
 🐨 Kody: Useful later. For this workflow specifically, what secondary signals
 help explain finalized-plan rate?
 
-💼 Brett: For workflow, poll response completion and time-to-finalized-plan.
+💼 Brett: For workflow, submission completion and time-to-finalized-plan.
 
 🐨 Kody: What failure pattern should we watch for?
 
@@ -150,7 +150,7 @@ value, even if activity looks okay. For example, if people keep abandoning the
 flow before they submit availability, that is a failure pattern.
 
 💼 Brett: The bad pattern is lots of activity that looks healthy on the surface
-but no real outcomes. In this case: lots of polls created, very few confirmed
+but no real outcomes. In this case: lots of schedules created, very few confirmed
 plans.
 
 🐨 Kody: Where does today’s workflow fail most?

exercises/01.building-an-mvp/04.solution.implementation/client/routes/host-schedule.tsx

@@ -341,6 +341,9 @@ export function HostScheduleRoute(handle: Handle) {
 			startsAtUtc: localSlotKeyToUtcIso(localSlotKey, timezone),
 		}))
 		const model = createGridModel(gridSlots, timezone)
+		const bestSlotSubmissionCount = scheduleSnapshot?.bestSlotUtc
+			? (scheduleSnapshot.responseCounts[scheduleSnapshot.bestSlotUtc] ?? 0)
+			: 0
 
 		return (
 			<section css={{ display: 'grid', gap: spacing.lg }}>
@@ -642,8 +645,8 @@ export function HostScheduleRoute(handle: Handle) {
 									hour: 'numeric',
 									minute: '2-digit',
 								})}{' '}
-								({scheduleSnapshot.responseCounts[scheduleSnapshot.bestSlotUtc] ?? 0}{' '}
-								votes, {timezone})
+								({bestSlotSubmissionCount} submission
+								{bestSlotSubmissionCount === 1 ? '' : 's'}, {timezone})
 							</strong>
 						</p>
 					) : (

exercises/01.building-an-mvp/04.solution.implementation/client/routes/respond-schedule.tsx

@@ -254,6 +254,9 @@ export function RespondScheduleRoute(handle: Handle) {
 			startsAtUtc: slot,
 		}))
 		const model = createGridModel(gridSlots, attendeeTimeZone)
+		const bestSlotSubmissionCount = schedule.bestSlotUtc
+			? (schedule.responseCounts[schedule.bestSlotUtc] ?? 0)
+			: 0
 
 		return (
 			<section css={{ display: 'grid', gap: spacing.lg }}>
@@ -291,7 +294,8 @@ export function RespondScheduleRoute(handle: Handle) {
 									hour: 'numeric',
 									minute: '2-digit',
 								})}{' '}
-								({schedule.responseCounts[schedule.bestSlotUtc] ?? 0} votes)
+								({bestSlotSubmissionCount} submission
+								{bestSlotSubmissionCount === 1 ? '' : 's'})
 							</strong>
 						</p>
 					) : null}