Construir para una plataforma muerta: Google Glass 2.

En 2019 lancé un marketplace de realidad aumentada sobre Google Glass 2 (la Enterprise Edition). El producto era un marketplace de dos lados: una persona en un teléfono podía contratar a otra que llevaba las Glass en otra ciudad para hacer un recado físico — comprar, orientarse, recoger una carga, revisar algo físico. El usuario del teléfono veía a través de los ojos de quien llevaba las gafas y lo dirigía en tiempo real.

Quiero ser preciso con el timing, porque es todo el punto de este post. Google ya había discontinuado la Glass de consumo en 2015. La Enterprise Edition sobre la que construí era un producto industrial de nicho sin futuro de consumo. Yo lo sabía cuando empecé. Lo lancé igual. Siete años después, construyendo el runtime multi-agente de GOGOGO LLC, sigo usando cosas que aquel verano me enseñó. Construir para una plataforma muerta es una escuela rara e infravalorada.

Por qué construir sobre algo que ya está muriendo

La respuesta honesta: el hardware estaba disponible y la restricción era interesante. La Glass 2 te daba una pantalla heads-up, una cámara, una barra táctil y un altavoz de conducción ósea, en un paquete que un trabajador podía llevar con las manos libres un turno entero. En 2019 nada más te daba exactamente esa forma. Que la plataforma estuviera condenada comercialmente no cambiaba lo que físicamente podía hacer.

Hay una categoría de ingeniero que solo quiere construir sobre la plataforma que todos coinciden en que está ganando. Entiendo el instinto — tus habilidades se acumulan, tu trabajo es legible para los reclutadores, el ecosistema te ayuda. Pero también aprendes exactamente lo mismo que todos los demás, exactamente al mismo tiempo. Construir sobre una plataforma muerta es solitario y no acumulativo, y por eso mismo te enseña cosas que la multitud nunca aprende.

Lección 1 — Una plataforma muerta no tiene Stack Overflow

Cuando construyes sobre React o iOS, casi cada problema que te encuentras ya fue encontrado, documentado y respondido. Estás haciendo pattern-matching contra un corpus enorme. Cuando construyes sobre Glass 2 en 2019, el corpus son unas pocas docenas de posts de foro, un doc de SDK empresarial que asume un caso de uso que no tienes, y tus propios experimentos.

Eso obliga a un tipo distinto de debugging. No puedes salir buscando. Tienes que construir un modelo mental de la máquina real — la latencia real del pipeline de cámara, la curva de throttling térmico, qué hace el altavoz de conducción ósea bajo carga — y razonar desde ahí. Ese músculo, razonar desde un modelo de la máquina en vez de desde el corpus de respuestas ajenas, es lo más valioso que me llevé de aquel verano. Es exactamente lo que necesitas cuando depuras un sistema multi-agente en 2026, porque los sistemas multi-agente también son demasiado nuevos para tener todavía un corpus real.

Lección 2 — Restricciones que no puedes negociar

En una plataforma sana, cuando chocas con un límite duro, hay una sensación de que podrías reportar un bug, esperar al próximo SDK, preguntar en un canal donde un ingeniero de la plataforma podría responder. El límite se siente negociable. En la Glass 2 en 2019, cada límite era definitivo. La duración de batería era la duración de batería. El campo de visión era el campo de visión. Nadie iba a lanzar un fix. Nunca.

Eso cambia cómo diseñas. Dejas de tratar las restricciones como temporales y empiezas a tratarlas como la forma del problema. Todo el modelo de interacción del marketplace de AR — miradas dirigidas y cortas, pasos confirmados por voz, sin UI densa — fue derivado de las restricciones inamovibles en vez de pelearse contra ellas. El producto era bueno porque la plataforma no perdonaba.

En GOGOGO diseño los sistemas de agentes igual. El piso de latencia de una llamada a un modelo no es negociable; diseño la orquestación alrededor de él en vez de fingir que un modelo futuro será instantáneo. El costo de un token es el que es. Tratar las restricciones reales como la forma del problema — no como bugs a arreglar después — es un hábito Glass 2.

Lección 3 — Lanza el demo, aprende la verdad

El marketplace de Glass 2 nunca se convirtió en un negocio. Era un demo funcional que me enseñó qué requiere de verdad un marketplace de recados de dos lados en el mundo real — confianza, responsabilidad legal, la incomodidad de ver por los ojos de un desconocido, la logística del pago entre ciudades. Nada de eso se ve desde una slide. Todo se ve a los treinta segundos de un demo funcional.

Un demo en una plataforma muerta no puede ser un peldaño hacia un unicornio — todos saben que la plataforma no tiene futuro, así que no hay tentación de sobreinvertir. Esa libertad aclara. Construyes el demo puramente para aprender la verdad, lo lanzas, extraes la lección, sigues. Construí cuatro proyectos paralelos con mi hermano Okan más o menos con ese espíritu antes de fundar GOGOGO. El de la Glass 2 fue el que más enseñó por semana de esfuerzo, precisamente porque nunca podría ser más que un demo.

Lección 4 — El futuro llega temprano, en el dispositivo equivocado

Esta es la parte en la que más pienso. El marketplace de AR de Glass 2 acertaba sobre el futuro y se equivocaba sobre el dispositivo. La computación heads-up con manos libres, un experto remoto viendo por los ojos de un trabajador local, las tareas del mundo real asistidas por IA — todo eso es mainstream ahora en 2026, en teléfonos y en la generación actual de gafas de AR. La idea estaba bien. El hardware de 2019 era el recipiente equivocado.

Esto pasa constantemente. Los chatbots de AIML en 2015 acertaban sobre las interfaces conversacionales y se equivocaban sobre la técnica. La primera ola de cripto acertaba sobre la confianza programable y se equivocaba sobre la mayoría de las aplicaciones. Reconocer "idea correcta, dispositivo equivocado" es una habilidad específica — te deja minar plataformas muertas y eras muertas en busca de las ideas que iban genuinamente adelantadas, y llevarlas al dispositivo que por fin encaja. Mucho de lo que GOGOGO lanza son ideas viejas que por fin tienen el sustrato correcto.

¿Lo volvería a hacer?

Sí — y lo hago. La disciplina no es "construye sobre plataformas muertas". Es: no dejes que el veredicto del mercado sobre una plataforma decida si esa plataforma puede enseñarte algo. Las plataformas sanas te enseñan el consenso. Las plataformas muertas y de vanguardia te enseñan a razonar desde la máquina, a tratar las restricciones como la forma del problema, a lanzar demos puramente por la verdad, y a separar la idea correcta del dispositivo equivocado.

“Cada plataforma muerta es una biblioteca de ideas que tenían razón demasiado pronto. Los ingenieros que saben leer esa biblioteca — razonar desde la máquina, no desde el corpus — son los que reconocen el futuro cuando por fin consigue el dispositivo que merece.”

Si has lanzado algo raro sobre una plataforma condenada y quieres comparar notas, colecciono estas historias. atakanozalan.com, o ezagor para el handle.