DropHelp

Neighbours helping neighbours — DropHelp turns messy requests into safe, private, actionable help exchanges.

Comment

Inspiration

We wanted to build something meaningful—an app that could help people look after one another in the real world.

The original idea came from a simple principle: helping people access essentials such as food, clothing, water, transport, or practical support when they are struggling. We were also thinking about older people and others who may have limited mobility, limited budgets, or no easy way to ask nearby neighbors for help.

That led us to a more focused question: how can neighbors coordinate small, useful acts of assistance without forcing people to expose their private contact details or navigate an intimidating system?

DropHelp is our first answer. It is designed around dignity, safety, and practical community support—making it easier for someone to ask for help and easier for someone else to respond.

What it does

DropHelp helps a requester create a help request using an AI request coach. The coach can clarify the request, identify safety boundaries, and suggest a clearer version that the requester reviews and approves.

Low-risk requests can be automatically approved. Uncertain or higher-risk requests are sent to an AI-assisted moderation triage flow where a moderator makes the final decision.

Once approved, a neighbor can discover and claim the request. The two people can coordinate through matched chat and lifecycle updates without exposing private contact details. The app also includes trust, access, moderation, and recognition foundations for future releases.

How we built it

The most important part of our build process was using Codex with GPT-5.6 as an active engineering conductor, not just as a code autocomplete tool.

Codex helped us understand the repository and specifications, break the work into waves, create implementation plans, coordinate isolated worktrees, delegate scoped tasks, review changes, resolve integration issues, run tests, verify browser workflows, and manage GitHub issues and pull requests.

We used RepoPrompt MCP heavily to assemble focused context from the repository—specifications, plans, source files, migrations, tests, and Git history—before planning or delegating work. This made it possible to give each task the right context without repeatedly loading the whole project.

Some implementation and review work was coordinated between GPT-5.6, Claude, and GLM 5.2. At different points, Codex acted as the orchestrator between those tools: it prepared focused prompts, compared their results, checked them against the project contracts, and brought the verified work back into the main branch.

The current in-app coach and moderation AI use GLM through a provider-neutral interface. GPT-5.6 was used through Codex to build, coordinate, review, test, and validate the project.

Challenges we ran into

Our biggest challenge was managing the scope and token budget. Once we had a working foundation, it was tempting to keep building wave after wave. We had to make difficult decisions about when to stop, what to leave for later, and which tasks were important enough to spend more context on.

At several points, I manually coordinated between the GPT-5.6 Sol orchestrator, Claude, and GLM to reduce duplicated work and save Codex usage. That made the workflow more complicated, but it also helped us keep moving when the available budget was tight.

Another challenge was making a partially completed product look coherent and polished enough to demonstrate. We spent significant time bringing the visual system, screens, moderation console, and demo flow together rather than presenting disconnected prototypes.

Accomplishments that we're proud of

We are proud of how much we got working in a very short time. We built and demonstrated the core request-to-help journey: coached request creation, automated approval for low-risk requests, moderator triage, volunteer claiming, matched chat, and lifecycle updates.

We also completed a large amount of work behind the demo, including privacy boundaries, trust and access controls, moderation safeguards, database authorization, accessibility improvements, and a reusable design system.

The project was tested with hundreds of automated tests, database checks, concurrency testing, rendered browser workflows, typechecking, linting, and independent review. Getting that much of the system working—and keeping it testable—was one of the most satisfying parts of the build.

What we learned

We learned that building with multiple AI systems requires strong coordination and clear boundaries. The models can move quickly, but they need focused context, well-defined tasks, and independent verification.

We also learned that AI should assist with clarity and prioritization without becoming the unchecked authority for safety decisions. User approval, deterministic policy, server-side authorization, and human moderation all need to remain explicit.

What's next for DropHelp

The full roadmap has nine waves, although only the first three are part of the hackathon target.

Next, we want to expand trust and verification with vouching and restriction controls, then add recognition features such as ratings, impact rings, milestones, streaks, and Anchor status.

Later waves would add stronger safety operations, including no-show sanctions, safety reports, and advisories; AI-assisted chat safety and translation; multi-provider AI failover and semantic ranking; and eventually production features such as precise location, retention controls, forecasting, push notifications, and app-store deployment.

Built With

Share this project:

Updates