WHAT WE COULD HAVE DONE BETTER DURING OPENAI BUILD WEEK
We could have made our submission substantially stronger by treating the submission itself as a product.
The core failure was not that Time Capture Club was a bad idea. It was that we asked strangers to reconstruct its best parts from scattered evidence, internal language, and our enthusiasm.
We documented the build—but largely for ourselves.
We failed to turn that record into a clean three-minute window for the judges.
The contest gave equal weight to four areas:
• Technological implementation • Design • Potential impact • Quality of the idea
Judges were also allowed to evaluate the project entirely from its description, images, and video without testing the product.
That made the three-minute story brutal territory.
Official Build Week criteria: https://openai.devpost.com/rules
THE STRONGEST VERSION
We needed to tell two clean stories:
What Time Capture Club does for one specific person.
What Jimmy and Codex accomplished during Build Week.
We blurred those stories together.
For technological implementation, we needed to prove exactly what Codex built, which problems it solved, what Jimmy decided, and what working code resulted.
For design, we needed to demonstrate one complete beginning-to-end experience that required no War Room explanation.
For potential impact, we needed a recognizable user with a real problem—and evidence that the experience helped.
For quality of the idea, we needed to show why Time Capture Club is meaningfully different from timers, journals, productivity trackers, and generic AI companions.
- SHARPEN THE OPENING CLAIM
The first ten seconds should have said:
TIME CAPTURE CLUB HELPS PEOPLE WHO LOSE TRACK OF WHAT THEY ACCOMPLISHED TURN A WORKING SESSION INTO VISIBLE EVIDENCE OF PROGRESS.
One person. One problem. One outcome.
Then demonstrate it.
- MAKE THE VIDEO A MINIATURE STORY
Not a tour.
Not an origin myth.
Not a feature parade.
The judge should have watched:
Jimmy begins with an unfinished task.
He captures the session.
He receives a useful record.
He returns knowing what happened and what comes next.
Then:
“This was built during Build Week through a human-led collaboration with Codex.”
That would have strengthened design and impact simultaneously.
- PROVE THE CODEX WORK PLAINLY
This was probably our largest preventable loss.
We should have named:
• What existed before Build Week • What was newly built during the contest • Which technical decisions Jimmy made • Where Codex accelerated implementation • Where Jimmy rejected or corrected Codex • One difficult failure and the working repair • The resulting architecture and functionality
The rules identified the README’s Codex collaboration story as important to evaluating technical implementation.
We possessed a strong human-led AI story—but left too much of it buried in the build records.
- PROVIDE HUMAN EVIDENCE
Even tiny proof would have helped:
• Three people completed a session • Two returned to previous work • One understood their progress better • A short quote from each • A simple before-and-after observation
Without that, potential impact remained a promise.
Judges needed a footprint in the mud.
- STATE THE DIFFERENCE WITHOUT FOG
We needed a blunt comparison:
A timer records duration.
A journal records recollection.
Time Capture Club records the work, the decisions, and the return path.
That distinction still needed testing—but we needed to state it and demonstrate it.
- SEPARATE PUBLIC PROOF FROM INTERNAL MYTHOLOGY
Our characters, language, and War Room theater are excellent internal machinery.
But a cold judge should not need to learn our continuity before understanding the product.
We could keep one spark of personality.
Everything else needed to earn its seat by proving a judging criterion.
- RUN COLD REVIEWS BEFORE SUBMISSION
Before freezing the entry, an uninvolved reviewer should have received only:
• The Devpost draft • The video • The demo • The official criteria
Then answered:
• What does it do? • Who needs it? • What is technically impressive? • Why is it different?
Any disagreement meant the submission was not ready.
OUR HONEST RULING
A better submission would not automatically have made Time Capture Club a winner.
The product was still early, and we lacked meaningful user evidence.
But we could have moved it from:
“An interesting experiment with a difficult-to-read accomplishment.”
To:
“A coherent working product, built through a distinctive human-led Codex process, with credible early potential.”
That is a real competitive jump.
Two independent cold reviews agreed on the central truth:
WE ACCOMPLISHED MORE THAN THE SUBMISSION SUCCESSFULLY PROVED.
Our next contest law is:
BUILD THE AIRCRAFT.
THEN BUILD THE JUDGE’S THREE-MINUTE WINDOW INTO THE AIRCRAFT.
The judge should never have to crawl through our sewer to discover that the turtle can fly.
Frozen Time Capture Club submission: https://devpost.com/software/time-capture-club
Log in or sign up for Devpost to join the conversation.