Productos cloud al consumer
Diseño e ingeniería para productos cloud al consumer
Un producto cloud al consumer se juega en la confianza. El usuario firma cuando cree que sus datos están a salvo, y se va en cuanto algo le hace dudar. Trabajamos para que esa confianza aguante el día en que la nota de prensa trae diez mil usuarios en una hora, el día en que un investigador de seguridad revisa el código, el día en que la app se abre en el túnel del metro sin red.
Lo que vemos más a menudo
- 01
El visitante llega a la promesa de la landing y aterriza en otro producto
La landing habla un idioma, el producto habla otro. Las previews salen perfectas, los screenshots se ven en 4K, y luego alguien se registra y aterriza en un signup, un onboarding y un dashboard que no han pasado por las mismas manos. La fractura se ve en el primer acceso, y se paga en la retención de los primeros mil usuarios.
- 02
La nota de prensa trae diez mil usuarios en una hora y el producto se ralentiza
Todo aguanta mientras los usuarios están en early access. Luego una nota en TechCrunch o un hilo en Hacker News empuja diez o cien veces la carga en una hora. La lista de archivos redibuja todo en cada interacción, la búsqueda deja de responder, las consultas que aguantaban con cincuenta usuarios ya no aguantan. El día en que debería llegar la facturación, el producto pide perdón.
- 03
El primer investigador de seguridad desmonta el "cifrado"
En la landing pone "cifrado". El primer investigador que abre el código encuentra las claves en el servidor, legibles para quien gestiona la infraestructura. Ahí está la diferencia entre una promesa de privacidad que se sostiene bajo revisión y otra que se cae al primer vistazo. Los usuarios que vinieron por la privacidad se van al producto de al lado.
Cómo construimos Cloude
Cloude llegó con un MVP en early access y una ronda a punto de cerrar. El founder quería un solo equipo que se hiciera cargo del sitio de marketing, el producto web y la app móvil dentro de la misma codebase, y quería una promesa de privacidad que se pudiera defender delante de un investigador de seguridad.
Marketing y producto, mismo código
La mayoría de los productos cloud al consumer convive con una fractura. El sitio de marketing vive en un repositorio, el producto en otro, y en medio hay una capa de traducción que nadie quiere mantener de verdad. En el lanzamiento, marketing e ingeniería salen en eventos separados, y el visitante ve una preview que no se corresponde con el producto que recibe al registrarse.
Defendimos una sola codebase Next.js, un único design system, un único equipo. El founder respaldó la apuesta. El precio es que un cambio de copy cuesta una coordinación con el deploy, y que quien refactoriza un componente tiene que pensar también en el SEO. La ganancia es que el componente Files que el visitante ve en la landing es el real del producto. Al registrarse no hay desfase. El trimestre del lanzamiento salió en un solo evento, y la retención de los primeros mil usuarios no se gastó en la decepción.
Ingeniería para el día del TechCrunch
El deck del seed proyectaba un orden de magnitud más de usuarios en los doce meses siguientes. Trabajamos para la proyección a doce meses.
La lista de archivos dibuja un número fijo de filas en pantalla, así que el navegador hace el mismo trabajo con mil entradas o con un millón. Los archivos recientes vienen de una sola consulta de servidor, indexada sobre las columnas que importan. La caché local del navegador lee primero del disco, y la primera pantalla aparece antes de que la red responda. Cuando el teléfono salta del Wi-Fi a la red móvil, la conexión aguanta sin reiniciar la negociación. El día de la primera nota de prensa, el producto aguantó. No por casualidad.
Móvil nativo, porque tiene que serlo
El atajo era una PWA envuelta en una WebView. Fuimos a nativo. No por estilo, sino porque en un producto de privacidad las claves del cifrado tienen que vivir dentro de la zona protegida del teléfono, y una WebView no la alcanza. El cliente móvil está hecho en React Native sobre el design system del web, así que un cambio de token llega a todos los clientes a la vez. La build se queda por debajo del umbral en el que Apple y Google siguen descargando las actualizaciones silenciosas, y las nuevas versiones llegan al teléfono del usuario sin que tenga que abrir la store.
La promesa de privacidad se verifica
El cifrado en el dispositivo aparece a menudo en la factura de latencia: cold starts más largos, archivos que se abren más despacio, viajes de más por la red. Ese coste, en los casos que hemos visto, no viene de las operaciones de cifrado. Viene de decisiones de arquitectura que se pueden evitar si se piensan antes.
Los archivos se cifran en el dispositivo antes de salir. Las claves del cifrado se derivan de la passphrase que el usuario elige, y no viven nunca en el servidor. Las claves privadas se quedan dentro de la zona protegida del teléfono, y no salen ni siquiera en un dispositivo modificado. El servidor solo contiene blobs opacos, y nadie de la infraestructura ve nunca una clave descifrada.
Una auditoría de seguridad independiente pasa por la arquitectura con cadencia recurrente. El programa de disclosure declara los tiempos de respuesta a quien reporta una vulnerabilidad, y cada hallazgo se sigue hasta el cierre. Cuando un periodista o un compliance officer pide ver lo que hay debajo, el cliente no lee una promesa nuestra. Lee un informe escrito por otra persona.
Lo que la decisión devuelve
Después del lanzamiento, cuando el founder quiso añadir una plataforma nueva, una forma nueva de compartir, una página nueva en el informe de transparencia, eso fue un cambio en un solo repositorio, no una coordinación entre tres equipos. El design system es el contrato entre el marketing y el producto, y el contrato aguanta.
Qué ponemos en producción en este sector
- 01
Lo que el visitante ve en la landing es lo que recibe al registrarse
El sitio de marketing y el producto comparten código y design system. El componente que el visitante ve en preview en la landing es el real del producto. El signup entrega lo que la landing estaba vendiendo, y los primeros mil usuarios no pagan la retención de la decepción.
- 02
Cifrado que verifica una auditoría independiente
Los archivos se cifran en el teléfono o el ordenador del usuario, con claves que no salen del dispositivo. El servidor solo guarda blobs opacos, ilegibles para quien gestiona la infraestructura. Una auditoría de seguridad independiente firma el informe. El cliente lee el informe del auditor.
- 03
Listo para el día en que la nota de prensa trae diez mil usuarios
El producto aguanta el crecimiento que el founder prometió al seed, no solo a la cohorte de early access que lo usa hoy. La lista de archivos se queda fluida con mil entradas o con un millón. Las consultas no se ralentizan mientras crece el dataset. Cuando llega la ola, el usuario no espera.
- 04
App móvil nativa, porque tiene que serlo
Para un producto de privacidad, las claves del cifrado tienen que vivir dentro de la zona protegida del teléfono, esa que Apple y Google reservan para las credenciales biométricas. Una WebView no la alcanza. El cliente móvil está hecho en React Native sobre el mismo design system que el web, así que un cambio de token llega a todos los clientes en el mismo momento.
- 05
Sync que aguanta el túnel del metro
El producto sigue leyendo y escribiendo mientras el teléfono está offline. Cuando la red vuelve, propaga solo los cambios que el usuario hizo de verdad. Una ventana offline larga no se convierte en una sincronización larga al volver.
- 06
Una posición honesta sobre la passphrase perdida
Si el usuario pierde la passphrase, sus datos están perdidos. Lo decimos en el primer acceso, con palabras claras, no al final de una página de ayuda. La recuperación se activa solo si el usuario quiere, dividida en piezas que nunca viven juntas en el servidor. Sin puertas traseras disfrazadas de producto privado.
Una arquitectura que se demuestra en lugar de pedir confianza
El stack de un producto cloud al consumer no se juzga sobre la demo del founder. Se juzga en dos momentos de la vida del producto: el día en que los usuarios crecen un orden de magnitud, y el día en que un investigador de seguridad, un periodista o un compliance officer pide ver cómo funciona de verdad. Trabajamos para que el stack gane sobre todo el segundo momento.
El sitio de marketing y el producto son el mismo código. Para el founder eso significa que la landing no promete lo que el producto no puede cumplir, y que cuando el producto cambia la landing cambia con él, sin un ticket entre dos equipos. Para el visitante significa que el signup entrega el producto que la página estaba vendiendo.
El cliente móvil es una app nativa. Para un producto de privacidad no es una preferencia, es un requisito: las claves del cifrado tienen que vivir dentro de la zona protegida del teléfono, y una WebView no la alcanza. Escribimos en React Native sobre el design system del web, así que un cambio de token llega a todos los clientes a la vez. La build se queda por debajo del umbral en el que Apple y Google siguen descargando actualizaciones silenciosas, y las nuevas versiones llegan al teléfono del usuario sin que tenga que abrir la app de la store.
Los archivos se cifran en el dispositivo antes de salir a la red. La clave de cifrado se deriva de la passphrase que el usuario elige, y nunca vive en el servidor. El servidor solo contiene blobs opacos, ilegibles para quien gestiona la infraestructura. La línea "no podemos leer tus datos" deja de ser copy de marketing. Está en el código.
El producto aguanta la escala que prometió el seed, no solo la cohorte de hoy. La lista de archivos se queda fluida sea cual sea el tamaño, porque el navegador dibuja solo las filas que está mostrando de verdad. Las consultas del camino caliente vienen de columnas indexadas, con un plan de consulta que aguanta mientras el dataset crece. La caché local del navegador hace aparecer la primera pantalla antes de que la red responda.
Una auditoría de seguridad independiente pasa por la arquitectura con cadencia recurrente. El programa de disclosure declara los tiempos de respuesta a quien reporta una vulnerabilidad, y cada hallazgo se sigue hasta el cierre. Cuando un periodista o un compliance officer pide ver lo que hay debajo, el cliente no lee una promesa nuestra. Lee un informe escrito por otra persona.
Preguntas frecuentes en este sector
¿Cómo aseguran que pueden decir "cifrado" sin que la primera auditoría lo desmonte?+
Los archivos se cifran en el dispositivo del usuario antes de salir a la red. La clave de cifrado se deriva de la passphrase que el usuario elige, y nunca vive en el servidor. Al servidor llegan blobs opacos, y nadie de la infraestructura ve nunca una clave descifrada. Una auditoría de seguridad independiente verifica todo esto con cadencia recurrente y firma un informe que el cliente lee por su cuenta.
¿Por qué una app móvil nativa y no una PWA en una WebView?+
La zona protegida del teléfono, la que Apple y Google reservan para las claves y las credenciales biométricas, no se alcanza desde un sitio metido dentro de una WebView. Para un producto de privacidad, ahí es donde tienen que vivir las claves del cifrado. El cliente móvil está hecho en React Native y toma el design system del mismo package que usa el web, así que el coste de ir nativo se paga una sola vez sobre el sistema de tokens.
¿El cifrado en el dispositivo no ralentiza el producto?+
La factura de latencia que la mayoría de los productos paga por el cifrado en el dispositivo viene de decisiones de arquitectura, y solo en pequeña parte de las operaciones de cifrado. Abrimos un archivo compartido a la misma velocidad que uno privado, porque la negociación de las claves es lo bastante ligera como para no notarse en el primer arranque.
¿Y si el usuario pierde la passphrase?+
Si el usuario pierde la passphrase, sus datos están perdidos. Lo decimos en el primer acceso, con palabras claras, no al final de una página de ayuda. La recuperación se activa solo si el usuario quiere, dividida en piezas que nunca viven juntas en el servidor. Sin puertas traseras disfrazadas de producto privado.
¿Cómo aguantan la escala antes de que lleguen los usuarios?+
La lista de archivos dibuja un número fijo de filas en pantalla, así que el navegador hace el mismo trabajo con mil entradas o con un millón. Las consultas del camino caliente vienen de columnas indexadas, con un plan de consulta que no cambia mientras el dataset crece. La primera pantalla se carga desde la caché local del navegador, y el usuario no espera a la red para empezar a trabajar.