Quiz

Prism mobile design quiz

Check the Prism mobile design post: local-first play, daily seeds, sync, leaderboards, streaks, notifications, and mobile reliability.

Questions

8

Est. time

~6 min

Read the post View the series

Score

01
Local-first gameplay

Why should Prism keep the tap-by-tap game loop on the mobile client instead of asking the server to validate each tap?
Options for question 1
1. A. Because local storage forbids API calls during gameplay
2. B. Because the memory loop needs instant feedback and should survive slow networks
3. C. Because leaderboards do not need any server validation
4. D. Because Expo apps cannot run server-driven phases, remote note playback, or local timers
Correct answer: B.

The player experience depends on instant audio, animation, and input feedback. The server should protect shared facts like seeds, scores, and leaderboard state, not sit in the middle of every tap.
02
Deterministic daily challenge

What is the main benefit of returning a daily seed instead of returning a full daily sequence from the backend?
Options for question 2
1. A. The client can generate the same challenge locally after receiving a small shared seed
2. B. The backend can skip secrets, validation, leaderboards, and all future server-side score checks
3. C. The leaderboard can trust every score without validation
4. D. The app can remove all local storage
Correct answer: A.

A seed lets the server define the shared challenge while the client generates the sequence locally. This keeps the backend simple and makes gameplay less dependent on repeated network calls.
03
Trust boundary

Which boundary best describes Prism's score and leaderboard design?
Options for question 3
1. A. The client owns leaderboard truth and can write all shared rankings directly to the database
2. B. The server owns every animation, note playback event, and tap transition
3. C. The client calculates gameplay, while the server validates and stores shared scores
4. D. Supabase sends each next note directly to the screen
Correct answer: C.

The client owns the responsive game experience, but the server decides what becomes shared leaderboard state after basic validation. That is the right split for a casual daily game.
04
Cloud sync

Why is a single last-write-wins rule a poor fit for all Prism sync data?
Options for question 4
1. A. Because Supabase only supports append-only writes
2. B. Because different data types need different merge rules, such as best score wins and settings staying local
3. C. Because Zustand state cannot be serialized, merged, persisted, or tested across app launches
4. D. Because achievements must be deleted whenever a user signs in
Correct answer: B.

Best scores, streaks, achievements, medals, and settings have different product meanings. A good sync design names the merge policy per data type instead of using one rule everywhere.
05
Offline retry

A player finishes a daily challenge in a subway tunnel and score submission times out. What should the app do?
Options for question 5
1. A. Discard the score because leaderboard submission failed
2. B. Block results until the network returns and the leaderboard confirms the write
3. C. Save local progress, queue the submission, and retry later with honest pending UI
4. D. Insert the score directly into Supabase from the client
Correct answer: C.

Mobile networks fail often. Prism should preserve the local result, retry transient submission failures, and avoid claiming confirmed leaderboard state until the backend accepts the score.
06
Daily streaks

What makes streak logic tricky enough to design explicitly?
Options for question 6
1. A. Streaks require every note in the sequence to be stored remotely
2. B. Streaks depend on day boundaries, completion state, sync, and user expectations around missed days
3. C. Streaks only work if the app has live multiplayer, real-time rooms, and socket presence
4. D. Streaks cannot be represented in local storage
Correct answer: B.

A streak seems simple, but it depends on date boundaries and completion records. The app also needs sane behavior across offline play and cloud sync.
07
Push reminders

Why does Prism use the backend for daily reminder pushes instead of relying only on local app screens?
Options for question 7
1. A. The backend can evaluate completion state, push tokens, preferences, and scheduled reminder windows even when the app is closed
2. B. React Native screens cannot navigate after a notification tap, app launch, or deep-link replay
3. C. Local settings are not allowed to store notification preferences
4. D. Push notifications must include the full daily sequence
Correct answer: A.

Reminder delivery is a background product loop. The server can check who still needs a reminder, dedupe push tokens, log delivery, and send pushes without the app being active.
08
Scope control

Which backend feature would be least necessary for Prism's first strong version?
Options for question 8
1. A. Daily seed endpoint
2. B. Score submission endpoint with validation, seed checks, upserts, and percentile lookup
3. C. Real-time multiplayer game server
4. D. Sync data endpoint
Correct answer: C.

A real-time multiplayer server would make the system much wider without helping the core daily memory-game loop. Prism can stay small with serverless endpoints for seeds, scores, sync, and reminders.

Progress

0/8 answered

Answer every question before submitting.

Made in SF v1

Product EM · SF

01 Home 02 Projects 03 Writing 04 CV 05 Playground 06 Contact

© 2026 Sean Kim