QuizQuest timed assessment platform case study

Project intent

QuizQuest is an assessment platform for students and instructors who still run practice as PDFs and email. Learners get timed quizzes with instant feedback and profiles that show which topics they own versus which ones keep failing them. Instructors need a Question Creator that drafts and publishes assessments without another spreadsheet war.

The goal was assessment that teaches during the attempt, not only after a graded dump. Profiles should reflect mastery over time so learners and teachers can plan the next practice set from real attempt data, not from memory of last week's quiz.

Schools and training programs wanted practice that survives real class periods. Timers have to hold up. Feedback has to arrive while the question is still fresh. Authoring tools have to be ones instructors will open twice a week. QuizQuest was built for that weekly rhythm, not for a one-off demo quiz.

Instructors also needed confidence that a published quiz would look the same for every student in the room. That sounds basic until you mix diagrams, timers, and late joiners. Consistency was part of the promise.

Challenge

Schools still ran quizzes as PDFs and email. Instructors had no clean authoring path. Students could not see which topics they owned versus which ones kept failing them. Timing was manual. Feedback arrived late or not at all. Practice felt like paperwork instead of a loop you can improve.

When something broke in the browser, support had little to go on. Without session replay and API error tracking, flaky quiz submits turned into he-said-she-said tickets. The platform needed reliable attempt storage, clear mastery views, and observability so QA and ops could catch scoring or timer bugs before a class sat down for a live assessment.

Scoring edge cases piled up fast. Partial attempts, refreshed tabs, and late submits all needed clear rules. Without solid attempt storage and API error tracking, instructors lost trust after one bad session. Students also needed profiles that told a story over time, not a single percentage that hid weak topics.

Support tickets often sounded like product bugs when they were really missing session context. Without LogRocket, a student saying "it froze" left engineering guessing. Without Sentry, API timeouts looked like random bad luck.

Solution

We built a React frontend and an Express API on EC2. RDS PostgreSQL stores questions, attempts, and profiles. Amazon S3 holds attachments, diagrams, and avatars. LogRocket captures frontend sessions. Sentry tracks API errors. The web app deploys on Vercel.

Students take timed multiple-choice quizzes with immediate feedback. Profiles show topic mastery and past scores. Instructors draft and publish assessments in the Question Creator. Session replay and error tracking sit in the same delivery pipeline so a broken submit or a scoring edge case is easier to reproduce.

The Question Creator sits beside the learner path so publishing does not require an engineer. Attachments and diagrams load from S3 inside the quiz UI. LogRocket and Sentry close the loop when a timer or submit misbehaves. That is the difference between a fixable bug and a lost class period.

Profiles tie attempts back to topics so remediation is specific. A student who keeps missing one cluster of questions gets a clear signal. Instructors can publish a follow-up set from the Question Creator without waiting on a content engineer.

Architecture

The React app on Vercel talks to Express on EC2. PostgreSQL on RDS stores question banks, published assessments, timed attempts, and profile mastery aggregates. Diagrams and other media go to Amazon S3 and are referenced from question records.

During a quiz, the API enforces timing and records answers as the attempt progresses. Results and mastery views read from those attempt rows, not from a separate spreadsheet. LogRocket records client sessions for hard-to-reproduce UI bugs. Sentry captures API exceptions so a failed submit or a scoring error surfaces with a stack trace. In EdTech, a broken timer during a live class is a trust problem, not a minor defect.

Express on EC2 keeps attempt writes close to PostgreSQL. Vercel hosts the React clients so instructor and student UIs can ship on a short cadence. Mastery aggregates stay queryable from attempt history instead of a separate analytics warehouse. The first version stays honest and operable for a school team without a data engineering bench.

Attempt rows are append-heavy by design. We optimize for honest history over clever rewriting. Mastery views are harder to game and easier to explain when a grade is questioned after class.

Security and access

Timed attempts write answers through the Express API into PostgreSQL so scoring follows recorded attempt rows, not a client-only timer. Admin authoring stays in the Question Creator behind instructor access, which keeps the question bank off casual student accounts.

LogRocket captures frontend sessions when a submit or timer misbehaves. Sentry tracks API exceptions. Together they help ops reproduce integrity issues without guessing from student reports alone.

Key features

• Timed MCQ quizzes with immediate feedback
• Profiles that show topic mastery and past scores
• Question Creator for drafting and publishing assessments
• Diagram and attachment storage on Amazon S3
• LogRocket session replay for frontend issues
• Sentry error tracking on the Express API

Results

• Timed MCQ quizzes with immediate feedback
• Profiles that show topic mastery and past scores
• Question Creator for drafting and publishing assessments
• Session replay and error tracking when something breaks

Product screens

Technology stack

Related services

• Web & Mobile DevelopmentReact, Next.js, Flutter, or React Native apps fast enough for daily use and solid enough to grow.
• QA & SecurityAutomated tests, performance checks, and security-minded QA so fewer surprises show up late.