To enter a contest, I made a document summarizing the submission requirements myself. A completely ordinary tracking sheet: each requirement written out, with its status next to it.

It had 3 errors.

And because I was making decisions based on that doc, I only noticed the mistakes when I read the primary source (the official rules) directly.

Error 1: Another app’s design had crept in

The doc said this:

Option A (free trial): A 3-day trial is already set up for premium

Based on this, I had concluded that “judges can try premium for free.”

It wasn’t set up.

What it cited as evidence was the billing design of a different app (the queue prediction app). I was building 3 apps in parallel, and they got mixed up when the doc was written.

There were 2 ways to check, and each took minutes.

# 1. Search the code
grep -rniE "トライアル|trial|introductory|無料期間" lib/
# → 0 hits. The paywall doesn't even have logic to display a trial

(The pattern includes the Japanese words for “trial” and “free period.”)

The second was the Play Console screen. In the subscription product list, the “Offers” column showed –. In Play’s current model, a free trial is attached to a base plan as an “offer.” No offers = no trial configured. That settled it. I checked both monthly and yearly.

In the time it took to read a doc that said “already set up,” I could have just looked at the real thing and been done.

Errors 2 and 3: Video length and screenshot resolution

The same doc had 2 more.

  • The video length it listed didn’t match the actual requirement
  • The screenshot resolution was listed as 1179×2556

The second one is the iPhone 15 Pro’s resolution. Google Play’s rule is “the long side must not exceed twice the short side,” and 2556 ÷ 1179 = 2.168, so it violates the rule. It had been confused with the App Store requirements and left in the instructions that way.

2 of the 3 errors came from something from another platform or another app getting mixed in. When you run multiple projects in parallel, this kind of contamination happens.

The big one: nobody had looked at the dates

This was the heaviest.

The promo codes for judges had already been issued. Quantity 2,000, valid until September 30, 2026. It was checked off in the tracking sheet as “ready.”

I went and read the official rules directly, and here’s what they said:

Judging Period:
  Thursday, October 1, 2026 – Tuesday, October 13, 2026

Judging starts October 1. The codes expire September 30. Not a single day overlaps.

The codes existed, there were enough of them, they were properly published, and they were completely unusable.

Something more important I found along the way

Reading the same official rules, I found 2 more things.

First, the original wording of the requirement is this:

the app must either offer a free trial or the Entrant must include a promo code for judges to unlock the in-app purchase and test all premium features

A trial or a promo code. Either one is enough. My own doc was written as if both needed to be prepared.

Second, and this one really mattered:

Judges are not required to test the Project and may choose to judge based solely on the text description, images, and video provided in the Submission.

Judges can choose not to touch the app at all. It explicitly says they may judge on the description, images, and video alone.

Providing a way to access the app is a required item, so I’ll still prepare it. But the priorities changed. Instead of fixing billing bugs “so judges can try it,” the framing becomes “we’re launching publicly and charging real users, so of course it has to be fixed.” And the time goes into polishing the demo video and the description.

Meeting the requirements and getting a good evaluation were separate jobs.

Why I didn’t notice

The reason is clear. The doc looked just like the real thing.

The tracking sheet lists the requirements, the status column is filled in, and there are even links to the evidence. The better made a doc is, the less reason you feel to go look at the real thing. You read it assuming “the research is already done and it’s all here,” so the idea of re-checking never comes up.

And we wrote this doc ourselves. I’d have been skeptical of outside information, but I didn’t doubt a summary I’d made myself.

What I decided

Decisions about requirements always go back to primary sources. Internal docs are used only as an index of “where to look.”

Specifically, I started writing a source URL and a date checked on each row of the doc.

- Video must be 2 minutes or less (source: https://... / checked 2026-08-15)

A row with an old check date is a signal that you must not base a decision on that row.

And “done” checkmarks include dates. Not “promo codes issued” but “promo codes issued (valid August 17 – January 31, 2027).” When there’s a field for the validity period, you have a reason to cross-check it against the judging period.

Lessons

A summary is only as correct as your understanding at the moment it was written.

What scared me more than my doc being wrong was that there was no mechanism for checking whether it was right. Each of the 3 errors could have been verified in minutes. They weren’t verified because nobody thought they needed verifying.

My tracking sheet now has a “date checked” column.

In the same “would have taken minutes to check” category, I’ve written about judges being unable to open the app and all my terms pages returning 404. All the places you can trip up when publishing to the store are collected here.