devrives
ENKR

Meta Hackathon Retrospective: Lessons From 14 Winners, and Building Exits as Open Data

7 min read

TL;DR

  • 14 of more than 5,300 projects won a prize at the Meta hackathon, and my entry HereOut was not one of them.
  • Most winners used three to six Meta tools, gave the model a big job and checked its work with code. I gave one model a small job.
  • Gatekeeper, second in the indie track, caught 48 npm packages that were later confirmed malicious, a median of 25 hours before public lists, and anyone could check the times.
  • HereOut found about half the exits on plan photos from 14 countries and regions. If building exits were open data in one shared format, a phone would not need to read the photo.

I entered the indie track of the Meta Global AI Developer Hackathon with HereOut, and it did not win a prize. 14 of more than 5,300 projects won one, and reading them showed me where I went wrong. One more thought stayed with me from the build: if building exits were open data, finding the way out of a building abroad would be easier.

What HereOut does

HereOut is a web app. You photograph the evacuation plan on a wall, and it finds the exits and draws the route from the spot you tap to the nearest one. It used one Meta model, Muse Spark. Muse Spark read the exits and the words on the plan, and code drew the walls and the routes.

The judges scored every entry on four things.

CriterionWeight
Impact30%
Use of Meta AI tooling25%
Technical depth and execution20%
Demo25%

The winners gave the model a big job

Start with tooling, a quarter of the score. Most of the 14 winners used three to six Meta tools. ControlAnything, first in the indie track, lets you look at a real device through a Quest 3 headset and say what you want. A Spark agent then writes and tests the code that connects to it. The model does the big job, and code checks the result.

I went the other way. I was afraid the model would be wrong, so I made its job smaller step by step. At first the model also read the "you are here" mark on the plan. Later the user tapped their own spot. I used only one Meta model, so the 25% tooling criterion was hard to score on.

On top of that, these weights came out after I had picked my idea, and I did not check the idea again.

A crowded field can still win

Gatekeeper picked its topic the opposite way from me. Gatekeeper, second in the indie track, won with malware detection for npm1, a field full of commercial tools. During the event it watched new packages live and caught 48 packages that were later confirmed malicious, a median of 25 hours before public lists. It recorded each detection time in a public record first, so the judges could check the numbers instead of trusting them.

I did the opposite: when I picked my idea, I dropped topics that many people already work on. Gatekeeper suggests that a result anyone could check during the event counted for more than a new topic.

Looking back, my choice of field hurt more. A security tool where an agent judges and code checks the evidence is the kind of thing I usually build, but I never put an idea from that field on the list. I started from ideas that tied into my existing products, and the list narrowed to consumer safety apps.

Demo as a video, strongest number first

The winners also showed their work differently. All 14 winners gave a YouTube video. In the video field I put a link to a silent screen recording. The demo was 25% of the score, and mine showed no one using it at a real plan and had no voice.

My submission put the accuracy in the middle: HereOut finds about half the exits. Being open about it was right. But Gatekeeper used a better order, with the strong result first and the limits after.

Why HereOut found only half the exits

Here is where that "about half" comes from. On 28 photos of posted plans from 14 countries and regions, HereOut found 53% of the exits the plans clearly mark. The other way round, only 47% of the spots it called exits were real exits. In an earlier run, the wrong exits were often the sign beside a stair instead of the stair door, or a direction sign in a corridor.

Language was not the hard part. HereOut shows the plan card in 12 languages besides English, next to the original words. The drawing was the hard part. Posted plans have an international design standard, ISO 23601, but countries follow different rules. In the US, plans follow state and local fire codes. The plans in my photos looked different from country to country and from building to building.

If exits were open data

There is another way around the drawing problem. If buildings published their exits as open data in one shared format, a traveller's phone would not have to guess from a photo. The formats to hold that data already exist. IMDF, the indoor map format that Apple made, has an emergency exit door type (emergencyexit). IFC, the open standard for building design data, has a fire exit field (FireExit) on doors and spaces.

What is missing is publication. Korea publishes its civil defense shelters as open data that is updated daily, and Japan publishes its designated emergency evacuation sites. But both say where to go, not where the exits inside a building are.

Yet I found no open, machine-readable data of exit locations inside buildings in Korea, Japan, the EU or the US. The closest in Korea were statistics on whether businesses have an emergency exit and as-built drawings of rail stations. The statistics have no location, and the drawings may not be changed or used commercially.

OpenStreetMap, the map that anyone can edit, has little of it either. It has about 714 million buildings, but only 29,235 places worldwide carry the emergency entrance tag (entrance=emergency), as of November 9, 2026.

I think this gap will shrink from two sides. One is AI. As plan reading gets more accurate, one photo becomes exit data. The other is publication. Once building exits are open data, a phone can find the route with no photo at all.

What I will change next time

For the next contest, I plan to:

  1. Look for ideas in a field I know well first.
  2. Give the model a big job and check its results with code.
  3. Use several of the host's tools, each with a real job.
  4. Check the idea again when the judging weights come out or change.
  5. Make a result that anyone can check during the event.
  6. Put a video on YouTube that shows real use, with a voice.

Sources

Footnotes

  1. npm is the public registry where JavaScript developers publish and download packages of code.

Share

Back to Blog