Lenny Roasts

Main Page - Knight Hacks Location UCF ENG2
Hackathon Award Ceremony - Knight Hacks SU Cape Ballroom
Hackathon Building, Workshops and Judging - Knight Hacks ENG 2 Atrium
Hackathon Building, Workshops and Judging - Knight Hacks ENG 2 Atrium
Hackathon Breakout Room Judge Pitch Overall - Knight Hacks ENG 2 Class room
Hackathon Breakout Room Judge Pitch MLH - Knight Hacks ENG 2 Class room
Designing with Figma Make Second Prototype
Designing with Figma Make Initial Prototype
Designing with Figma Make Second Prototype from Above
Figma Main Page with Dashboard Design and Plan Later implemented
Figma Dashboard Design for Pitch Later Implemented

Inspiration

We were brainstorming ideas, researching them, and even starting to build one before realizing it probably wasn’t worth pursuing. By then, we had already spent part of our hackathon finding out what we wished we had known earlier.

That made us wonder: what if we could get a rough feel for the competition and judging before committing to an idea? Would our project stand out? Does it actually fit the sponsor track? Is the pitch hiding a weak idea behind nice wording?

That’s where Lenny Roasts came from. We wanted a place to test an idea, hear the uncomfortable feedback early, and give it another shot while there was still time to change direction.

What it does

Lenny Roasts turns your hackathon idea into a practice submission. You describe your project, choose your sponsor tracks, and let Lenny evaluate it against a simulated field of competitors.

You get scores, category eligibility, a placement range, rival projects, and suggestions for improvement. The experience takes place in a 3D UCF setting, with sponsor classrooms, Lenny hosts, and a simulated awards ceremony.

The placements are practice results, not predictions of who will win. The goal is to help you spot weaknesses and make better decisions before the real judging starts.

How we built it

We split the work into three parts: preparing the competition, building the judging backend, and creating the frontend.

We used past public Devpost projects as seeds and GPT-6 Luna through Codex to create variations for our simulated field. Our final field contains 106 accepted projects.

Qwen3-32B, served through Hugging Face and DeepInfra, evaluates both those competitors and new user submissions. Each applicable category gets three scoring runs, and our code calculates the averages, eligibility, and rankings. We keep the judging settings consistent so users and competitors are compared on the same basis.

The backend uses FastAPI and Neon PostgreSQL. The frontend uses React, TypeScript, Vite, and Three.js to bring the campus, classrooms, and ceremonies to life.

Challenges we ran into

Our biggest challenge was deciding which tracks we could simulate fairly. We wanted to include more, but had to leave out NVIDIA, AMD, OneEthos, Figma, Adobe, and others.

Some tracks involved hardware, where a written submission alone cannot show whether something actually works. Others depended heavily on the UI or design, which our text-based judge could not properly assess. For some sponsors, we also couldn’t find enough past hackathon examples to understand their judging expectations or build a useful field of simulated competitors.

That limited our scope more than we expected. Each track needed enough context to guide the judge and enough relevant projects to make the comparison useful. We focused on the categories we could support with the data and evaluation approach we had.

Accomplishments that we're proud of

We’re proud that we turned a problem we were experiencing ourselves into a working practice tool during the hackathon.

We built and scored a 106-project simulated field, connected real Qwen evaluations to our backend and database, and verified the submission-to-report flow locally.

We also gave the project a setting that feels like our own hackathon. Walking through UCF, pitching to Lenny in a classroom, and watching a practice ceremony made the experience much more personal than a plain score dashboard.

What we learned

An idea deserves more than one enthusiastic conversation before implementation. Looking at it from the user’s perspective, the sponsor’s requirements, and the competition can reveal problems that brainstorming alone misses.

We learned how to work with open-source models more effectively: test model choices on concrete cases, give them clear rubrics, keep responses manageable, and check what they return.

We also learned that valid JSON can still contain bad judgment. Getting the format right was only the beginning; we had to question the scores and explanations too.

What's next for Lenny Roasts

We want users to revise a pitch and compare versions, so they can see how their changes affect the feedback.

We also want to support more hackathons with their own tracks and competitor fields. The biggest next step is comparing our evaluations with feedback from real judges. That would help us understand where Lenny is useful, where it is too generous, and where it still misses the point.