Build with AI Hack Days: Top 4 with DropSafe AI

On Friday, August 7, 2026, I competed in Build with AI Hack Days at Southeast University and finished in the top 4, earning a $50 Google gift card through MLH. The project I brought to the event was DropSafe AI, a checkout protection engine designed around a very practical Bangladesh e-commerce problem: risky last-mile delivery instructions before dispatch.

The challenge

Build with AI Hack Days pushed participants to build working AI-powered products, not just polished ideas. That format suited DropSafe AI well because the product only makes sense when it can evaluate a checkout request in real time and return a concrete action.

The core problem is simple: merchants and couriers often receive vague delivery notes such as "leave at gate", "front steps", or "no one home". If the item is expensive and the handoff is unattended, that one line of text can create a refund, a dispute, a lost parcel, and a confused courier.

I wanted the demo to turn that ambiguity into a safer delivery plan.

What I built: DropSafe AI

DropSafe AI evaluates a Dhaka delivery request before the order is placed. It looks at address details, property type, item value, delivery window, delivery notes, drop-off type, and optional product metadata, then returns a risk level with safer handoff recommendations.

The important part is that the checkout decision is not left to a vague AI answer. A deterministic TypeScript risk engine calculates the score and risk tier first. If GOOGLE_GEMINI_API_KEY is configured, Gemini Search Grounding can add current web context, search queries, citations, and clearer courier instructions, but it cannot override the fixed score or level. That made the demo stable enough for judging while still using AI where it adds value.

The product flow is:

1. A customer selects a product and enters delivery details.
2. The checkout calls the risk assessment API.
3. DropSafe validates the request, looks up a small Bangladesh area-context table, and calculates a deterministic score.
4. The API returns a low, medium, high, or critical delivery risk with reasoning, source type, timestamp, safer alternatives, and rewritten instructions.
5. If the result is marked as needing intervention, the customer must choose a safer option before placing the protected order.

The demo moment

The strongest part of the demo was showing contrast.

A secure office delivery with a signature handoff can continue almost instantly. A front-gate or unattended front-steps delivery for a high-value item triggers intervention and asks the customer to choose a safer alternative such as guard desk delivery, signature handoff, pickup counter, or evening handoff before placing the protected order.

That visual difference made the product easy to understand: DropSafe AI is not a chatbot bolted onto checkout. It is a pre-dispatch safety layer that helps merchants reduce avoidable delivery risk.

Why the top 4 result mattered

Finishing in the top 4 felt meaningful because this was not just a feature demo. It was a complete product slice with a real audience:

• merchants who need fewer refunds and disputes
• couriers who need clearer handoff instructions
• customers who want safer delivery without long support conversations
• small e-commerce teams that do not have enterprise logistics tooling

The $50 Google gift card through MLH was a nice reward, but the bigger validation was seeing the idea land with judges as a practical AI product rather than a generic model wrapper.

Lessons I am taking forward

• AI should support the decision, not replace the rules. The deterministic engine kept the demo explainable and predictable, while Gemini helped with context and language.
• Local context matters. A delivery safety product for Bangladesh needs different assumptions than a generic package-theft demo. Unknown addresses should fall back cautiously and rely on delivery details, not broad labels.
• Judges remember clear interventions. "This order needs a safer handoff" is easier to trust than "the AI thinks this looks risky."
• Responsible boundaries matter. DropSafe is not a police-grade safety feed or a final production risk model. It is a checkout decision support layer that needs privacy review, monitoring, validation, and data governance before real merchant use.
• A narrow product slice beats a broad unfinished system. The checkout-to-protected-order loop made the idea feel real.

What is next

DropSafe AI still has room to grow. The next steps are persistence, better merchant analytics, configurable risk thresholds, and more structured Bangladesh delivery context. I also want to keep improving the UX so safer alternatives feel like normal checkout choices, not scary warnings.

You can try the live project at dropsafe.moraladnan.me, view the project source on GitHub, and see the event page here: Build with AI Hack Days.

Top 4 is a strong signal. Now the goal is to turn that hackathon proof into a product that can actually help small merchants ship safer.