Creamos apps para móviles y ordenadores, además de extensiones de navegador. Somos un equipo pequeño e independiente que trabaja en remoto. Publicamos lo que nos gustaría tener en nuestros propios móviles, ordenadores y navegadores, y nada más.
Creemos que el ritmo habitual del móvil moderno —lanzamientos constantes, funciones a medio terminar, tests A/B para todo— agota a los usuarios y desgasta a los equipos. Lanzamos cuando el trabajo está terminado, no cuando lo dice el sprint. A veces eso significa una semana; otras, un trimestre. En cualquier caso, la actualización llega y se nota terminada.
Solo recopilamos lo que una app necesita de verdad para funcionar. Sea lo que sea —analítica, anuncios, servidores de sincronización—, se indica en la etiqueta de privacidad de la tienda y en la Política de privacidad de la app antes de que la instales. Nada de recopilación oculta ni de perfiles de comportamiento vendidos a intermediarios de datos.
Algunas de nuestras apps se compran una sola vez. Otras son gratuitas con suscripciones opcionales. Otras se financian con publicidad. Sea cual sea el modelo que encaje con el producto, se muestra claramente en la ficha de la tienda: sin cargos ocultos, sin renovaciones automáticas por sorpresa, sin patrones oscuros.
Seguimos siendo pequeños. Lo bastante como para que quien escribió el código sea quien lea tu correo sobre el error en ese código. No hay niveles de soporte ni cadenas de escalado. Hay una sola bandeja de entrada, y la leemos.
Fundó Zydeno en 2026 tras una década creando software para empresas ajenas. Decide qué lanzamos y, lo que es más importante, qué no. Cree que la mayoría de las apps serían mejores con la mitad de funciones.
Responsable del lenguaje visual de todas las apps de Zydeno. Obseso de la tipografía, minimalista del movimiento. Cinco años en diseño editorial e impreso antes de pasarse a las pantallas: se nota en la tipografía. No aprueba una interfaz que solo funciona si además puede sentirse bien.
Pasó seis años haciendo motion graphics para agencias de publicidad antes de pasarse al producto. Cada animación elástica, cada toque y cada transición de una app de Zydeno pasa por sus manos. Cree que una curva de easing de 240 ms marca la diferencia entre una herramienta y un juguete.
iOS nativo desde iOS 5. Alérgico al bombo de SwiftUI, escribe Swift que arranca en menos de un segundo en un iPhone de hace cinco años. Lee notas de versión por diversión. Es responsable de la arquitectura de todas las apps de iOS que publicamos y revisa cada pull request que toca el runtime.
Ocho años escribiendo Swift y, antes, dos en Objective-C. Se mete a fondo en las migraciones de Core Data, las tareas en segundo plano y las partes de UIKit que StackOverflow dio por perdidas. Es el segundo de guardia ante los cierres en producción y lo prefiere a desarrollar funciones.
Se incorporó tras dos años creando componentes de iOS para empresas en un estudio de herramientas de diseño. Vive en SwiftUI cuando tiene sentido y baja a UIKit cuando no. Se encarga de la mayor parte de nuestra biblioteca compartida de componentes de interfaz: las piezas pequeñas y con criterio que reutiliza cada app para que la próxima versión resulte familiar desde el primer minuto.
Maximalista de Kotlin. Le importan más el tiempo de arranque en frío y el consumo de batería que el número de funciones. Trata cada kilobyte como si pagara alquiler. Se encarga de los ports a Android y, últimamente, de las versiones para Windows, para las apps que se lo ganan.
Todo lo que los usuarios nunca ven: la sincronización, el almacenamiento local pensado para funcionar sin conexión, las partes aburridas que hacen que la app parezca magia. Lleva él solo nuestra infraestructura, desarrolla nuestras extensiones para Chrome, Edge y Firefox, y lo prefiere así.
La última persona que toca cada build antes de su lanzamiento. Se encarga de la revisión de calidad y de la disciplina de decir «todavía no». Mantiene la batería de pruebas de regresión que permite al equipo avanzar rápido sin romper las apps que ya están en las pantallas de inicio de la gente.
Contratamos despacio. Discrepamos a menudo. Y aun así lanzamos.
Bocetos, flujos de usuario, discusiones sin rodeos sobre si eso debería siquiera existir. Si sobrevive a esta fase, se ha ganado el derecho a construirse.
Código real en dispositivos reales. Sin maquetas ni datos inventados. Si algo no convence en esta fase, tampoco convencerá al lanzarlo: lo arreglamos aquí o lo descartamos.
Microinteracciones, retoques de textos, una revisión de accesibilidad: los 200 pequeños detalles que separan el software que funciona del software bueno. Y entonces sale.
Leemos todos los informes de errores y peticiones de funciones. No todas se desarrollan. Las que sí, llegan en el siguiente ciclo, no en el próximo parche urgente.