Submission Lens

• 

• 

• 

• 

• 

Inspiration

I’ve submitted several projects to hackathons, and I’ve learned that finishing the app is only part of the job.

Submission rules often include deadlines, repository requirements, demo videos, licenses, required files, and other details spread across long pages of text. Even when the project itself is finished, it is easy to miss one small requirement.

I already used my own pre-submission checklist, so I wanted to explore whether AI could turn event-specific rules into a checklist automatically while keeping general submission safety checks separate.

What it does

Submission Lens turns pasted hackathon rules and submission requirements into an actionable checklist.

The user pastes the rules and clicks Analyze. The app extracts organizer requirements such as:

• deadlines
• deliverables
• repository requirements
• video requirements
• eligibility conditions

Each organizer requirement includes the source excerpt it came from, so the user can verify the result against the original text.

If the wording is ambiguous, the item is marked Needs review instead of being presented as a definite requirement.

Submission Lens also shows a separate set of general Submission Safety Checks, including checking public URLs while logged out, repository visibility, exposed secrets, builds and tests, licenses, and final submission links.

The two sources are deliberately kept separate: organizer requirements come from the pasted rules, while safety checks are general recommendations.

How I built it

I used a plan-first workflow before writing the application.

I first defined the project scope, then created a PRD and technical specification, and only then implemented the proof of concept.

The frontend uses Vite, React, and TypeScript. The application is deployed as a Cloudflare Worker with Static Assets.

The Worker sends pasted rules to Gemini through the Interactions API and requests schema-constrained structured output. The response is then validated by the application before it is returned to the browser.

I did not want to trust the model output by itself, so Submission Lens also verifies that each returned source excerpt actually appears in the pasted rules. If the excerpt cannot be verified, the item is marked Needs review and the unverified quotation is not shown.

No database or account system is used. The current checklist exists only for the active browser session.

Challenges

One challenge was deciding how much to trust AI-generated structured output.

A JSON schema can constrain the shape of a model response, but it cannot prove that the model interpreted the source correctly. This led me to add runtime validation and source-excerpt verification as a second layer.

Another challenge was model availability. During development, Gemini 3.8 Flash repeatedly returned temporary high-demand errors. I kept the model configurable, moved the project to Gemini 3.6 Flash after testing it successfully, and later added one retry for temporary HTTP 503 capacity failures.

This reinforced an important lesson: external AI services should be treated as dependencies that can fail, even when the application itself is working correctly.

What I learned

The biggest lesson was the value of a plan-first workflow.

Defining the MVP and explicitly deciding what not to build helped keep the project small. I avoided accounts, databases, PDF parsing, URL scraping, browser extensions, notifications, and other features that were not necessary to prove the core idea.

I also learned to separate deterministic testing from live AI testing. Validation failures, malformed responses, source mismatches, and input limits are tested with fixed fixtures instead of depending on a model to reproduce those cases.

The result is a small proof of concept that does one thing end to end: turn long submission rules into a checklist that is easier to verify and act on.

Built With

• cloudflare
• gemini
• react
• typescript
• vite
• workers
• wrangler