• ## Inspiration

Our inspiration as a team was security camera doorbells, especially products like Ring. We kept coming back to the same idea: there should be a free, flexible version that works with any camera, reacts immediately, and doesn’t lock people into one expensive hardware ecosystem. We wanted Peep to feel like a smarter neighborhood safety layer, not just a static camera feed. Instead of only recording what happened, we wanted it to detect what matters and do something useful right away.

## What it does

Peep is a live, agentic camera system that can connect to a camera feed or use your phone/computer camera. It watches for package-related events, like a package arriving, being taken, or never showing up at all, and then routes that event into the right action automatically. If a package is stolen, Peep can kick off a refund workflow. If something looks suspicious, like loitering, multiple people hanging around, a weapon, after-hours activity, or even an animal, it can turn that into a security alert instead of just leaving it as raw footage.

It also includes an inbox flow that checks expected deliveries, so Peep can tell the difference between “nothing happened” and “the package should have arrived but didn’t.” On top of that, there’s a community feed where neighbors can share alerts, discuss what’s happening in the area, report issues, and post lost-and-found updates. The goal is to combine live monitoring, neighborhood communication, and automatic follow-up into one place instead of scattering it across separate apps.

## How we built it

We built Peep in Next.js and used Neon Postgres for the database. We also used Claude Code to help us move faster while building and debugging. Under the hood, the project is split into multiple pieces: a vision layer that detects events from the camera, an orchestration layer that decides what action to take, and an execution layer that carries out that action. That setup let us keep the system modular instead of hard-coding everything into one big flow.

We also built out supporting pieces like inbox parsing for delivery tracking, a security alerts store, a browser agent that can automate the refund flow, and a fraud-scan path for analyzing suspicious clips. That gave us a fuller prototype than just a camera demo, because the app can actually turn a detection into a downstream response.

## Challenges we ran into

One of the biggest challenges was figuring out how to reliably detect when a package was actually picked up from the camera view. That sounds simple, but in practice it’s hard to know whether something disappeared because it was taken, because the camera lost sight of it, or because the scene changed in some other way. We also ran into a lot of bugs while wiring together the different pieces of the system, especially since the app had multiple workflows and agents all interacting with each other.

Another challenge was making the system behave intelligently without becoming noisy. We had to think carefully about false positives, timing thresholds, and when the app should actually take action versus when it should stay quiet. That made the debugging process a lot more involved than a basic camera app.

## Accomplishments that we’re proud of

We’re proud that this was one of our first hackathons and that we still chose such an ambitious idea. We built something that doesn’t just detect an event, but can also reason about it, decide what to do next, and carry that action through. That made the project feel a lot more complete than a simple prototype.

We’re also proud that we did this with teammates we had never met before and still managed to collaborate well. We learned a lot, adapted quickly, and kept the project moving even when things got messy. Most importantly, we had fun while building something that actually feels useful.

## What we learned

We learned that it’s much better to prepare for the worst at the start, because once code starts breaking, you need a clean structure to recover quickly. We also learned how important it is to separate a system into layers: detection, decision-making, and execution. That made it easier to debug and reason about the app.

We also learned a lot about working as a new team under time pressure. Hackathons move fast, and if you don’t keep your scope tight and your system modular, it becomes very hard to recover when something breaks.

## What’s next for Peep

Next, we want to keep adding on to everything we already have. That means making package detection more reliable, improving the inbox and delivery flow, and making alerts even faster and more accurate. We also want to keep expanding the community side so neighbors can communicate more naturally, share verified alerts, and build trust around local incidents.

We’d like to make the automation even stronger too, so Peep can handle more workflows beyond refunds and security alerts. That could mean better reporting, smarter moderation, more device support, and deeper integration across mobile and web. The long-term goal is for Peep to become a real-time neighborhood safety platform that doesn’t just watch problems happen, but helps respond to them immediately.

Built With

Share this project:

Updates