Aerogami

Inspiration

Everyone has folded a paper airplane, but almost nobody knows why one plane glides across the room while another nosedives. We wanted to turn that childhood experiment into something you can actually learn from: tweak a design, watch the physics play out, and get feedback on what to change.

We also had a personal reason to build it. One of our teammates is an aerospace engineer, and the questions that come up when folding a plane are the same ones that come up in real aircraft design: where the center of gravity sits, how wing shape affects lift and drag, and why a plane stalls. With so many aerospace engineering majors at our school, we realized Aerogami could be more than a toy. It could be a quick, hands-on way for students to build intuition for stability and aerodynamics before they ever open a textbook or a simulation suite.

What it does

Aerogami lets you design a paper airplane, set your throw speed and angle, and watch it fly through a 3D sky. You can turn wind on or off to see how conditions change a flight, replay any throw, and compare two flights side by side to see exactly where they split apart.

An AI coach powered by Google Gemini looks at your design and your flight and explains what happened in plain language, then suggests specific changes to try. If you’d rather not tune by hand, Auto-tune searches for a better design for you. Your best throws go on a shared leaderboard, and every flight’s telemetry is saved so you can chart altitude, speed, and distance over time.

How we built it

The frontend is plain JavaScript with a custom canvas renderer and our own flight physics, written from scratch rather than pulled from a library. The backend is Node and Express, and it keeps our API keys and database credentials off the client.

Google Gemini powers the coach, returning structured advice we can show in the interface. MongoDB Atlas stores the leaderboard and saved designs. Tiger Cloud, which is Postgres with TimescaleDB, stores time-series telemetry for every flight, and we use time bucketing to downsample it for replay and comparison. If the database is ever unreachable, the app falls back to in-memory storage so the simulator keeps working.

We deploy to a Vultr server running pm2 and nginx, and the site auto-deploys from GitHub every minute, so the live version always matches our latest work.

Challenges we ran into

The hardest part was keeping the physics stable. Small changes to lift, drag, or pitch behavior could quietly turn a good glider into a brick, so we locked baseline flight distances into tests to make sure no change could silently break how planes fly.

Deployment brought its own surprises. Partway through the hackathon, the Gemini model we started with was retired, and we had to switch models and update the coach. Right after deploying, planes wouldn’t launch at all. We traced it to a browser API that only works over HTTPS and wrote a fallback so the app works in either case. Getting the time-series telemetry bucketed correctly in TimescaleDB also took several attempts before replay and comparison lined up.

Finally, several of us were pushing to the same files at once, so merging audio, UI, and feature work without losing anyone’s changes turned out to be a challenge of its own.

Accomplishments that we’re proud of

We built the full loop from design to throw to feedback to a better design, and we’re proud that it holds together end to end. A player can fold a plane, fly it, compare it against an earlier attempt, ask the coach what went wrong, and try again.

Under that loop is a real time-series telemetry pipeline, flight replay and comparison, and a live site that deploys itself, all built in a single hackathon. We’re also proud that the physics behaves the way a real plane does: long, narrow wings glide farther, a nose-heavy plane dives, and a badly balanced one stalls.

What we learned

We learned how paper airplanes actually stay in the air, including how the balance between the center of gravity and the center of lift decides whether a plane flies smoothly or tumbles. We also learned how to store and query time-series data, and how to get useful, structured advice out of an LLM by giving it real flight data instead of vague prompts.

On the engineering side, we learned how to deploy and harden a server from scratch, and how to keep a team’s work from colliding when everyone is shipping at the same time.

What’s next for Aerogami

Our next step is making Aerogami a proper teaching tool for aerospace students. We want to show real quantities like static margin, aspect ratio, and lift-to-drag ratio alongside each flight, so students can connect what they see to the equations from class. We’d also like to let people snap a photo of a real folded plane and have the AI estimate its dimensions so they can test it in the sim, and add more fold templates and wind conditions.

Beyond that, we’d like to add head-to-head challenges, so classmates and clubs can compete on distance or accuracy with their own designs.