What a working Snap Spectacles lens actually looks like

In short: a genuinely native Spectacles build is designed around hands and gaze from the first decision, tested for hours on real hardware rather than a simulator, and understandable to a first-time wearer with no explanation. Everything else in this article is what that looks like in practice, using two shipped projects as evidence.

Why a portfolio matters more on Spectacles than almost any other platform

Most AR work you can evaluate from a screen recording. Phone AR, WebAR, even a lot of headset content translates reasonably well to a video. Spectacles does not translate the same way. The thing that makes a Spectacles build good or bad is the interaction: how it responds to a hand, how it holds up when you turn your head, whether the wearer knows what to do in the first three seconds. A polished render or a demo reel tells you almost nothing about that. You need to see what was actually built, on the actual hardware, tested with actual first-time users.

That is the gap this article is closing. Not another list of what a smart glasses developer can build in the abstract (that overview lives at what a smart glasses developer builds if that is what you need). This is proof: two real, shipped Spectacles projects, walked through in enough technical and craft detail that you can judge them the way you would judge any other developer's portfolio piece before a hire.

Proof one: Noodle, and what winning a Snap-judged category actually demonstrates

Noodle is a spatial AI workbench built for Snap Spectacles Gen 5 in a 36-hour window at MIT Reality Hack 2026. It won the Founders Lab Track Prize, the Best Use of Spatial AI prize sponsored by Snap Spectacles, and the Snap Spectacles Community Challenge. The full build story, including the design decisions and the technical constraints, is in the Noodle build log. What matters for this article is what the win actually signals about the studio's execution on the platform, and the specific interaction choices that got it there.

Noodle has no screens, no keyboard, and no phone in the loop at any point. You look at a hand-drawn sketch on a real desk. A node-based canvas floats in your field of view. You create a node by pointing and pinching. You wire two nodes together by dragging with your hand, and the wire completing the connection is what actually triggers the pipeline. You speak a prompt instead of typing one. A generated 3D model appears spatially anchored on the same desk, next to the sketch it came from. Every step of that flow had to be designed for a hand-tracking-only input model, because Spectacles gives you nothing else to fall back on.

What MIT Reality Hack judging actually evaluates

MIT Reality Hack draws over 300 participants across teams of four to five, with a 36-hour build window and judges drawn from spatial computing researchers and platform engineers. A working demo under that kind of time pressure is judged on more than concept. It has to run reliably in front of strangers, hold up when a judge who has never seen it puts it on and starts touching things, and demonstrate platform fluency: an interaction model that could only have been built for the hardware it was shown on, not a concept that happened to be running on Spectacles that day. Winning a Snap-sponsored category specifically means the judging panel, which included people who evaluate spatial AI and Spectacles builds for a living, saw an interaction model and a technical execution that held up to that scrutiny. That is a meaningfully different bar than a controlled studio demo where nothing unexpected happens.

One craft detail worth naming: the team spent real build time designing what happens while the AI is generating. Generation takes 10 to 30 seconds. On a phone you get a loading bar and look away. On glasses, with nothing else in view, an empty wait breaks the experience. The fix was visual feedback states that made the system look like it was thinking alongside the wearer, not processing somewhere off-screen. That is the kind of decision that never shows up in a pitch deck and only shows up when you actually build the thing and test it on your own face.

Proof two: Ice Fishing, and designing for someone who has never worn AR glasses

Ice Fishing is a hyper-casual AR game for Snap Spectacles that places a frozen lake in real space around the wearer and turns a physical phone into the fishing rod: scroll up to cast, scroll down to reel in, sixty seconds to catch as many fish as you can. The full build story, including the performance work behind it, is in the Ice Fishing build log. It has been demonstrated at multiple Snap Spectacles events, and the pattern that showed up every time was consistent: people who had never touched a pair of AR glasses picked up the phone and started fishing within thirty seconds, without being told what to do.

That result is the entire point of this proof piece. Most people trying Spectacles for the first time have zero prior context for how to interact with a spatial display. If your onboarding depends on a tutorial overlay or a staff member standing next to the installation explaining it, you have already lost a chunk of the audience before the experience starts. Ice Fishing solved this by not inventing a new interaction at all. Holding a phone vertically already looks like a fishing rod handle. Scrolling up and down maps directly to what a wrist does with a real reel. The Spectacles handled the spatial layer, the phone handled the tactile input people already understood, and the two together read as one experience.

What separates a native Spectacles build from a ported one

Put Noodle and Ice Fishing side by side and a pattern shows up that is worth naming explicitly, because it is the checklist you should actually be applying to any Spectacles developer's portfolio.

Native interaction design for hands and gaze, not a ported screen flow

A ported build starts from a screen-based assumption: menus, buttons sized for a mouse cursor, text entry as a default input. It tries to make those patterns work with hand tracking bolted on afterward. A native build starts from the opposite direction. No keyboard, no mouse, no touchscreen. The interface gets designed around what a hand and a voice can actually do, and the constraint becomes the design principle rather than something to work around. Noodle's node-and-wire system exists because dragging a wire between two points is a gesture hands are already good at. Nothing about it resembles a desktop interface that got ported.

On-device testing rigor, not simulator-only development

Ice Fishing's performance problem (three heavy systems competing for one frame budget) only shows up on the actual hardware. A simulator will not surface the frame drops, the tracking lag, or the moment the fish response feels disconnected from the reel input. Getting that combination smooth required running builds on real Spectacles repeatedly and tuning each system against the others until the combined load fit inside the device's actual performance ceiling. A portfolio piece that only ever ran in a preview window has not been tested the way a live Spectacles build needs to be tested.

First-time-wearer onboarding thinking baked into the interaction, not bolted on after

Most people evaluating a Spectacles developer are picturing an audience that has never worn the hardware before, whether that is at a trade show, a retail activation, or a product launch. The tell for whether onboarding was actually designed for is whether the experience needs an explanation at all. Ice Fishing needed none because the phone-as-rod metaphor was already familiar. That is a design decision made at the very start of the project, not a tutorial screen added at the end because early testers got confused.

What this means if you are shortlisting a Spectacles developer

Ask to see the actual build running on hardware, not a render or an edited demo reel. Ask what happened the first time someone who had never used Spectacles tried it, and ask for a specific answer, not a general one. Ask whether the interaction model was designed for hands and gaze from the start or adapted from something built for a screen. And if a developer has a result like a Snap-judged win or a multi-event deployment to point to, that is worth more than a portfolio of concepts that never left a studio. Noodle and Ice Fishing are both public, both documented in full build logs, and both answer every one of those questions directly.

If you already know Spectacles is the right platform and you are past the evaluation stage, the next practical question is cost. Our guide to Snap Specs lens development cost breaks down what drives price on a build like this. And if you want the fuller picture of where Spectacles work fits inside the studio's wider wearables practice, see our wearables and smart glasses page.

Frequently asked questions