Work / Hackathons
AeroBites
V1 of my campus drone-delivery idea: a React ordering app plus an AWS Bedrock agent back end, written as IaC.
- React 18
- Tailwind CSS 3
- TanStack Query 4
- Serverless Framework 4
- AWS Lambda (Node.js 18)
- DynamoDB
- S3
- Amazon Bedrock (Claude 3 Sonnet)
- Microsoft AirSim
TL;DR
- Where the drone-delivery idea started: at SCU ACM’s AWS x INRIX Hack in October 2025, my five-person team set out to let UC Santa Cruz students order dining-hall food by drone.
- I authored 13 of the team repo’s 18 commits, including every commit that changed code: the app, the menus across 20 dining locations, order tracking, the delivery map and the chat assistant.
- We had no drone, so I flew one in simulation. Three months later I rebuilt the concept on live data as SlugBites, and our team won two awards with it.
The problem
Campus dining is a walk away from where students actually are, and a sponsor event built around AWS and mobility data was a good excuse to ask what drone delivery would take: an ordering app, an agent that can take an order in plain language, and a way to show a flight.
What I built
- App. React 18 with Tailwind and TanStack Query: menus with dietary filters, a cart with a dorm selector, order history, an order tracker and a delivery map.
- Back end as code. An AWS architecture written in Serverless Framework: four Lambda HTTP functions (an AI agent, recommendations, natural-language ordering and a Bedrock agent), a DynamoDB table for agent memory keyed by hash and range, and an S3 knowledge-base bucket.
- Agent. A Bedrock function that wraps Claude 3 Sonnet in an ordering persona.
- Simulation. On the final morning I stood up Microsoft AirSim’s prebuilt Unreal Engine environments, flew a quadrotor by hand with RGB, depth and segmentation views, then launched AirSim’s Neighborhood map and started a screen recording.
Key decisions
- Decision: infrastructure as code for the whole back end. Why: it is reviewable and reproducible from one file. Trade-off: it stayed undeployed at the event; the IAM setup was still outstanding.
- Decision: a mock data layer under the UI. Why: the app demos end to end without a deployed back end. Trade-off: the demo ran on mock menus, which is exactly what SlugBites fixed.
- Decision: show the drone in a simulator. Why: no hardware, and a real flight model beats an animation. Trade-off: manual flights, not autonomous delivery.
The hard part
Demoing drone delivery with no drone. The team had no hardware. In the last hours I set up AirSim’s Unreal Engine environments on my own machine and flew a quadrotor with multi-camera sensor views, then switched to the Neighborhood map and started a screen recording 46 minutes before the team’s final commit.
What I learned
AeroBites’ back end stayed undeployed and the UI ran on mock data. Both became the brief for round two: SlugBites scraped real menus and ran its own API from day one, and six weeks after that I was flying scripted missions from a web console in Riptide.
What I’d do next
This version is archived; the idea continued in SlugBites and Riptide.
Links
- Code: github.com/versean/AeroBites (team repo)
- Devpost: AeroBites
- Round two: SlugBites · Round three: Riptide
Verified numbers
| Metric | Value | Source |
|---|---|---|
| Team-repo commits I authored, including every commit that changed code | 13 of 18 | github.com/versean/AeroBites/commits |
| Lambda functions, DynamoDB tables and S3 buckets defined as infrastructure-as-code | 4 · 1 · 1 | versean/AeroBites/serverless.yml:31-86 |
| Submissions at the event (257 participants) | 38 | aws-inrix-hack-2025.devpost.com/ |