Student presentations put the whole class in front of the same work at the same time. That makes them unusually rich feedback moments: everyone is watching, comparing, reacting, and forming judgments teams rarely get to see while the work is still fresh.
Students notice what lands, what confuses them, which teams feel investable, and where the story breaks down. When that feedback comes back quickly and clearly, it changes how teams understand their own work. When it arrives a week later as a pile of comments, the learning moment has already cooled off.
The feedback was valuable. The workflow slowed it down.
My old system was just a Google Form. Students could submit peer reviews, and the form could collect hundreds of responses during class. It worked okay.
The slow part came after class: sorting the spreadsheet, looking for class-wide trends, deep-diving into each team, summarizing the written feedback, and then sending the right results to the class and to each team. Every presentation created 2-4 hours of manual work before students could get use out of the feedback.
When feedback is delayed, students lose the chance to apply what they've learned to future assignments and presentations.
Before Plause
2-4
hours
manual analysiseach presentation
]In under 24 hours, Plause was in a real class.
I used Codex to build the first prototype and put it in front of my students during their final pitches. It was rough, and the UX had places to improve, but it worked.
Between skills like Craft, agents working from docs, and my own experience building software and products, the prototype became a working platform with rich features like Duke SSO, a real database, response collection, permissioned results, deterministic analytics, and AI-generated summaries.
Using it with real presentation feedback gave the next version a map. Students submitted real feedback, teams could receive useful results, and I could see which parts of the workflow needed more polish.
I could move fast and keep the codebase clean.
Once the first version worked, the next job was to keep shipping without turning the codebase into a pile of experiments. I used Codex to break the build into focused workstreams: auth, results, release safety, data handling, and UI/UX polish.
That made the speed useful. I could make clean commits, keep PRs small, write helpful descriptions, pull documentation into the work, test in the browser, and keep a Git history that still made sense the next morning.
Threads
One conversation per workstream.
Each thread could stay focused on one slice of the product, which kept the work moving without turning every decision into one giant context pile.
Focused workstreams
Reviewer flow
questions, progress, submission state
Trusted access
Duke SSO, Google, signed sessions
Results
Data
Polish
Release
As Plause grew, testing by memory stopped being good enough. I added an internal QA checklist for the flows most likely to lose work, leak access, or blur release state, with progress, failures, notes, and a copyable summary for each run.
Plause grew into the full feedback loop.
Plause now handles the parts that made the old workflow hard to sustain: access, team membership, releases, result visibility, charts, and AI-assisted summaries.
For instructors, the analysis and distribution work can happen in one place. For students, feedback comes back while the work is still fresh, with repeated patterns instead of isolated comments and next steps they can actually use.
Engagement
Students listen differently when their feedback has somewhere useful to go.
Peer learning
Plause helps students see what their peers noticed, valued, and wanted clarified.
Action
Patterns, signals, and summaries make the next presentation easier to improve.
Building momentum with modern tools.
The arc of Plause shows how quickly the right tools and real feedback can solve problems that make a difference. Starting from a concrete classroom challenge, I was able to map needs to features and put working solutions in students' hands almost as fast as new pain points emerged.
Moving at that pace only worked because I could shape, test, and polish fast without compromising code quality or clarity. I used Codex as a force multiplier — accelerating implementation, supporting intentional design, and helping me establish a strong habit of tight feedback loops. Each release responded to real student needs, so progress was tangible, immediate, and genuinely meaningful to everyone using it.