Shipping for a dead platform: Google Glass 2.

In 2019 I shipped an augmented-reality marketplace on Google Glass 2 (the Enterprise Edition). The product was a two-sided marketplace: a person on a phone could hire a person wearing the Glass in another city to do a hands-on errand — shopping, navigation, picking up cargo, checking on something physical. The phone user saw through the glass-wearer's eyes and directed them in real time.

I want to be precise about the timing, because it's the whole point of this post. Google had already discontinued the consumer Glass in 2015. The Enterprise Edition I built on was a niche industrial product with no consumer future. I knew that when I started. I shipped anyway. Seven years later, building GOGOGO LLC's multi-agent runtime, I still use things that summer taught me. Building for a dead platform is a strange, underrated school.

Why build on something already dying

The honest answer: the hardware was available and the constraint was interesting. Glass 2 gave you a heads-up display, a camera, a touch bar, and a bone-conduction speaker, in a package a worker could wear hands-free for a full shift. In 2019 nothing else gave you that exact shape. The platform being commercially doomed didn't change what it could physically do.

There's a category of engineer who only wants to build on the platform everyone agrees is winning. I understand the instinct — your skills compound, your work is legible to recruiters, the ecosystem helps you. But you also learn exactly the same things as everyone else, at exactly the same time. Building on a dead platform is lonely and uncompounding and that is precisely why it teaches you things the crowd never learns.

Lesson 1 — A dead platform has no Stack Overflow

When you build on React or iOS, almost every problem you hit has been hit before, written up, and answered. You are pattern-matching against a vast corpus. When you build on Glass 2 in 2019, the corpus is a few dozen forum posts, an enterprise SDK doc that assumes a use case you don't have, and your own experiments.

This forces a different kind of debugging. You can't search your way out. You have to build a mental model of the actual machine — the camera pipeline's real latency, the thermal throttling curve, what the bone-conduction speaker does under load — and reason from it. That muscle, reasoning from a model of the machine rather than from the corpus of other people's answers, is the single most valuable thing I carried out of that summer. It is exactly what you need when you debug a multi-agent system in 2026, because multi-agent systems are also too new to have a real corpus yet.

Lesson 2 — Constraints you can't lobby away

On a healthy platform, when you hit a hard limit, there's a sense that you could file a bug, wait for the next SDK, ask in a channel where a platform engineer might answer. The limit feels negotiable. On Glass 2 in 2019, every limit was final. The battery life was the battery life. The field of view was the field of view. Nobody was shipping a fix. Ever.

That changes how you design. You stop treating constraints as temporary and start treating them as the shape of the problem. The AR marketplace's whole interaction model — short directed glances, voice-confirmed steps, no dense UI — was derived from the immovable constraints rather than fought against them. The product was good because the platform was unforgiving.

At GOGOGO I design agent systems the same way. The latency floor of a model call is not negotiable; I design the orchestration around it instead of pretending a future model will be instant. The cost of a token is what it is. Treating real constraints as the shape of the problem — not as bugs to be fixed later — is a Glass-2 habit.

Lesson 3 — Ship the demo, learn the truth

The Glass 2 marketplace never became a business. It was a working demo that taught me what a two-sided real-world-errand marketplace actually requires — trust, liability, the awkwardness of seeing through a stranger's eyes, the logistics of payment across cities. None of that is visible from a slide. All of it is visible thirty seconds into a working demo.

A demo on a dead platform can't be a stepping stone to a unicorn — everyone knows the platform has no future, so there's no temptation to over-invest. That freedom is clarifying. You build the demo purely to learn the truth, ship it, extract the lesson, move on. I built four side projects with my brother Okan in roughly that spirit before we founded GOGOGO. The Glass 2 one taught the most per week of effort precisely because it could never be more than a demo.

Lesson 4 — The future arrives early, on the wrong device

Here's the part I think about most. The Glass 2 AR marketplace was correct about the future and wrong about the device. Hands-free heads-up computing, a remote expert seeing through a local worker's eyes, AI-assisted real-world tasks — all of that is mainstream now in 2026, on phones and on the current generation of AR glasses. The idea was right. The 2019 hardware was the wrong vessel for it.

This happens constantly. AIML chatbots in 2015 were correct about conversational interfaces and wrong about the technique. The first wave of crypto was correct about programmable trust and wrong about most of the applications. Recognizing "right idea, wrong device" is a specific skill — it lets you mine dead platforms and dead eras for the ideas that were genuinely ahead, and carry them to the device that finally fits. A lot of what GOGOGO ships is old ideas that finally have the right substrate.

Would I do it again

Yes — and I do. The discipline isn't "build on dead platforms." It's: don't let the market's verdict on a platform decide whether the platform can teach you something. Healthy platforms teach you the consensus. Dead and bleeding-edge platforms teach you to reason from the machine, to treat constraints as the problem's shape, to ship demos purely for truth, and to separate the right idea from the wrong device.

“Every dead platform is a library of ideas that were right too early. The engineers who can read that library — reason from the machine, not the corpus — are the ones who recognize the future when it finally gets the device it deserves.”

If you've shipped something strange on a doomed platform and want to compare notes, I collect these stories. atakanozalan.com, or ezagor for the handle.