Winning 3rd Place at Microsoft's Global Hackathon

Hackathons compress everything I enjoy about engineering into a tiny, unreasonable window: urgency, ambiguity, technical experimentation, product instinct, and just enough chaos to make normal constraints disappear. At Microsoft’s Global Hackathon, that energy turned into Local BizChat, a project that ended up winning 3rd place globally. The award was surreal, but what stayed with me more was how clearly the experience showed me what good product-building feels like under pressure.

The idea: AI for local businesses, but private by default

The problem we cared about was simple. Small businesses are curious about AI, but many of them do not want the default experience to be “send your customer and business context to the cloud and hope that’s fine.” We wanted an assistant that felt modern and capable without making privacy a tradeoff.

That is how Local BizChat took shape: an assistant for Copilot+ PCs that could help local businesses reason over their information, answer practical questions, and do it entirely on-device.

That last point was not a marketing bullet. It was the product thesis. No cloud calls. No hidden dependency on remote inference. No need to explain away data movement after the fact.

The technical stack forced honest product decisions

The core of the project used PHI-3 Silica SLM, a Windows Native Host, TypeScript, an Outlook add-in experience, and inference accelerated by the NPU. I loved that stack because it did not let us cheat. If the experience felt slow or awkward, we could not hide behind a giant remote model.

The architecture was roughly:

Outlook add-in UI (TypeScript)
    -> Windows Native Host bridge
    -> local business context + prompt assembly
    -> PHI-3 Silica on device
    -> NPU-accelerated inference
    -> response rendered back into workflow

That architecture made the privacy story real. It also forced us to be disciplined about prompt design, retrieval scope, and interaction design because local inference is a much stricter environment than infinite-cloud-thinking.

Building in 48 hours changes your priorities fast

I love long-form engineering, but there is something clarifying about a 48-hour build sprint. You stop pretending every problem deserves a perfect abstraction. You start asking sharper questions:

• What has to work for the demo to feel inevitable?
• What can be faked, simplified, or postponed without breaking the core truth?
• Which part of the product will judges remember five minutes later?

That kind of compression makes team dynamics incredibly visible. People naturally gravitate into roles. Someone keeps the narrative coherent. Someone protects the critical path. Someone keeps the UI from collapsing. Someone does the ugly but necessary glue work that nobody mentions in the final pitch but everybody depends on.

I really enjoyed that part. Good hackathon teams are not just collections of smart people. They are fast trust systems.

The moment the NPU demo worked felt different

I’ve had plenty of satisfying coding moments, but there was something uniquely fun about seeing the experience actually work on the NPU. The reason is subtle: when you watch a cloud demo, there is always a part of your brain that says, “Sure, but of course a big remote service can do that.”

Watching a local flow feel real on Copilot+ hardware creates a different emotion. It feels closer to product truth. You can imagine the user actually owning the experience rather than borrowing it from a server somewhere else.

That was the moment the project stopped being a nice concept and started feeling legitimate.

The science fair showcase was half the challenge

Microsoft’s hackathon showcase really does have a science fair energy in the best possible sense. People walk up curious but skeptical. They ask direct questions. They test whether your project is actually useful or just cleverly packaged.

I liked that environment because it rewards clarity. A good demo is not a feature dump. It is a compressed argument:

Why does this problem matter?

For us, it was business privacy and accessibility.

Why does this solution deserve to exist now?

Because on-device AI had become good enough to support a credible experience.

Why is the product meaningfully better than the obvious alternative?

Because privacy, responsiveness, and local ownership were features, not compromises.

That framing shaped our pitch as much as the code did. I think a lot of hackathon teams underinvest in narrative because they assume the implementation will speak for itself. Usually it doesn’t. Great products still need interpretation.

What I learned about team dynamics

The best part of the project was that nobody had time to be territorial. In a short sprint, status games are useless. What matters is whether the work moves. That tends to bring out a very healthy form of collaboration.

I noticed a few things during the build:

• people became more decisive because the clock forced tradeoffs
• communication got simpler because unnecessary detail was obviously expensive
• product and engineering stayed tightly coupled because there was no time for long handoff loops

I wish more normal projects preserved a little of that energy. Not the chaos, but the clarity.

Why the privacy-first angle mattered to me personally

I was especially drawn to Local BizChat because I think a lot of AI discourse defaults to scale-first thinking: bigger models, bigger clouds, bigger centralized systems. That is not the only future worth building.

There is something deeply compelling about AI that runs close to the user, respects their constraints, and still feels capable. For local businesses, “privacy-first” is not philosophical branding. It can be a very practical trust requirement.

Building something that made this idea tangible felt meaningful. We were not just talking about on-device AI as a trend. We were turning it into a product argument people could touch.

The award was surreal, but not the whole story

Winning third place globally was obviously exciting. I am not going to pretend otherwise. It felt validating, especially because hackathon environments are crowded with smart ideas and energetic teams.

But the deeper reward was seeing a concept move all the way from vague instinct to functioning demo in such a short time. That arc is addictive. You go from a whiteboard conversation to a thing that makes strangers stop, ask questions, and nod because they get it.

Looking back, Local BizChat reminded me that some of my favorite work lives at the intersection of systems depth and storytelling. You need enough technical credibility to make the product real, but you also need enough empathy to explain why anyone should care. The 48-hour sprint, the NPU moment, the science-fair pitch, and the eventual third-place finish all reinforced the same lesson for me: constraints do not only make engineering harder. Sometimes they make the idea sharper, the team better, and the product story finally honest.