ISYOÜ
en movimiento

ISYOÜ Tickets: las organizaciones ya pueden contratar a ISYOÜ para su evento

Hasta ahora ISYOÜ vendía a creadores y a marcas por separado, pero no tenía cómo atender a una organización que monta un evento presencial y quiere a ISYOÜ como su boletería y su transmisión. Esta semana nació ISYOÜ Tickets, una pestaña nueva dentro de Eventos, solo para organizaciones, y la primera ya firmó.

• Dos paquetes: Impulso, para darle visibilidad al evento, y Organizador, que suma la boletería con control de acceso. El Organizador se puede pagar completo o la mitad para activar y el resto antes de abrir la venta.
• Se paga en pesos, por PSE o con factura electrónica. Ese dinero va por nuestros rieles de pago y nunca se convierte en ISY.
• Solo organizaciones verificadas. Antes de pagar, la organización pasa por la verificación de empresa, que también se reforzó (ver más abajo).
• Un panel de finanzas para el CTO: cada contrato con lo cobrado, lo que falta, los gastos y las devoluciones. Desde ahí se registra el pago de una factura y se resuelve un pago que el banco avisó a medias.
• Reglas claras por escrito: si el evento se aplaza, el paquete sigue; si se cancela, ISYOÜ se queda la mitad de lo recibido y devuelve el resto. Está en una sección nueva de los términos.

El primer paso de la compra del paquete según cómo va la verificación de la organización. Pantallas con datos de ejemplo.

Boletas con QR que solo se activan con la identidad verificada de quien compró

Con el paquete Organizador, la organización vende sus boletas dentro de ISYOÜ. El público elige la localidad, paga en pesos por PSE y la boleta queda a su nombre. Para que nadie revenda ni copie una boleta, el QR solo se activa cuando quien compró verifica su identidad. Sus acompañantes entran con él.

• Sin sobreventa. Al empezar a pagar, las boletas quedan apartadas 60 minutos; si el pago no llega, vuelven a la venta solas.
• En la puerta, el portero lee el QR con el teléfono o escribe el código corto de la boleta. Ve en grande si puede entrar, el nombre verificado de quien compró y los últimos 4 números de su documento para compararlo. Una boleta entra una sola vez.
• Si el evento se aplaza, las boletas siguen valiendo. Si se cancela, se anulan y ISYOÜ gestiona la devolución.

Del evento a la puerta: la compra, la boleta con su QR y la pantalla del portero. Pantallas con datos de ejemplo.

Cada promotor con su enlace, y la organización sabe exactamente cuánto vendió cada uno

Las organizaciones mueven sus boletas con creadores y artistas que las promocionan, y necesitan saber cuánto vendió cada uno para pagarles su comisión. Ahora cada promotor tiene su código y su propio enlace de compra. Quien llega por ese enlace compra con el código ya puesto, y la venta queda a nombre de ese promotor aunque después escriba otro.

• La organización ve todo en su panel: lo vendido por localidad y por promotor, la comisión de cada uno con el porcentaje que ella decide y un archivo para descargar.
• El promotor ve sus propias ventas, con su enlace para compartir. De los compradores solo ve el nombre y la inicial del apellido.
• La plata del evento se liquida después del evento, y solo a la cuenta bancaria de la empresa con un código al correo oficial. Si el evento no se hace, el dinero sigue disponible para devolverlo.

El panel de la organización (promotores, reporte y liquidación) y lo que ve cada promotor. Pantallas con datos de ejemplo.

ISYOÜ ahora es solo para mayores de 18, y la edad se comprueba con el documento

Para entrar bastaba con un correo o una cuenta de Google: nadie confirmaba su edad, y la verificación de identidad no miraba la fecha de nacimiento del documento. Ahora la pantalla de entrada pide confirmar «tengo 18 años o más» antes de continuar, y todos vuelven a aceptar los términos, que dicen lo mismo.

• La edad la confirma el documento. Al verificar la identidad, se lee la fecha de nacimiento del documento. Si la persona es menor de edad, la cuenta queda restringida en todo, incluso si tenía la sesión abierta.
• Ese dato nunca es público. La restricción vive en una parte privada de la cuenta, nunca en el perfil que otros pueden ver.
• Ganar dinero exige la identidad verificada, de las dos partes cuando hay un pago entre personas.
• Una entrada más clara: fondo claro, errores al lado de cada campo y el código por correo con su tiempo para reenviarlo.

La nueva pantalla de entrada: el aviso de 18+, la confirmación de edad y los errores al lado de cada campo.

Verificar una empresa ahora prueba que quien la maneja es de verdad su representante

Con organizaciones moviendo dinero de eventos, la pregunta del CTO fue directa: ¿cómo sabemos que quien maneja la cuenta de una empresa es de verdad quien la representa? Antes bastaba subir un documento de la empresa. Ahora la verificación de empresa tiene tres candados:

• Primero la persona, luego la empresa. Quien verifica la empresa ya tiene su identidad verificada, y tiene que figurar como representante legal en el certificado de Cámara de Comercio, de 30 días o menos. El número de su documento tiene que coincidir con el del certificado.
• El correo oficial lo pone la Cámara, no el usuario. Llega un código al correo de notificaciones que aparece en el certificado, y sin ese código la empresa no queda verificada.
• Lo que no se puede comprobar solo, lo revisa el CTO. Un apoderado sube el poder firmado y el CTO lo aprueba a mano. Lo mismo pasa con un certificado cuya firma digital no se puede comprobar como emitida por una Cámara.

El modelo de IA solo lee los datos del documento. Las decisiones (edad, número, fecha, cargo y NIT) las toman reglas fijas del servidor, con pruebas automáticas.

Los tres pasos de la verificación de empresa: datos y rol, documentos y el código al correo oficial. Pantallas con datos de ejemplo.

El dinero solo sale a la cuenta del dueño, y cada retiro se confirma con un código

Un retiro aceptaba cualquier cuenta bancaria de destino y no pedía nada más: quien entrara a una cuenta ajena, o quien manejara el perfil de una empresa, podía mandar el dinero a donde quisiera. Ahora:

• Una cuenta registrada, a nombre del dueño. Una persona solo registra una cuenta con su mismo documento de identidad. Una empresa, solo una cuenta a nombre de la empresa, con su certificación bancaria. La cuenta de una empresa se activa 48 horas después de registrarla.
• Un código por correo en cada retiro y al registrar o cambiar la cuenta. En una empresa, el código llega al correo oficial de su certificado de Cámara de Comercio, no al de quien maneja el perfil.
• Un código sirve para un solo retiro, por ese monto, a esa cuenta y en esa moneda.

Retirar ahora: la cuenta registrada a nombre del dueño y el código por correo en cada retiro. Pantallas con datos de ejemplo.

Se cerraron las puertas laterales por donde el saldo podía salir sin confirmación

Asegurar los retiros no bastaba si el saldo podía moverse por otro lado. Revisamos cada camino por donde sale dinero de una cuenta y lo cerramos con la misma regla: lo que no es una compra normal dentro de ISYOÜ, se confirma con un código por correo.

• Enviar saldo a otra persona siempre pide el código. Los regalos en un live y las compras siguen sin fricción hasta un tope diario.
• Las empresas solo compran dentro de ISYOÜ. No envían saldo a personas ni a billeteras externas.
• Cambiar la billetera principal o exportar su llave pide la identidad verificada y el código.
• La creación de campañas de anuncios queda en pausa mientras se le pone la misma protección. Las campañas que ya existen siguen activas.

Un solo link para invitar creadores, con una sola regla: 10% durante 12 meses

Quien invita a un creador a ISYOÜ se lleva una parte de lo que ISYOÜ gana con ese creador. Pero hasta esta semana la regla no era la misma en todas partes. En la pantalla del saldo, arriba decía «Programa activo · 12 meses» y abajo «15%… Sin límite de tiempo». Algunos links creaban acuerdos con un porcentaje propio. Y quien compartía una publicación mandaba un enlace que la abría, pero no contaba como invitación: si la otra persona se registraba, nadie quedaba como quien la trajo.

Ahora la regla es una sola y se cumple igual en todos lados:

• 10% de lo que gana ISYOÜ. En una venta de 100 ISY, ISYOÜ se queda 5, y de esos 5, 0,50 son para quien invitó al creador. Se paga en cada venta del creador, siempre que tenga su identidad verificada.
• Durante 12 meses. Se cuentan desde el día en que el creador se registró con el link. Pasado ese tiempo, lo que vende es solo entre él e ISYOÜ.
• El mismo link, desde donde sea. Da igual si se comparte desde el perfil, desde el saldo o desde una publicación: siempre aplica la misma regla. Compartir una publicación ahora abre esa publicación y además cuenta como invitación.
• Para todos, sin tocar lo pagado. Los creadores invitados antes también cuentan sus 12 meses desde que se registraron, y lo que ya se pagó con la regla anterior no cambia. Los managers que ISYOÜ asigna a mano a un creador conservan su acuerdo.
• Todo dice lo mismo. La pantalla del saldo, los términos y el asistente de la app cuentan la misma regla. En el panel de administración se ve hasta cuándo paga cada invitación, y cuando pasan los 12 meses queda marcado.

La sección Referidos del saldo antes y ahora: de «12 meses» arriba y «sin límite» abajo, a una sola regla. Pantallas con datos de ejemplo.

El perfil de un creador ya muestra todo lo que ha publicado

Un creador abría su Vault y veía ahí sus publicaciones, pero en la pestaña «Posts» de su perfil no estaban. ¿Por qué? El perfil no buscaba las publicaciones de ese creador: tomaba las 100 más recientes de toda la app y de ahí sacaba las suyas. Si había publicado hace unas semanas, sus publicaciones ya habían quedado fuera de esas 100. Les pasaba a 74 creadores, y uno con 63 publicaciones veía su perfil vacío.

• Todo, siempre. El perfil ahora busca todas las publicaciones de ese creador, por viejas que sean, y se actualiza solo cuando publica algo nuevo.
• Las pestañas cuentan lo mismo. Posts, Repeticiones, el contador de publicaciones y el Vault salen de la misma lista, así que siempre coinciden.
• Lo comprado, completo. La Colección muestra todo lo que el usuario compró, no solo lo que estaba entre lo más reciente de la app.
• Repeticiones junto a sus lives. En el Vault, las repeticiones aparecen con los lives, igual que en el perfil.

Una llamada en pleno live ya no acaba con el show

Imagina a una creadora en vivo, con 37 personas mirando. Le entra una llamada, contesta, y cuando vuelve su live ya no está en la pantalla. Hasta esta semana tenía dos caminos, los dos malos: abrir un live nuevo y empezar de cero con su público, o esperar sin saber qué pasaba. Mientras tanto, su live seguía «al aire» media hora sin nadie, el público miraba una imagen quieta y la grabación quedaba en un lugar que ella no sabía dónde buscar.

Ahora la historia es otra:

• Vuelve con un toque. Esté donde esté dentro de la app, ve arriba «Tu live sigue al aire · Volver» y cuánto tiempo le queda. Un toque y está otra vez en su mismo live, con su chat y su grabación. Si había cerrado la app, al abrirla el live sigue solo.
• Su público la espera. En vez de una imagen quieta, ve «El creador salió un momento» y cuánta gente está esperando, y puede seguir escribiendo en el chat.
• Salir ya no es un accidente. Si toca «salir», la app le pregunta antes de terminar, le recuerda cuánta gente la está viendo y le dice que tiene 10 minutos para volver.
• Si no vuelve, nada queda en el aire. A los 10 minutos el live se cierra solo (antes tardaba hasta 45). El público ve «El show terminó», con su perfil y otros lives para seguir viendo. A ella le llega un aviso: su grabación ya está guardada en su Vault.

La barra para volver, la pregunta antes de terminar, lo que ve el público mientras la creadora vuelve y cuando el show terminó. Pantallas con datos de ejemplo.

Media hora de live gratis cada día, y un plan para quien vive de sus lives

Un creador que está empezando transmite de vez en cuando, y no debería pagar por eso. Uno que hace lives todos los días necesita más tiempo y un lugar para guardar todo lo que produce. Por eso, desde ahora, cada creador tiene 30 minutos de live gratis al día. Quien necesita más elige un plan, lo paga con ISY y le alcanza para transmitir todo el mes. Vale para todos los lives, también los de El Palco y los de entrada paga.

• Tres planes, cada 30 días. Básico: 10 horas por 14,99 ISY. Creador: 30 horas por 34,99 ISY. Pro: 100 horas por 89,99 ISY. Cada plan agranda también el Vault: de 1 GB gratis a 5, 15 o 50 GB.
• Siempre sabe cuánto le queda. Antes de salir al aire, un anillo le muestra sus minutos. Primero se gastan los 30 gratis del día y después los del plan.
• Nadie se queda cortado de golpe. Al aire, un contador discreto se pone ámbar cuando faltan 5 minutos y rojo en el último. Si se acaban, tiene 2 minutos para mejorar su plan ahí mismo, sin salir del live. Si no lo hace, el live termina y la grabación queda guardada en su Vault.
• Subir de plan es justo. Si sube a mitad de mes, se le descuenta lo que no alcanzó a usar del plan que tenía. La renovación es automática y la puede apagar cuando quiera.
• Pagar es seguro. Como todo pago con ISY, pide la identidad verificada y deja su comprobante. Nadie puede activarse un plan sin pagarlo.
• Antes de publicarlo, alguien intentó hacer trampa. Una revisión aparte buscó cómo usar minutos sin pagar o cómo cobrar de más, y encontró cuatro caminos. Un live que terminaba en segundos podía dejar el contador corriendo para siempre. El teléfono podía «atrasar el reloj» para no gastar minutos. Quien gastaba todas sus horas y subía de plan se llevaba casi todo de descuento. Y una renovación podía pisar una compra hecha en el mismo instante. Los cuatro quedaron cerrados.

Los minutos antes de salir, los planes, subir de plan con descuento y los 2 minutos para mejorar sin salir del live. Pantallas con datos de ejemplo.

Todo lo que un creador publica, guardado en un solo lugar

Hasta esta semana, encontrar la grabación del live de la semana pasada era una búsqueda: había que entrar a la pantalla para salir en vivo y abrir «Ver mis grabaciones». Las historias desaparecían a las 24 horas para siempre, y el Vault del perfil solo mostraba algunos archivos sueltos. Ahora el Vault es el archivo personal del creador: ahí aparece solo todo lo que publica.

• Sus lives. Cada uno aparece con lo que está pasando: «Grabando» mientras sigue al aire, «Preparando» mientras queda listo, y después listo para ver o descargar, por partes si fue largo. Si algo falló, lo dice. Las grabaciones de los lives no le gastan espacio.
• Sus historias. Cuando una historia vence a las 24 horas, sigue guardada en su Vault. Si la borra antes, también se borra de ahí: fue su decisión.
• Sus publicaciones y archivos. Fotos, carruseles, clips, infoproductos y archivos, con filtros para encontrar cada cosa y una barra con el espacio que lleva usado.
• Solo lo ve él. Los enlaces para ver o descargar duran 2 horas, así que nada de su Vault queda circulando para siempre.
• Un hueco cerrado. Antes, la propia app anotaba cuánto espacio tenía cada cuenta, y alguien con conocimientos podía darse 50 GB sin pagar. Ahora el espacio sale del plan, y ese dato solo lo cambia ISYOÜ al cobrar. Nadie había pagado el plan anterior del Vault, así que nadie perdió nada.
• Y lo que ya no quiere, lo borra. Cada tarjeta tiene su botón para borrar. Antes de hacerlo, la app le muestra qué se va a ir, cuánto espacio libera y que no se puede deshacer, y lo marcado es «Cancelar». Hay dos cosas que no deja borrar, y explica por qué. Una publicación que alguien compró no se borra, porque esa persona perdería lo que pagó. El archivo de un curso tampoco: dejaría el curso roto para quien lo compró. Se borra borrando la publicación. Un live que todavía se está grabando espera a terminar.

Un Vault con lives en distintos momentos, publicaciones, historias y archivos, y uno recién estrenado. Pantallas con datos de ejemplo.

Borrar desde el Vault: el botón en cada tarjeta, la pregunta antes de borrar y los dos casos que no se borran. Pantallas con datos de ejemplo.

Pagar con ISY es ahora entre personas con identidad verificada

El 24 de octubre alguien sin verificar intentó pagar por un enlace. No pasó nada grave, pero dejó ver un hueco: comprar ISY, pagar por enlace, dar propinas y regalos, comprar entradas o contenido, suscribirse o retirar no pedían la identidad verificada. Solo El Palco se la pedía a quien compraba y la tienda a quien vendía. Desde este día, todo pago con ISY la pide a las dos partes: a quien paga y a quien recibe.

• En cada cobro, sin excepciones. ISYOÜ lo revisa justo antes de mover la plata, así que no hay forma de saltárselo desde la app.
• Un enlace que no confunde. Quien abría un enlace de pago sin cuenta veía «Enlace no encontrado», como si estuviera roto. Ahora ve «Para pagar necesitas una cuenta verificada» y un botón para entrar, que después lo lleva directo a verificarse.
• Quien paga sin verificar ve un aviso con «Verificar mi identidad», y el botón de pagar le dice qué le falta.
• Si quien recibe no está verificado, el enlace lo dice claro: «Valentina todavía no puede recibir pagos».
• Suscripciones: si una de las dos partes no está verificada, la renovación no se cobra y se avisa.
• De paso: al pagar con una tarjeta guardada, el cobro sale siempre de la cuenta de quien está usando la app.

Lo que ve quien abre un enlace de pago sin cuenta, quien quiere pagar sin estar verificado y quien paga a alguien que todavía no lo está. Pantallas con datos de ejemplo.

El pago por enlace pide el celular y dice cuánto recibe el creador

El 24 de octubre llegó el primer pago por transferencia bancaria desde un enlace, y el proveedor de pagos lo rechazó: «número de celular inválido». La página del enlace nunca pedía el celular. La compra desde la billetera sí lo pide, y por eso ahí funcionaba. La misma compra encendió además una alarma de «intento de manipular el monto», que resultó falsa: la página decía «Sin comisión» y mandaba el monto entero, pero al creador le llega lo pagado menos la comisión de ISYOÜ.

• El celular, con su indicativo. Un campo nuevo con el indicativo del país (+57, +52, +55). No deja pagar hasta tener los dígitos que corresponden, y lo explica: «Escribe tu celular de 10 dígitos, sin el indicativo del país».
• Espacios y guiones ya no tumban el pago: se quitan antes de enviarlo.
• Sin sorpresas con la comisión. Por decisión del CTO, la página muestra «Valentina recibe ≈ 9,09 ISY» y «Comisión de ISYOÜ: 10 %», donde antes decía «Sin comisión».
• Adiós a la falsa alarma: la página manda exactamente lo que muestra.

Lo que recibe el creador después de la comisión, el celular incompleto y el formulario completo, listo para pagar. Pantallas con datos de ejemplo.

Los correos de ISYOÜ ahora se ven y suenan como ISYOÜ

Quien compraba un cupo recibía un correo con un encabezado genérico y un pie que decía «pasó algo con tu cuenta». No parecía de una empresa: parecía uno de esos avisos automáticos que se borran sin leer, o que hacen dudar si son un engaño. Justo lo contrario de lo que debe transmitir un comprobante de pago.

• La marca, de punta a punta. El logo de ISYOÜ arriba, sus colores, la franja naranja, violeta y turquesa, y la Ü al pie. Se ve igual en el correo del teléfono y en el del computador.
• El monto, protagonista. Va grande y con la moneda ISY al lado. Lo que recibe un creador va en turquesa y con «+».
• Tono de empresa. Cada correo dice qué es («Comprobante de compra», «Comprobante de venta»), saluda por el nombre y dice cuándo pasó, en hora de Colombia. Muestra el detalle de la operación y cierra con una nota de seguridad y el correo de soporte.
• En inglés para quien usa ISYOÜ en inglés.

Un comprobante de compra, uno de venta y el mismo comprobante en inglés. Pantallas con datos de ejemplo.

Cada compra, venta y retiro ahora avisa a quien tiene que saberlo

Una fan compra su cupo para un show de El Palco, paga… y no le llega nada. Ni un aviso en la app ni un correo. No sabe si quedó adentro. Así pasaba con casi todo lo que movía plata en ISYOÜ: solo la compra de ISY mandaba comprobante. Desde este día, cada operación le avisa a cada persona que participa en ella.

• El Palco: quien compra recibe «Tu cupo está confirmado». El creador y su socio reciben «Vendiste un cupo… Recibiste X ISY». Cuando el show empieza, todos los que tienen cupo reciben «ya empezó». También se avisa si un cupo vence o se revoca, con el motivo.
• Entradas, contenido, suscripciones y solicitudes del chat: comprobante a quien paga y aviso de venta a quien cobra. Si hubo un promotor, también a él.
• Tienda: el comprador ahora recibe la confirmación. Antes no recibía nada.
• Retiros: cuando se recibe, cuando se paga y, si no se pudo pagar, que se le devolvió el saldo. Los reembolsos y la verificación de identidad también avisan.
• En la app, en el teléfono y por correo, en el idioma de la cuenta, y nunca dos veces el mismo aviso. Los regalos dentro de un live solo avisan en la app: serían decenas de correos por show.
• Un canal cerrado. Nadie puede usarlo para mandarle correos a otra persona.

Los avisos de una compra, una venta, un show que empieza y un retiro, en español y en inglés. Pantallas con datos de ejemplo.

Antes de salir en vivo, el creador sabe si su internet aguanta

Un músico va a transmitir desde su casa. Hasta ahora salía al aire a ciegas: si su internet no daba, se enteraba cuando el público ya veía el video entrecortado. Si cantaba, el teléfono «limpiaba» su voz como en una llamada y le apagaba la guitarra. Y si giraba la cámara, quien miraba veía un corte.

• Prueba de internet. Antes de salir toca «Probar», y en unos 10 segundos sabe cuánto sube su conexión y qué calidad le alcanza: 480p, 720p o, en computador, 1080p. Si es muy poca, le sugiere usar WiFi. Lo que elige queda guardado para la próxima vez.
• Modo música. Sonido sin filtros y en estéreo, para cantar o tocar. Si hay invitados, le recuerda usar audífonos para que no haya eco.
• Un iPhone más fresco. En iPhone, iPad y Mac el video sale en el formato que procesa el propio chip del equipo. Antes se hacía por otro camino que calentaba el teléfono.
• Girar la cámara sin cortes: quien mira ya no ve el salto.
• La repetición ya no se congela. Si el creador giraba la cámara o dejaba de compartir pantalla, la repetición guardada seguía con sonido pero con la imagen quieta desde ese momento. Ahora guarda por tramos y al final los une en un solo video.

El resultado de la prueba de internet, el consejo cuando la conexión es débil y el modo música encendido. Pantallas con datos de ejemplo.

Meta de regalos, top de fans y los mejores momentos del show

En un live, el público quiere sentir que su regalo cuenta, y el creador quiere llevarse algo del show cuando termina. Hasta ahora los regalos pasaban por el chat y se perdían entre los mensajes, y lo mejor del live quedaba enterrado en una grabación de una hora.

• Meta de regalos. El creador toca «Poner meta» («Micrófono nuevo · 500 ISY») y todos ven la barra avanzar. Al llegar, «¡Meta cumplida!».
• Top de fans. Los tres que más regalaron, con corona para el primero. Al tocarlos aparece el top 5 con los montos, y quien mira se ve marcado si está en la lista.
• Solo cuenta lo que se pagó. La meta y el top suman los cobros, no lo que dice el chat: un mensaje se puede inventar, un cobro no.
• Mejores momentos. Al terminar, ISYOÜ propone hasta tres momentos de 30 segundos, los de más movimiento en el chat entre mensajes, reacciones y regalos. Cada uno empieza unos segundos antes, porque la reacción llega después de lo que la provocó. Se ven ahí mismo y se publican como historia con un toque. Si no hubo suficiente actividad, no se inventan momentos.
• Orden arriba a la izquierda: la meta, la canción del momento y el distintivo de El Palco van en una sola columna. Antes podían quedar uno encima del otro.

La meta en el live, la hoja para ponerla, el top de fans y los mejores momentos al terminar. Pantallas con datos de ejemplo.

Seguir viendo el live en miniatura mientras se usan otras apps

Una fan está viendo un live y le escriben por otra app. Hasta ahora, salir a contestar era perderse el show: al volver, ya había pasado lo mejor. Ahora puede seguir viéndolo en una ventanita mientras contesta.

• Un botón arriba, junto a compartir: «Ver en miniatura».
• La primera vez, una nota en el teléfono explica cómo usarlo. Los teléfonos solo abren la miniatura cuando la persona toca, no por su cuenta.
• Con imagen y sonido. La ventanita lleva la imagen de quien transmite y todo el sonido del live. Mientras está abierta, el live dentro de la app se calla para no oírse doble.
• No aparece para quien transmite ni en un live de pago que no se ha comprado. Si el live termina, la miniatura se cierra.

El botón de la miniatura, la nota de la primera vez y el botón marcado con la miniatura abierta. Pantallas con datos de ejemplo.

Un show de El Palco se comparte antes de que empiece

Un artista pone a la venta su show de El Palco para dentro de dos semanas. Lo natural es compartirlo ya, para vender cupos. Pero solo se podía compartir el live cuando ya estaba al aire, y para entonces era tarde para vender.

• Desde «Mis Palcos»: «Compartir» va primero en cada show que está a la venta.
• Desde el show: quien lo abre, desde el perfil o desde Eventos, tiene «Compartir» arriba a la derecha.
• El enlace llega listo para vender: con la portada, la fecha y un texto que termina en «Aparta tu cupo». En el teléfono abre el menú para compartir; donde no lo hay, copia el enlace.
• Un borrador no lo ve nadie y un show pasado ya no se vende, así que esos no llevan el botón.

«Compartir» primero en un show a la venta, y el mismo botón en el show que abre el público. Pantallas con datos de ejemplo.

Un artista invitado probó transmitir con sus gafas, sin montar un evento

Un artista invitado quería probar sus gafas con cámara antes de un show importante. Transmitir desde unas gafas usa una señal que llega de afuera de la app, y eso solo existía dentro de El Palco: para probar, tenía que crear un evento de pago. Se le abrió una prueba solo a él: un live gratis y público con sus gafas, una hora al día, hasta el 23 de octubre.

• Elegir la fuente. En «Fuente del video» elige «Cámara de este dispositivo» o «Gafas (prueba)», y ve los minutos que le quedan hoy.
• La misma sala de control de El Palco. Al salir al aire recibe la dirección y la clave para la app de sus gafas. La clave solo la ve él.
• Una hora al día. Al cumplirse, el live se cierra solo y la clave deja de servir. Al día siguiente tiene otra hora.
• Para todos los lives con señal de afuera: si el live se cierra, por la hora o por falta de señal, quien transmite ahora se entera, con el motivo y el resumen. Antes seguía viendo la sala de control como si estuviera al aire.
• La prueba terminó el 23 de octubre, como estaba previsto.

La opción de las gafas con minutos disponibles y cuando ya se usó la hora del día. Pantallas con datos de ejemplo.

La app ya no se queda quieta hasta recargarla

En las pruebas apareció una falla rara: de vez en cuando, al moverse rápido entre Explorar y un live, la app dejaba de recibir novedades. El chat no avanzaba, los avisos no llegaban y el saldo no se actualizaba hasta recargar la página. No era un error de ISYOÜ, sino de una pieza de un proveedor con la que la app recibe los datos al instante. Su fabricante ya lo había corregido en una versión nueva, y ISYOÜ pasó a usarla.

El chat del live ya no pierde mensajes, y quien transmite lo puede moderar

Algunos mensajes del chat se perdían sin que nadie se enterara: quien escribía veía su mensaje en su pantalla, pero el resto del público nunca lo recibía. Pasaba en tres casos: cuando el reloj del teléfono iba atrasado, cuando llegaban más de 50 mensajes entre un envío y el siguiente, y cuando dos mensajes tenían exactamente la misma hora.

• Por qué pasaba: el chat se reparte al público en tandas. Cada tanda pedía los mensajes posteriores a la hora de la tanda anterior, y la hora de cada mensaje la ponía el teléfono. Ahora la pone el servidor, y cada tanda sigue exactamente desde el último mensaje que repartió. Si hay más de 50, la siguiente sigue donde quedó.
• Moderación: quien transmite toca un mensaje para borrarlo o para silenciar a quien lo escribió (no puede escribir y sus mensajes se ocultan). Desde los ajustes del chat le devuelve la voz.
• Modo lento: 5, 15 o 30 segundos entre un mensaje y otro de cada persona. Los regalos y las propinas no esperan. El ritmo lo hace cumplir el servidor, no solo la app.
• Si el chat no acepta un mensaje que ya se pagó, como un regalo, el pago ya no se informa como fallido.
• Estado de la conexión: avisos de «Reconectando…», «Sin conexión» y señal débil, y barras de señal para quien transmite. De paso, el aviso de señal débil salía cortado en el teléfono («…puede verse con c…»); ahora se lee entero.
• Mejor imagen: la cámara transmite a 720p y 30 cuadros por segundo, con el micrófono en alta calidad. Quien mira con mala señal recibe una versión liviana del video en vez de cortarse. Los invitados, a 480p.

Moderar un mensaje, los ajustes del chat, el modo lento visto por el público y los avisos de conexión de quien transmite. Banco de pruebas con datos de ejemplo.

El Palco tiene portada y cuenta regresiva, igual que los lives de Eventos

Un show de El Palco solo tenía el día, sin hora, y su imagen la ponía la administración. Los lives gratis de Eventos ya tenían portada, día con hora y una cuenta regresiva grande, que es lo que crea expectativa. Ahora El Palco se arma y se ve igual.

• Al crear un show: portada opcional (sin ella se usa la foto del perfil) y fecha con hora. A los shows ya creados se les agrega con «Portada y fecha»; «Cambiar fecha» en un show que ya pasó abre la misma hoja.
• Las mismas piezas, no copias: el selector de imagen, la portada con la cuenta regresiva y la fila de la agenda son las mismas en El Palco y en Eventos. El Palco de cada creador se ve como la agenda de Eventos: por día, con la hora, la portada y los cupos.
• Al abrir un show: la portada con «Empieza en 2 d 0 h», y en la última hora, minutos y segundos.
• La hora se guarda como el instante exacto: cada persona la ve en su hora local. Una hora sin zona se leía como hora de Colombia en el servidor y como la hora del teléfono en la app, así que desde otro país la cuenta regresiva habría quedado corrida.
• Al compartir un show, la tarjeta muestra su portada y la fecha legible («domingo, 25 de octubre, 8:00 p. m. (hora Colombia)») en vez de una imagen genérica y «2026-10-25».
• Un show sin hora sigue funcionando: dice «Hora por confirmar», y a quien lo creó se le recuerda que sin hora no hay cuenta regresiva.

Crear un show con portada y hora, «Portada y fecha» en uno ya creado, El Palco de un creador visto por su público y un show abierto con la cuenta regresiva. Banco de pruebas con datos de ejemplo.

Al cambiar de idioma ya no quedan textos en el idioma anterior

Con el selector de idioma nuevo, algunos botones seguían en español después de pasar a inglés (y al revés) hasta recargar la página: los del chat del live (emojis, regalos, enviar), la tienda del live, la música y el marketplace, entre otros.

• Al cambiar de idioma, la app se vuelve a dibujar entera sin cerrar nada ni perder lo que se estaba haciendo: nadie se sale de un live por cambiarlo.
• Los mensajes del sistema del live («Bienvenido…», «Conectado al chat») y los errores de cámara y micrófono se traducen al mostrarse, no al crearse.
• Cuatro textos del live que salían en un solo idioma para todos («Unlock Failed», «Link Unlocked!», «Failed to restore camera.» y el de fondos insuficientes) ahora salen en el idioma de cada persona.

En el iPhone, la app tapaba el live y no se podía escribir en el chat

El reporte llegó con una captura desde un iPhone: al entrar a un live, el encabezado de la app tapaba la parte de arriba (LIVE, compartir y cerrar) y la barra de abajo tapaba el campo para escribir y el último botón del costado. Desde el teléfono no se podía comentar, unirse ni salir de ningún live.

• Por qué pasaba: en el iPhone, el área principal de la app arma su propia capa por la forma en que Safari maneja el desplazamiento. El live quedaba encerrado en esa capa, por debajo del encabezado y de la barra, aunque estaba marcado para ir encima de todo. En computador y en Android eso no pasa, y por eso las pruebas anteriores, hechas en Chrome simulando un iPhone, no lo detectaron.
• El arreglo: al entrar, el live se monta por encima de toda la app, como ya lo hacían el correo y la ventana del chat. Antes de entrar, la pantalla sigue en su lugar.
• De paso: los avisos que salen durante el live, como un error al enviar un regalo, ahora aparecen encima del live. Antes quedaban debajo y nadie los veía.
• El banco de pruebas ahora puede mostrar el live dentro de la app imitando al iPhone, para que esta falla no vuelva sin que se note.
• Queda: confirmarlo en un iPhone de verdad. El banco imita el comportamiento de Safari, pero no es Safari.

Antes y ahora en el teléfono, con el teclado abierto y en un live compartido. Banco de pruebas con datos de ejemplo.

Un video largo para una historia ya no se rechaza: se recorta al publicar

Un video de más de 60 segundos se rechazaba con «Recórtalo y vuelve a intentarlo», y había que recortarlo en otra app. Ahora se abre un recortador, como en las apps de historias más usadas.

• Con un video largo, el recortador abre con los primeros 60 segundos elegidos. Abajo, la tira de cuadros con una ventana que se arrastra (los bordes la acortan, el centro la mueve; de 1 a 60 s). Arriba, el tramo elegido se repite. Con un video corto, las tijeras lo abren si se quiere acortar.
• Se sube solo el tramo elegido: el corte lo hace el mismo paso que ya achicaba el video en el teléfono.
• Si el teléfono no puede recortar video, uno largo se sigue rechazando como antes, en vez de mostrar un recortador que fallaría. Si el corte falla, no se sube el video entero: se avisa.
• Un video para recortar puede pesar hasta 2 GB; lo que se sube se sigue revisando contra el límite de 100 MB.

El recortador con un video de 1:30 y el primer minuto elegido. Banco de pruebas con un video de ejemplo.

La traducción se completa: Studio, avisos, correos y un selector de idioma

Con esta entrega, quien usa ISYOÜ en inglés ya no encuentra español en las pantallas, en los avisos que le llegan al teléfono ni en los correos. El español sigue siendo el idioma principal, y ahora cada persona puede elegir el suyo.

• ISYOÜ Studio, recompensas y el gestor de anuncios ya están en los dos idiomas. En Studio, lo que escribe la IA (textos, kits de identidad, narraciones) sale en el idioma de la app.
• Avisos y correos en el idioma de cada cuenta: los avisos al teléfono, el correo con el código para entrar, el código para confirmar una transacción y el comprobante de compra. Los avisos se siguen guardando como siempre y se muestran traducidos, también los que ya estaban.
• Errores del servidor: cada mensaje conocido llega en inglés a quien usa la app en inglés. De paso, unos 40 mensajes que salían en inglés dentro del español ahora salen en español.
• Selector de idioma (Español | English): en la pantalla de ingreso, en el menú de la cuenta y en el perfil del teléfono. El cambio es inmediato y queda guardado en la cuenta.
• Documentos legales: en inglés se muestran en español, que es la versión que rige, con una nota que lo explica.
• Quedan en español a propósito los paneles de administración, que usa solo el equipo, y todo lo que escribe la gente: nombres, publicaciones y mensajes.

ISYOÜ Studio y el centro de recompensas, en español y en inglés.

El selector en la pantalla de ingreso y el correo con el código, en los dos idiomas.

ISYOÜ empieza a hablar inglés: casi toda la app ya está en los dos idiomas

El español sigue siendo el idioma principal. Todo lo que ve la persona pasa ahora por diccionarios en español y en inglés, en vez de estar escrito dentro de cada pantalla. Quien tiene el navegador en inglés ve la app en inglés; antes veía una mezcla de los dos.

• Ya en los dos idiomas: menú, acceso y avisos; el inicio, Comunidad, historias y lives programados; el live completo; la billetera y los pagos; verificación, perfil, mensajes, notificaciones y correo; El Palco, Eventos, el Marketplace, crear publicaciones e infoproductos, la música y la página del artista oficial.
• Fechas, horas y números según el idioma: «19 oct · 6:00 p. m.» y «407.945 COP» en español; «Oct 19 · 6:00 PM» en inglés.
• Lo que se guarda no cambia: la descripción de un movimiento, la categoría de un producto o el estado de un pedido siguen guardándose igual; solo se muestran en el idioma de quien los mira.
• Una clave que falta no compila: el inglés tiene la misma forma que el español, así que un texto sin traducir se detecta antes de publicar.
• De paso se corrigió el inglés que aparecía dentro del español («Upgrade your Account», «No Clips Available», «Fee / Transfer», «PENDING»…).
• Falta: ISYOÜ Studio, recompensas y el gestor de anuncios; los avisos y correos del servidor en el idioma de cada cuenta; la nota de los documentos legales (en inglés se muestran en español, que es la versión que rige) y el selector de idioma, que se activa cuando todo esté listo.

El Marketplace y Eventos, en español y en inglés.

La verificación y el perfil, en español y en inglés.

/estrategia ahora es una presentación corta para marcas grandes, en español e inglés

/estrategia era un informe largo para inversionistas, firmado con nombre propio. Ahora es una presentación que se lee en un par de minutos, pensada para ofrecerla a grandes corporaciones. Las secciones son tarjetas de distintos tamaños sobre una misma cuadrícula.

• Primero, la alianza de marca. En la primera pantalla se ve dónde aparece la marca: la barra superior del live, con «Tu logo aquí» marcado junto a ISYOÜ.
• Cuatro formas de estar en el show: El Palco, el producto fijado dentro del live, la cuenta regresiva con «Avísame» y los lives compartidos. Además, la agenda de eventos, los pagos locales y la grabación de cada live. Cada una muestra su pantalla real.
• Después, la puerta a una alianza estratégica: la tesis y una calculadora ilustrativa en USD, con la advertencia de que no es una proyección ni una oferta.
• ISYOÜ Monetiza, marcado como piloto: la marca financia la campaña, el creador convoca a su comunidad y la persona recibe recompensas por participar, con lo que se mide para repetir (compras, costo por comprador, margen y renovación). Lleva dos piezas visuales: «Tu atención tiene valor» y «Cobra por tu streaming». La propuesta interna del piloto quedó fuera; de ella solo se usó la idea, sin el reparto en dinero.
• Mantiene el selector ES | EN. En inglés, una nota aclara que las pantallas están en español porque el producto es para Latinoamérica.
• Ya no lleva el nombre de quien la firmaba ni marcas de terceros.

La primera pantalla en computador y en teléfono, en español y en inglés.

Después, el CTO decidió no mostrar las cifras de producción: la franja con las cuatro cifras ya no está en la página.

Ronda 2 y ronda 3 de la tarjeta de El Palco en teléfono: el texto pasó a ir sobre fondo sólido.

Eventos ahora es una agenda: lives gratis y shows de El Palco juntos, por día, a un toque desde el menú

La sección de Eventos tenía tres pestañas a medio hacer. «Próximos» solo mostraba los lives gratis, cada uno en una tarjeta que ocupaba la pantalla entera. Los shows de El Palco, que son los que venden cupos, no aparecían. «Pasados» decía «en construcción», y en «En vivo» las tarjetas no tenían imagen. Además, la sección no estaba en el menú, y el botón del banner del inicio decía «Únete al Palco» sin dejar claro adónde llevaba.

Ahora funciona como una agenda:

• Lo que viene junta lives gratis y shows de El Palco, ordenados por día («Hoy», «Mañana», «Domingo 18 oct») en filas cortas, con la hora o cuánto falta, quién, dónde, cuánto cuesta y cuántos cupos quedan. Se puede filtrar entre Todo, Lives gratis y El Palco, y en cada live gratis está «Avísame».
• En vivo muestra solo lo que está al aire, con imagen, cuánta gente lo ve y cómo se entra: gratis, con entrada o por El Palco. Debajo aparece lo que viene.
• Pasados lista lo de los últimos 30 días.
• La pestaña inicial depende de lo que haya: si nadie está al aire, abre en lo que viene.

Eventos está en el menú lateral, y el banner del inicio ahora dice «Ver eventos».

Antes y ahora en Próximos, y las pestañas En vivo y Pasados. Banco de pruebas con datos de ejemplo.

Cómo se llega: el menú y el banner. Al tocar un live, su detalle con la cuenta regresiva.

Todos los lives se graban en la nube: un show ya no se pierde porque se cerró la pantalla

Una artista hizo un show en vivo de hora y media desde su teléfono, anunciado con anticipación: el aviso les llegó a todos los que lo esperaban. Al final quiso guardar la repetición y no había nada que guardar. Cerca del final, la app salió de la pantalla del live sin terminarlo. En el iPhone basta rozar el borde de la pantalla para que el teléfono haga el gesto de «volver», y la app lo obedecía aunque hubiera un live al aire. La grabación vivía solo en la memoria del teléfono, así que se perdió entera. En la nube solo se grababan las transmisiones con señal externa.

Ahora todos los lives se graban en la nube desde que empiezan, terminen como terminen: si se cierra la pantalla, se acaba la batería o se cambia de app, el video queda guardado. El creador lo descarga desde «Ver mis grabaciones», y solo él puede verlo. Además:

• Durante un live, el gesto de volver ya no saca de la transmisión, y salir con el menú pide confirmación.
• La app ya no se deja traducir por el navegador. El traductor cambiaba los textos de la pantalla y la rompía, que fue el error que la artista vio al día siguiente.
• La repetición ya no se da por fallida si tarda más de un minuto en subir, y muestra cuánto lleva.
• El anuncio del live se cierra solo al terminar la transmisión.

En el live, la barra del navegador ya no tapa los comentarios ni el campo para escribir

En el teléfono, durante un live, el campo «Di algo…» y los últimos comentarios quedaban debajo de la barra de abajo del navegador. Pasa sobre todo en los navegadores que dejan esa barra flotando encima de la página, como el de los iPhone más recientes y los que se abren desde otras apps. Quien miraba no podía escribir sin cerrar la barra, y el último botón de la derecha quedaba cortado.

La causa: la capa de comentarios se acomodaba al teclado, pero ignoraba a propósito todo lo que tapara menos de 120 píxeles, para no saltar cuando la barra aparece o se esconde. Esa barra mide menos que eso. Ahora la capa mide cuánto de su borde de abajo queda fuera de la vista, sea teclado o barra, y se sube exactamente eso. Cuando nada la tapa, se ve igual que antes.

La versión anterior y la nueva con la barra flotando; sin barra, y con el teclado. Banco de pruebas con la zona segura de un iPhone simulada.

Lives programados: un artista ya puede anunciar su live gratis con anticipación y crear expectativa

Una artista iba a salir en vivo y no tenía cómo avisarle antes a su comunidad. El Palco sirve para shows con cupos, boleta y verificación de identidad; para un live abierto y gratis no había nada: la pestaña «Próximos» de Eventos estaba vacía y su botón «Crear» solo llevaba a transmitir en ese momento.

Ahora el creador programa su live con título, fecha y hora, de qué va y una portada opcional. El anuncio sale en Eventos, en su perfil y en un carril nuevo del inicio, «Lives que vienen», con una cuenta regresiva que en la última hora corre segundo a segundo. Quien lo ve toca «Avísame» y recibe dos avisos en el teléfono: uno 15 minutos antes y otro cuando el creador sale al aire. También puede guardarlo en su calendario, y el contador muestra cuántas personas lo esperan.

Al guardarlo, la app invita a compartirlo: el enlace muestra la portada, la hora y quién transmite en cualquier chat o red. Quien no tiene cuenta y lo abre ve el anuncio antes de registrarse. Cuando el creador abre el estudio cerca de la hora, su anuncio aparece ya marcado. Al salir en vivo, la tarjeta cambia a «Entrar al live» en todas partes.

Lo que se cuidó: el número de personas que esperan solo sube de a uno y junto con el aviso de cada persona, así nadie lo infla. Cambiar la hora no sirve para mandar recordatorios sin fin (máximo dos por anuncio). El aviso de «empezó» sale una sola vez, aunque el creador abra varias transmisiones. Y nadie puede usar el anuncio de otro para mandar avisos.

Antes y ahora en la pestaña Próximos; al anunciarlo, y al salir en vivo desde el estudio. Banco de pruebas con datos de ejemplo.

Dónde vive: el formulario, el perfil del creador y el carril del inicio.

Historias: la canción del sticker suena con un solo toque

Quien publica una historia puede ponerle una canción con el sticker «Canción»: se busca por nombre o artista y queda en la historia con su portada. Quien la ve encuentra un ▶ junto a la canción. Con un solo toque, la historia se pausa y la canción empieza a sonar sola en el reproductor oficial de la plataforma de música. Al terminar, «Seguir viendo» vuelve a la historia.

Por qué así y no como música de fondo: las condiciones de esa plataforma prohíben que su música suene junto con imágenes o video. Probamos un catálogo propio de música de fondo, pero se decidió quedarse solo con las canciones de la plataforma, que se escuchan al tocarlas. En algunos navegadores, sobre todo en iPhone, el reproductor no arranca solo; entonces aparece «Toca ▶ para escuchar».

De paso apareció un fallo que ya existía: si un video no arrancaba solo y la persona pasaba a la siguiente historia, el botón «Toca para reproducir» se quedaba encima y las historias siguientes dejaban de responder. Quedó corregido.

De izquierda a derecha: ponerle la canción a la historia, cómo la ven los demás y la canción sonando tras un toque. Banco de pruebas.

Tu música en ISYOÜ: la canción que te representa, en el chat y en el live

ISYOÜ se conectó al catálogo de una de las plataformas de música más usadas. Nadie tiene que iniciar sesión en ella: se busca por nombre de canción o de artista desde la app.

• En el perfil: cada persona elige «la canción que te representa», y quien la visita la escucha en el reproductor oficial.
• En el chat: un botón nuevo comparte una canción, que llega con su reproductor.
• En las historias: un sticker con la portada, el nombre y el artista.
• En el live: el anfitrión muestra arriba la canción que está sonando, y el público la abre con un toque.

Lo que se cuidó:

• Las credenciales de la conexión viven solo en el servidor. La app nunca las ve, y cada persona tiene un límite de búsquedas por hora.
• En la base se guarda solo el identificador de cada canción. El nombre, el artista y la portada los escribe el servidor, así nadie puede mostrar una «canción» con un nombre o una imagen inventados.
• Se cumplen las condiciones de la plataforma: su logo oficial acompaña cada canción, con su tamaño mínimo, y su música no suena dentro de un live.
• Un panel interno de administración muestra qué canciones se usan más en ISYOÜ. Cuenta personas, no reproducciones, porque esas condiciones no permiten medir lo que se escucha. Esos datos no se publican.

De izquierda a derecha: buscar, la canción del perfil, compartida en el chat y lo que suena en el live. Banco de pruebas.

Lives compartidos: el anfitrión sube hasta tres invitados a su transmisión

Hasta hoy un live era de una sola persona. Ahora el anfitrión puede compartirlo de dos maneras. Puede invitar a alguien desde un buscador: a esa persona le llega el aviso «te invitó a salir en su live», que la lleva directo a la transmisión. O puede aceptar a quien toca «Unirme» desde el público. Caben hasta tres invitados a la vez: cuatro personas en pantalla.

La pantalla se reparte sola en recuadros, cada uno con el nombre de quien sale en él y una corona en el del anfitrión. En el teléfono los recuadros van arriba y el chat abajo, así ningún invitado queda tapado por los mensajes. Si alguien apaga la cámara, su recuadro muestra su foto.

Lo que se cuidó:

• Nadie se sube solo. Hace falta el sí de las dos partes: el anfitrión invita y la persona acepta, o la persona pide y el anfitrión acepta. El permiso para transmitir lo da el servidor, no la app.
• La cámara de un invitado solo se enciende con un toque suyo, después de un aviso que dice que se van a encender su cámara y su micrófono y que todo el público lo va a ver.
• Solo salen cuentas con la identidad verificada, igual que para transmitir.
• El anfitrión quita a cualquiera cuando quiera. Si termina el live, todos los invitados dejan de transmitir.
• Las propinas del live siguen siendo del anfitrión.

Lo que falta: la prueba con video real entre dos teléfonos. Lo de arriba está comprobado con pruebas automáticas y en el banco de pruebas, todavía no en una transmisión real. Además, la repetición del live graba solo al anfitrión, y por ahora los invitados no aplican en El Palco.

De izquierda a derecha: pedir unirse, la invitación, dos y cuatro personas al aire, la vista del invitado y el panel del anfitrión. Banco de pruebas con personas de ejemplo.

Tocabas «Mensaje» en un perfil y no sabías con quién estabas hablando

El reporte: al buscar a alguien, entrar a su perfil y tocar «Mensaje», se abría el chat pero nada decía con quién. Un chat nuevo era una pantalla vacía, con un encabezado chico que decía «Desconectado». Ahora abre con una tarjeta de la persona: su foto, su nombre, su @, sus seguidores y el botón «Ver perfil», más la invitación «Escríbele a Luna para empezar la conversación». El encabezado muestra siempre la foto y el nombre, y el campo para escribir dice «Escribe a Luna…».

Al revisar el chat completo, en teléfono y en computador, aparecieron fallas que nadie había reportado:

• El botón «Mensaje» del perfil no hacía nada si la persona no tenía nombre completo.
• En el teléfono, el teclado tapaba el campo para escribir, y el botón del micrófono quedaba cortado fuera de la pantalla.
• La conversación no abría en el último mensaje: las fotos terminaban de cargar después y lo empujaban fuera de la vista.
• En el computador, el encabezado con el nombre se perdía al llegar un mensaje y el campo para escribir quedaba por debajo de la pantalla.

En el teléfono la conversación ahora ocupa toda la pantalla, sin el menú de la app, y termina justo encima del teclado. Abre siempre en el último mensaje y se queda ahí mientras cargan las fotos, salvo que la persona suba a leer. Para leer mejor: la hora queda a la vista, hay separadores de día y de «2 mensajes nuevos», y bajo el último mensaje propio dice «Visto» o «Enviado». En la bandeja, los mensajes propios llevan «Tú:».

Antes y después: el chat nuevo, con el teclado abierto y una conversación con fotos. Banco de pruebas con datos de ejemplo.

Historias: mencionar a alguien con @ y que al tocarlo se abra su perfil

El botón «Mención» de las historias ponía un texto que decía «@» y nada más: no buscaba a nadie y no llevaba a ningún lado. Ahora funciona como en las apps de historias más usadas. Al escribir @ en un texto aparece, justo encima del teclado, una lista con foto, nombre y usuario: primero la gente que sigues, y al escribir, búsqueda por nombre o por @. También hay un sticker de mención, que se escribe dentro del propio sticker. Se pueden mencionar hasta 20 personas por historia.

En la historia publicada, el sticker y los @ subrayados dentro de un texto se pueden tocar: aparece una pastilla con la foto y el nombre de la persona, y al tocarla se abre su perfil. A cada persona mencionada le llega el aviso «Te mencionó en su historia».

Con el mismo trabajo llegó responder sin salir de la historia. Antes, tocar «Enviar mensaje» cerraba la historia y abría el chat. Ahora se escribe ahí mismo, la historia espera, y la respuesta llega al chat con la miniatura de la historia y el texto «Respondió a tu historia». En la bandeja, las historias ya vistas quedan al final con un aro gris más visible.

De izquierda a derecha: escribir @, la mención en la historia, el sticker de mención, tocar la mención, responder y la bandeja. Banco de pruebas con datos de ejemplo.

Un live lleno de propinas destapó el problema: en el teléfono, el teclado tapaba el chat

El live salió muy bien y llegaron muchas propinas. Pero desde el teléfono, el chat «se sobreponía» y el campo para escribir quedaba tapado. Al reproducirlo aparecieron tres causas.

• El teclado. En un iPhone, y en la mayoría de los Android recientes, abrir el teclado no achica la página: la tapa. El campo, anclado abajo, quedaba debajo del teclado y se escribía a ciegas. Pasaba en todos los casos medidos.
• El panel de emojis. Era transparente por un color que no existía en el diseño, y los emojis quedaban encima de los mensajes.
• Los regalos animados. Con muchas propinas, nacían justo sobre el chat y sobre el producto fijado.

Ahora la app mide cuánto de la pantalla tapa el teclado y sube el chat esa misma distancia: el campo queda justo encima del teclado, y siempre se ve el último mensaje. Mientras se escribe, los botones y el producto fijado se apartan para dejar lugar. Los paneles de emojis y de regalos son opacos y ocupan el lugar del chat en vez de montarse encima, y los regalos animados suben por el costado derecho, lejos del texto.

De paso, el chat se rediseñó contra el de una de las plataformas de streaming en vivo más usadas. Cada mensaje va en una línea, con el nombre en color, sin burbujas y sobre un fondo oscuro difuso que se lee igual sobre cualquier video. Donde antes cabían tres mensajes, ahora caben diez o doce, y las propinas tienen su propia línea con borde dorado y la cifra destacada. Una revisión independiente que solo veía capturas comparó cada ronda contra esa referencia: cinco rondas hasta aprobar, en dos tamaños de teléfono, para quien mira y para quien transmite, con y sin teclado.

Antes y después: con el teclado abierto, con el panel de emojis y en estado normal. Banco de pruebas con datos de ejemplo.

La revisión independiente, ronda por ronda, hasta la aprobación en la quinta.

Una revisión a fondo de toda la app: ocho puertas de seguridad y privacidad cerradas el mismo día

Se revisó ISYOÜ completo, como lo haría alguien que busca romperlo: las reglas que deciden quién puede leer y escribir cada dato, las funciones del servidor, los caminos del dinero y 32 pantallas en teléfono y escritorio. Cada sospecha se comprobó de la única forma que no deja dudas: intentando el abuso contra una copia local de las reglas. Los doce intentos pasaron, así que los doce huecos eran reales.

Los dos más serios tocaban lo más privado. Los mensajes directos se podían leer con solo tener una cuenta: el identificador de cada conversación se arma con los de sus dos personas, que son públicos, y la regla no comprobaba que quien leía fuera una de ellas. Y cualquier cuenta podía editar la publicación de otra: cambiarle el título o el video, o dejar su contador de compras en cero para después borrarla. Ahora solo las dos personas de una conversación la leen y escriben, y solo el autor edita lo suyo; los demás únicamente suman lo que la app suma al mirar, dar me gusta, dejar propina o comprar, de a uno y sin poder restar.

Lo demás iba por el mismo camino. Cada vez que alguien retiraba, la app guardaba sus datos bancarios en el perfil público: titular, cuenta, documento y teléfono. Ahora van en un espacio privado que solo leen la persona y administración, y lo que quedó de antes se está moviendo solo. También se cerró que alguien pudiera:

• dejar avisos falsos con enlaces en la bandeja de otra persona («Recibiste 500 ISY, confirma en…»);
• escribir el documento de identidad de otra persona en su propia verificación y bloquearle la suya;
• ponerse la insignia premium;
• usar sin límite el asistente de inteligencia artificial, que paga la plataforma.

Cada puerta cerrada quedó con una prueba automática que vuelve a intentar el abuso y otra que confirma que lo que la app hace de verdad sigue funcionando. Así, si mañana alguien afloja una regla sin querer, las pruebas fallan antes de llegar a producción. Todo quedó desplegado en la plataforma principal y en el respaldo.

Suscripciones que nunca se renovaban, un «Pago fallido» que sí cobraba y lives de pago que Explorar no dejaba abrir

La misma revisión encontró fallas que no eran de seguridad sino de plata. La más grande, en las suscripciones a creadores. Las creaba la app después de cobrar, y guardaba la fecha de renovación como texto, mientras el servidor busca fechas. Nunca se encontraban: una suscripción pagada una vez quedaba activa para siempre, sin volver a cobrarse, y el creador perdía su ingreso de cada mes. Además, la regla dejaba crear una suscripción activa sin pagar nada. Ahora la crea el servidor en el mismo cobro, con el precio que fijó el creador y una fecha de verdad. A las viejas que ya habían pasado su fecha no se les cobra de golpe lo atrasado: se cierran con un aviso para volver a suscribirse. Y cancelar ya no corta el acceso antes de que termine lo pagado.

En el chat, pagar una solicitud de cobro mostraba «Pago fallido» aunque el dinero sí había salido, y la solicitud quedaba pendiente para pagarse otra vez. La app intentaba marcarla pagada después del cobro y las reglas no se lo permitían. Ahora el servidor cobra y la marca pagada en la misma operación: pasan las dos cosas o ninguna.

En Explorar, todo live con entrada, para compradores o de El Palco salía como «Solo suscriptores», con candado. Quien quería comprar la entrada no podía ni abrirlo, aunque desde el inicio sí entraba. Ahora cada live muestra su acceso real («Entrada · 5 ISY», «El Palco», «Para compradores») y la pantalla del live cobra lo que haga falta.

Y tres detalles que se veían:

• El centro de recompensas seguía en «Mayo · Cierra el 31 de mayo», con junio «por venir», en pleno octubre. Las misiones nunca vencieron, así que ahora se agrupan por lo que piden y no prometen plazos que no existen.
• El formulario de retiro podía quedar en un método oculto que siempre fallaba.
• Cada visita nueva a la app dejaba un error del servicio de notificaciones. En tres visitas nuevas a la app publicada, ya no aparece.

El centro de recompensas antes y después, capturado en el banco de pruebas con datos de ejemplo.

ISY Credits ahora es un Marketplace, y se puede comprar sin salir del live

La sección de ISY Credits era una billetera: saldo, recargar y retirar. Desde hoy es un Marketplace. Empresas verificadas venden productos físicos, archivos digitales o servicios, y cualquier persona los compra con su saldo en ISY. El botón «Comprar» de arriba ahora lleva a la tienda; el saldo sigue a un toque, como «Mi saldo».

Lo nuevo de verdad está en las transmisiones. El creador elige qué productos muestra en su live y fija uno, que aparece abajo, en la zona del pulgar, con su precio y el botón «Comprar». Quien mira abre la ficha y paga en una hoja compacta, sin salir de la transmisión. Por cada venta hecha en su live, el creador cobra la comisión que fijó el vendedor. En el Marketplace, una fila «Comprando en vivo» muestra qué productos se están vendiendo en ese momento y quién los muestra.

Todo lo que mueve dinero lo decide el servidor, no la app: el precio sale del producto guardado, y la comisión solo se paga si el live está en curso y su anfitrión estaba mostrando ese producto. Lo que reciben vendedor y creador queda retenido como protección del comprador. Si confirma que lo recibió, se libera antes; si reporta un problema, la plata sigue ahí hasta que administración decida, desde una pestaña nueva del panel, si reembolsa o libera el pago.

Comprar dentro del live, de la tarjeta fijada al pago. Banco de pruebas con datos de ejemplo.

La compra desde el Marketplace: catálogo, ficha, pago y confirmación.

Después de comprar: el seguimiento de quien compra y el panel de quien vende.

La pestaña nueva de administración para resolver disputas.

Una historia en video que no se veía ni se escuchaba, y lo que llegó con el arreglo: me gusta, textos y stickers

El reporte fue directo: se subió un video como historia y nadie lo veía. La ruedita de carga giraba y no salía ni imagen ni sonido. El archivo estaba bien hecho; el problema era su peso: una grabación de pantalla del teléfono, 63 MB para 17 segundos, a unos 28 Mbps. Con una conexión móvil normal eso no alcanza a llegar. Se midió en un teléfono simulado a 12 Mbps: en 8 segundos de espera avanzaban 2 de video.

Los videos de las publicaciones ya se comprimen en el servidor, pero las historias habían quedado fuera a propósito, con la idea de que «viven 24 horas y no vale la pena». Era al revés: justo porque viven un día, tienen que verse desde el primer minuto. Ahora el video se prepara en el propio teléfono antes de subirlo, como hacen las apps de historias más usadas: queda en 1080p, 30 cuadros por segundo y unos 4 Mbps, con el índice al principio para que empiece a sonar apenas llegan los primeros datos. Mientras se prepara, la persona puede seguir escribiendo o poniendo stickers.

El visor también dejó de fallar en silencio. Si el teléfono no deja arrancar el video (por ejemplo, en modo de ahorro de batería), aparece «Toca para reproducir» en vez de una pantalla negra. Si un video no se puede leer, lo dice y pasa a la siguiente historia en vez de saltarla sin explicación.

Con el arreglo llegaron tres cosas que se pidieron: me gusta en las historias (el autor ve cuántos y de quién, y recibe un aviso), y textos y stickers al crearlas: nueve colores, tres estilos de texto, stickers por categorías, la hora y menciones. Todo se mueve con el dedo, se agranda y se gira con dos dedos, y se borra soltándolo sobre la papelera. El diseño se comparó en dos rondas con una revisión independiente que solo veía capturas: en la primera falló porque crear y ver usaban marcos distintos; en la segunda pasó.

Los textos y stickers no se «queman» en la foto: se guardan aparte y se dibujan encima al ver la historia, así se ven nítidos en cualquier pantalla y un video no hay que procesarlo dos veces. Los me gusta, como las vistas, se borran solos al vencer la historia.

Capturas del banco de pruebas: textos y stickers sobre la historia, el me gusta, la hoja de texto y la de stickers.

La revisión independiente, ronda por ronda: en la primera, crear y ver usaban marcos distintos; en la segunda, el mismo.

El Palco de Billboard solo lo habría podido ver la gente de Miami: la ciudad ahora ata al creador, no al público

La regla de la ciudad de El Palco estaba pensada al revés para el negocio. A quien compraba un cupo y lo abría desde otra ciudad, la app le mostraba «Este Palco es solo para…», aunque hubiera pagado. Vender el show de Crisaint en Billboard Latin Music Week con esa regla significaba que solo lo podrían ver quienes estuvieran en Miami.

Y al revisarlo apareció el caso contrario. El evento de Billboard tiene como ciudad «Miami Beach», que no estaba en la lista de ciudades con coordenadas, igual que cualquier ciudad escrita a mano. Para esas, nadie verificaba nada: ni el público ni el creador.

Ahora la regla es la que tiene sentido: el público ve su palco desde cualquier ciudad, y el creador sí tiene que estar en la ciudad del evento para empezarlo. Se comprueba con la ubicación del dispositivo, a menos de 60 km del centro (el área metropolitana cuenta). La dirección IP no se usa para confirmar, porque en datos móviles miente. Sin permiso de ubicación el show no empieza, y el mensaje explica cómo activarlo. Las ciudades escritas a mano se ubican con un buscador de lugares público.

Lo que ve el creador al poner la ciudad del evento.

La comprobación del creador ocurre en la app. Llevarla al servidor, para que no se pueda saltar desde un navegador manipulado, queda como siguiente paso.

Crear, rediseñado, e infoproductos: cursos con página de venta, garantía y cupones

La pantalla de crear mezclaba todo y cada publicación salía con la categoría «Digital Art» sin importar qué fuera. Ahora empieza con una pregunta, «¿Qué quieres crear?», y tres caminos: una publicación (foto, video o carrusel, con su categoría real, gratis o de pago, y la vista previa de cómo se verá), una historia o un infoproducto.

El infoproducto es nuevo: un curso, un e-book o una plantilla, armado por pasos y con vista previa en vivo. Tiene módulos y lecciones (video, audio o documentos), página de venta con el temario, garantía de 0, 7, 14 o 30 días y cupones de descuento. Quien compra ve su progreso y puede pedir el reembolso dentro de la garantía. El creador ve sus ventas, los motivos de los reembolsos y maneja sus cupones.

La parte delicada fue el dinero. Lo ganado por una venta que todavía está en garantía no se puede gastar ni retirar hasta que la garantía vence: si hay reembolso, la plata sigue ahí. El cupón lo calcula el servidor, no la app, y el reembolso revierte la parte del creador, del promotor y del manager. Si un reembolso deja una deuda, se descuenta sola de las ganancias siguientes.

Del «¿qué quieres crear?» al curso comprado, con un infoproducto de ejemplo.

Cinco palcos llevaban desde agosto «en vivo», y los creadores no podían borrar un evento

En «Mis Palcos» faltaban eventos. Eran cinco palcos que habían quedado marcados como «en vivo» desde agosto y septiembre: sus shows terminaron antes de que existiera el cierre automático, y con el filtro por fecha no caían en ninguna sección. Ahora aparecen en «Pasados».

De paso, Mis Palcos se ordenó en Borradores, En venta y Pasados, con los compradores de cada evento. El creador puede eliminar un palco que nadie compró (si alguien compró, no se puede) y cerrar la venta. Un palco cuyo día ya pasó deja de venderse también en el servidor, no solo en la pantalla; quien compró conserva su cupo, y el creador puede cambiar la fecha para reabrir la venta. Los eventos de ensayo ya no aparecen en el inicio.

Mis Palcos por secciones, con datos de ejemplo.

Editar el perfil se borraba solo cada 30 segundos, y la foto nueva volvía a la anterior

Parecía que «Tomar foto» y «Galería» no funcionaban: la foto se subía y un momento después volvía la anterior, y lo que se estaba escribiendo se borraba. La causa no estaba en la foto. La app avisa cada 30 segundos que la persona sigue en línea, y cada aviso hacía que el formulario de editar perfil se volviera a llenar con los datos guardados, encima de lo que se estaba editando.

Ahora el formulario se llena una sola vez, al abrirlo. Y si el saldo no cambió, la app ya no redibuja todo con cada aviso de «en línea», lo que también la hace un poco más liviana.

Una pasada de pulido por las pantallas principales

Se revisaron una por una las catorce pantallas principales, en teléfono y en computador, con una revisión independiente que las comparaba contra una regla de calidad escrita. Lo que se corrigió, en resumen: un solo color de acento en lugar de muchos, sin brillos ni degradados decorativos, y el rojo solo para «en vivo» y el naranja solo para la plata.

En los textos: todo en español (quedaban «All Tasks», «Born», «Metaverse», «hold», «stream»), sin nombres de proveedores externos en las pantallas de pago, y con la marca bien escrita. Las ganancias muestran su equivalente en pesos y los montos usan el formato colombiano (128,50 y no 128.50). Se quitaron tres eventos «próximos» que estaban inventados en el código y se reemplazaron por un estado vacío honesto, y 114 textos que estaban en 10 píxeles subieron a 11 para que se lean.

Antes y ahora, con los mismos datos de ejemplo: billetera, perfil y recompensas.

Carruseles de hasta 10 fotos o videos, e historias de 24 horas

Dos formatos que los creadores pedían. El carrusel: una publicación con hasta 10 fotos o videos, que se ordenan, se quitan o se agregan antes de publicar; el primero es la portada. Se sube uno por uno con «Subiendo 3 de 7», y si uno falla se reintenta sin volver a subir los demás. En una publicación de pago, el candado dice cuántos archivos incluye.

Las historias: una foto o un video que se ve 24 horas arriba del inicio y de Comunidad, y después desaparece. Solo las publican cuentas verificadas, y el nombre del autor se lee de su perfil, así nadie puede publicar una con el nombre de otro. El visor funciona como la gente espera: tocar para avanzar o volver, mantener para pausar, deslizar para cambiar de creador o cerrar. El autor ve quién la vio. Al día siguiente se agregó el encuadre de la foto antes de publicar: moverla, acercarla y elegir entre llenar el marco o mostrarla entera.

Los archivos de las historias se borran solos a las 25 horas, y los de los carruseles reciben la misma compresión, protección y limpieza que el resto de los videos.

La bandeja de historias, el carrusel y quién vio tu historia.

«Recomendados» y «Trending» nunca ordenaron nada, y Comunidad se cortaba en el teléfono

Al revisar Comunidad apareció un error que venía de antes: «Recomendados» y «Trending» ordenaban por los me gusta como si fueran un número, pero se guardan como una lista de personas. El orden nunca funcionó, y el contador mostraba identificadores en lugar de una cifra. «Recién publicado» ordenaba por un campo de fecha que las publicaciones no tienen. Las tres listas ahora ordenan por lo que dicen.

El diseño también se arregló. En el teléfono, una sola tarjeta ocupaba toda la pantalla; ahora son dos columnas, con las categorías siempre a la vista. En el computador se forzaban cuatro columnas en poco espacio, y los títulos se cortaban y el precio quedaba encima del texto. Las historias también aparecen arriba de Comunidad.

Comunidad después del arreglo, en computador y en teléfono.

Medidas propias para cada formato, una guía para creadores y «Únete al Palco» en el inicio

Cada formato tiene ahora su medida fija: las publicaciones en 3:4 (1080 × 1440) y los Clips en 9:16 (1080 × 1920), iguales en el inicio, Comunidad, el perfil y la vista previa al compartir un enlace. Antes convivían varias proporciones, y la misma foto se recortaba distinto en cada lugar.

Para que los creadores sepan qué subir, hay una guía de formatos con las medidas, la zona segura donde no tapan los botones y láminas listas para compartir; habla solo de ISYOÜ. Y el carrusel del inicio estrenó una lámina, «Únete al Palco», con Sümy recomendando los eventos, armada en código y no como una imagen fija, para que se vea nítida en cualquier pantalla.

Una de las láminas de la guía de formatos.

El inicio carga en menos de 3 segundos, y los videos ya no se descargan solos

El inicio y Explorar se sentían lentos en cuanto aparecían videos. En lugar de adivinar, se midió todo en frío, como lo vive un teléfono de gama media con 4G: sin nada guardado, con el procesador frenado y la conexión recortada. Cada cambio se volvió a medir, y una revisión independiente, que solo veía los números, decidía si pasaba. Hicieron falta cinco rondas.

El hallazgo principal no era obvio. Las tarjetas, la ventana del video y el buscador usaban el video mismo como imagen de portada, y en las publicaciones viejas la «miniatura» también era el video. Solo con abrir la app, sin tocar nada, el teléfono bajaba más de 1 MB de video, y una pantalla de 30 tarjetas pesaba 67 MB. Ahora cada publicación tiene una portada de verdad, generada en el servidor: una imagen liviana para las fotos y un cuadro del propio video para los videos.

El segundo hallazgo era el peso de los videos al reproducirlos. Algunos pedían entre 4 y 18 Mbps, y uno estaba en 4K, en una red 4G que da unos 4. Ahora cada video público tiene además una versión liviana en 720p: la app la elige en conexiones lentas y en pantallas de teléfono, y deja la completa para las conexiones rápidas. Mientras el video carga, en vez de una pantalla quieta, ahora gira un indicador.

Las versiones livianas de los videos viejos se generan de a poco, unas 40 por noche. Queda pendiente la de los videos de pago: como solo los abre quien los compró, su versión liviana tiene que estar cerrada de la misma forma, y eso va aparte.

El inicio estrena «Experiencias ISYOÜ»: el artista oficial al frente

El banner del inicio, con órbitas girando y texto en degradado, no vendía nada. Lo reemplaza «Experiencias ISYOÜ»: hasta tres eventos de El Palco destacados, con el artista como protagonista, y debajo un carril de próximos eventos con fecha, lugar, precio y cupos. Cada tarjeta entera es el enlace, y el carrusel se pausa con el mouse, con el teclado o si la pestaña no está a la vista.

La decisión de fondo fue de negocio: ese espacio es solo para el artista oficial y las marcas que se publiciten. Los eventos de otros creadores siguen a la venta y aparecen en el carril, pero nunca en el banner, y el panel ni siquiera ofrece destacarlos. El primero en ocuparlo es Crisaint en Billboard Latin Music Week, con el anuncio «Venta de palcos próximamente»: sin precio ni cupos todavía. El día que se ponga a la venta, el mismo banner pasa solo a «Reservar».

El respaldo se quedó sin cuota, y su propia alarma lo empeoraba

A las 7 p. m. llegó la alerta que se armó para esto: el respaldo no estaba copiando. El segundo proyecto, el que recibe una copia de cada cambio, había quedado sin su facturación activa y había vuelto al límite gratuito diario. Ese límite no alcanza para seguir el ritmo de la plataforma, y esa tarde se acabó.

Al revisarlo apareció algo peor. Cada falla del espejo escribía un registro de error, y ese registro, como todo lo demás, también intentaba copiarse al respaldo. Esa copia fallaba y escribía otro registro. En dos horas se acumularon más de 10.000, y cada uno gastaba la cuota que quedaba. Ahora el espejo no copia sus propios registros de error, con una prueba que lo cuida.

La lección queda anotada: un respaldo depende también de que alguien lo pague. Desde ahora, ante una alerta de cuota, lo primero que se revisa es la facturación del respaldo.

Crisaint es el artista oficial de ISYOÜ, rumbo a Billboard Latin Music Week

La página de influencer oficial pasa a ser /artista-oficial, dedicada a Crisaint, con la misma línea gráfica de las propuestas que se le presentaron. Vende el Palco de su presentación en Billboard Latin Music Week y trae un formulario para las marcas que quieran estar ahí. Ese formulario está protegido contra el abuso: un campo trampa para los robots, límites por hora y por día, y cada solicitud llega por correo al equipo. La dirección vieja redirige sola, y la insignia de Artista Oficial pasa a su perfil.

Se grabó además un video recorriendo la página, con subtítulos, gráficos y un presentador virtual, para compartir con el artista y las marcas. Para que el recorrido saliera limpio, la página dejó de animar su entrada cuando la visita un navegador automático; antes, en el video aparecían tramos en negro.

Marcas aliadas en el live del Palco, gestionadas desde un solo lugar

Los palcos del artista oficial muestran ahora una barra de marcas aliadas arriba del live: ISYOÜ a la izquierda y los patrocinadores a la derecha, todos al mismo tamaño. La parte de abajo queda libre para el carrito y la compra. Si se cambia un logo, se ve en el live sin recargar.

Las marcas se manejan desde una pestaña nueva del panel, «Marcas aliadas»: un catálogo con nombre, logo y estado, y la asignación de hasta seis marcas por palco, con orden y vista previa en teléfono. Pausar una marca la quita de todos los palcos donde aparece, y al reactivarla vuelve a su lugar. Solo la administración puede editarlas, y las reglas lo verifican con pruebas: cualquiera ve la barra, nadie más la cambia.

Volvió la plataforma, y el respaldo pasó su primera prueba de verdad

La plataforma principal volvió el 5 de octubre a las 4:42 p. m., después de unas 36 horas suspendida. Esa misma noche el espejo hizo lo que estaba esperando: se llenó. Al día siguiente se comparó todo, pieza por pieza, contra el original, y no se dio nada por bueno sin contarlo.

La base se recorrió nivel por nivel, porque hay datos guardados dentro de otros datos: los mensajes de un chat viven dentro del chat, que a su vez vive dentro de la cuenta. El más profundo baja tres niveles, y el espejo cubre justo esos tres. Las 68 colecciones, sus 26 tipos de subcolecciones, los 3.754 archivos y las 904 cuentas coinciden uno a uno.

La revisión encontró tres cosas que no estaban bien, y las tres se habrían descubierto en el peor momento. La primera: la copia diaria fuera del proveedor de nube falló su primera noche, porque una pieza del código no cargaba como debía. Al arreglarla apareció la segunda: los videos más pesados, de casi 1 GB, se cargaban enteros en memoria para copiarlos y la agotaban. Ahora pasan en flujo, sin cargarse nunca enteros, y la copia completa salió entera.

La tercera era la más seria. El respaldo daba por hecho que nadie entraba con contraseña, y no era así: 124 de las 904 cuentas lo hacen. El día del cambio, esas personas habrían encontrado su cuenta en el respaldo sin poder abrirla. Ahora viaja también la contraseña, pero nunca la contraseña en sí: viaja solo su versión cifrada, la misma que guarda la plataforma principal, y se carga con los mismos parámetros de cifrado. Se probó con una cuenta creada para eso: entró al respaldo con su contraseña de siempre, y con una equivocada fue rechazada.

Hubo dos agregados más. La copia de fuera del proveedor de nube no llevaba las cuentas, porque viven en un servicio distinto al de las bases de datos. Si el proveedor cayera entero, habría datos pero no a quién devolvérselos. Ahora la lista viaja cada día, sin contraseñas: fuera del proveedor no se pueden verificar, y quien la usaba entraría con el código que llega al correo. Y cada copia diaria que termina bien manda un correo de confirmación al equipo. Un silencio ya no se confunde con «todo bien».

Una auditoría de cada salida de dinero: cuatro puertas cerradas el mismo día

Después de la suspensión se revisó, uno por uno, cada camino por el que sale dinero real de ISYOÜ: retiros, avisos de pago, transferencias entre personas y permisos de administración. Aparecieron cuatro puertas que, en teoría, dejaban mover saldo o dar por hecho un pago que nunca ocurrió. Ninguna se usó: la conciliación de saldos cuadra igual desde el 8 de septiembre, y los únicos movimientos de ese tipo eran pruebas del propio equipo. Las cuatro se cerraron ese mismo día, en la plataforma principal y en el respaldo.

El cambio de fondo es de enfoque. Antes las reglas decían qué no se podía tocar, y una lista así falla en silencio el día que alguien agrega algo y se olvida de anotarlo. Ahora es al revés: el perfil de una persona solo acepta los campos permitidos, y lo demás se rechaza. Ser administrador lo decide la cuenta de inicio de sesión, nunca un dato que se pueda editar. Y un aviso de pago solo vale si trae el número de operación que nos dio el propio proveedor de pagos.

Además, ahora todo envío de dinero desde la tesorería pasa antes por un freno con topes diarios. Si algo intenta sacar más de lo normal, se detiene y avisa, aunque el pedido parezca válido. Y cada despliegue termina con una auditoría que revisa qué queda abierto sin sesión: si aparece algo que no está en la lista de lo permitido, el equipo se entera en ese momento, no semanas después.

Videos un 60 % más livianos, sin que se note la diferencia

Al copiar el respaldo apareció un dato que nadie miraba: había videos de casi 1 GB. Las grabaciones de los lives salían del navegador sin comprimir, y los videos del teléfono se subían tal como salían de la cámara. Eso cuesta en todos lados: en lo que se guarda, en lo que se respalda y, sobre todo, en los datos móviles de quien los mira.

Ahora cada video que se sube se recomprime solo, a los pocos minutos, a un formato que reproduce cualquier teléfono, sin pasar de Full HD. La configuración no se eligió a ojo: se midió sobre videos reales de la plataforma, comparando cuadro a cuadro contra el original, y se fijó la que queda por encima del punto en que la diferencia ya no se nota. Si el video no baja al menos un 20 %, se queda el original. Los de pago siguen cerrados: solo los abre quien los compró.

Los videos viejos se recomprimen de a poco, unos 30 por noche, empezando por los más pesados. El original se guarda 7 días más, por si algo hay que revertir. Y se cerró un gasto silencioso: borrar una publicación solo la ocultaba, y su archivo seguía guardado y pagándose para siempre. Ahora, 30 días después del borrado y solo si nadie la compró, sus archivos se eliminan de verdad.

ISYOÜ ya no depende de un solo lugar: un segundo proyecto, en espera

La suspensión del 4 de octubre dejó una lección sin matices: todo vivía en un solo proyecto y no había ninguna copia afuera. Bases de datos, archivos, cuentas y agentes AI cayeron juntos, y no había a dónde ir. En un día se armó lo que faltaba: un segundo proyecto, aislado y con otra cuenta de facturación, listo para que ISYOÜ vuelva a funcionar desde ahí en minutos.

Son tres capas, y cada una cubre un riesgo distinto. La primera es un espejo: cada cambio de la plataforma principal llega al segundo proyecto en segundos, y cada cuenta se copia con su mismo identificador, para que la persona entre con su misma cuenta de Google y vea lo suyo. La segunda es un historial: si alguien borra algo por error, el espejo también lo borraría, así que el segundo proyecto guarda cómo estaba todo minuto a minuto durante 7 días y una copia diaria por 14 semanas. La tercera es una copia diaria fuera del proveedor de nube, con un candado de 30 días que impide borrarla o reemplazarla, ni siquiera desde nuestras propias cuentas.

De un solo lugar a tres capas — y lo que pasa si vuelve a caer.

Mientras la plataforma principal funciona, el segundo proyecto recibe copias y no actúa: sus tareas están pausadas y sus agentes AI, cerrados. Sin eso, cada copia de una notificación dispararía otra notificación, y cada persona recibiría todo dos veces. Y si algo de su configuración falla, se queda quieto: nunca se convierte por error en una segunda plataforma. El día que haga falta, un solo comando lo enciende, mueve el tráfico y comprueba que responde. Lo máximo que se pierde son los últimos segundos de cambios y, como mucho, cinco minutos de cuentas nuevas.

Ese ingreso fallido es justo lo que hay que encontrar en un simulacro y no en una emergencia. Tenía dos causas. Una pieza que el inicio de sesión necesita solo existía si el sitio tenía algo publicado, y el sitio estaba vacío. Y el ingreso pasaba por un dominio distinto del que la persona visitaba, que es el mismo error que en septiembre dejaba afuera a quien entraba desde Safari. Ahora cada dominio inicia sesión por sí mismo.

Queda un paso que depende de terceros: el espejo se llena el día que vuelva la plataforma principal, porque mientras está suspendida no se puede leer nada de ella. Para ese día ya quedó escrito el manual de emergencia, con cuándo cambiar, cómo hacerlo y cómo volver sin perder lo que se escribió en el segundo proyecto.

Mientras tanto, lo que ve la gente: un aviso claro y una versión de prueba sin riesgo

Con la plataforma principal suspendida, quien abría ISYOÜ se encontraba con «sitio no encontrado»: ni una explicación, ni una salida. El dominio pasó a una red que se para delante de cada pedido y decide a dónde va, y eso permitió cambiar la experiencia sin tocar la plataforma caída.

isyou.io responde siempre: si la página principal no contesta en 8 segundos, se sirve sola una copia, sin que nadie intervenga. app.isyou.io muestra un aviso con la marca de ISYOÜ: qué pasa, que no hay que hacer nada porque la página reintenta sola cada dos minutos, y un botón a la versión de prueba. Y www.isyou.io ahora lleva a isyou.io, para que las visitas no se repartan en dos direcciones.

Capturas reales del 5 de octubre, con la plataforma principal suspendida.

test.isyou.io es la versión de prueba: se puede entrar con Google, transmitir en vivo y crear un palco sin que nada cueste dinero real. Una bienvenida explica qué se puede hacer y qué no, y en modo prueba no hace falta la verificación de identidad: la cuenta queda habilitada desde que entra. Esa habilitación existe solo en la pantalla de la versión de prueba; en las bases de datos nadie queda verificado.

Hubo un hallazgo a mitad de camino. La primera versión de prueba vivía dentro del segundo proyecto, el del respaldo, y eso era un error de diseño: lo que la gente hiciera probando quedaría mezclado para siempre con la copia de los datos reales, porque la copia agrega y nunca borra. Y el día de copiar, la «prueba» se volvería un sitio con datos y pagos reales. Se corrigió ese mismo día: la versión de prueba pasó a un proyecto propio, que no admite agentes AI y por lo tanto no puede cobrar nada, aunque alguien se equivoque. Del respaldo se borraron las 6 cuentas de prueba y todo lo que habían creado, y la copia de datos reales ahora se niega a correr si encuentra restos de prueba.

La plataforma suspendida por una llave a la vista — y las tres barreras para que no vuelva

El 4 de octubre el proveedor de nube suspendió la plataforma principal de ISYOÜ. El motivo: llaves privadas de servicios externos publicadas donde cualquiera podía verlas. Con la suspensión cayó todo a la vez: las bases de datos, los archivos, el inicio de sesión y los agentes AI. Nadie podía entrar a su cuenta.

La causa estaba en cómo se armaba la app. Una plantilla de inicio de proyecto, usada al comienzo, copiaba las llaves de la configuración dentro del código que descarga el navegador, sin avisar. Cada publicación del sitio las dejaba a la vista de cualquiera que lo abriera, y nada lo revisaba. Al buscar a fondo aparecieron más: llaves escritas en el código de la app móvil retirada, que cualquiera podía sacar descomprimiéndola.

Por dónde salía la llave, por dónde pasa ahora y las tres barreras. Diagrama ilustrativo.

Ahora ninguna llave privada sale del servidor. La app pide el servicio con la sesión de la persona, y un agente AI lo atiende: exige sesión, solo acepta lo que la plataforma usa y pone un tope a cada pedido, para que nadie lo convierta en una puerta abierta a costa de ISYOÜ. Y para que no vuelva a pasar hay tres barreras, una detrás de otra: un cambio que trae una llave no se puede guardar, un sitio que contiene una llave no se puede publicar, y cada envío al repositorio se vuelve a revisar solo. Las únicas que pasan son las llaves públicas por diseño de la app web, restringidas a nuestros dominios y a los servicios que usan.

Ese mismo día se envió la apelación, y la seguridad de la empresa sumó alertas de gasto, alertas de actividad sospechosa y un contacto de seguridad que recibe los avisos del proveedor. Al cierre de esta entrada la apelación sigue en revisión. Lo que sí está resuelto es la otra mitad del problema, contada arriba: la plataforma ya no depende de un solo lugar.

Cinco meses sin referidos — y ahora se sabe de dónde llega cada cuenta

Al preparar el enlace del reel de El Palco para que contara referidos apareció algo que nadie había visto: desde el 30 de abril ninguna cuenta nueva quedó registrada como referida. Los enlaces con código funcionaban, la persona se registraba, pero el último paso fallaba en silencio. La plataforma tenía 36 referidos, todos de antes de esa fecha.

La causa: ese último paso lo hacía el teléfono de la persona nueva, y además de marcar su cuenta intentaba sumar un punto en la cuenta de quien la refirió. Con el endurecimiento de la seguridad, nadie puede escribir en la cuenta de otro, así que el paso completo se rechazaba. Ahora lo hace el servidor, una sola vez por cuenta y solo en sus primeras 48 horas.

De paso, cada cuenta nueva guarda de dónde llegó: la campaña, la red, la página por la que entró y el código de referido. Con eso se puede medir el camino completo, del reel en Instagram a la cuenta creada. Y cambió cuánto gana quien refiere. El programa anterior pagaba el 1% (10% a socios) de lo que retenía ISYOÜ en las compras del referido, y solo por 12 meses. Ahora, del 5% que retiene ISYOÜ en cada venta, el 15% es para quien refirió al creador que vende, en todo lo que ese creador venda y sin límite de tiempo. Si ISYOÜ le asignó un manager al creador —como los artistas de Nelson—, la comisión es del manager. Lo acumulado con el programa anterior se puede seguir cobrando, y los términos de servicio ya dicen la regla nueva.

También se cerró una puerta: el referidor de una cuenta se podía cambiar desde la propia app. Ahora solo lo escribe el servidor.

El Palco, contado con la tarde del estreno: el reel BALCODER × ISYOÜ

La primera transmisión oficial dejó material de verdad: CRISAINT MUSIC grabando en vivo desde sus gafas, lo que veía el público en la app y el equipo en el Café Zepelín. Con eso se armó un reel de 35 segundos que explica El Palco sin necesidad de sonido: qué es, cómo se vive y por qué es distinto. Se publicó como colaboración en las cuentas de BALCODER e ISYOÜ.

Cada texto del reel se revisó contra lo que la plataforma hace hoy, no contra lo que se quisiera decir: cada palco vive en una ciudad y solo entra quien está ahí, el cupo se paga con ISY y la propina llega completa al artista. Las pantallas que mostraban datos de conexión del día del show se dejaron fuera.

Cuatro momentos del reel. Verlo en Instagram.

La primera transmisión oficial — y el show que el artista no pudo terminar

El 30 de septiembre salió al aire la primera transmisión oficial de ISYOU: CRISAINT MUSIC, en vivo con sus gafas inteligentes, en un palco desde Medellín. La señal llegó bien durante 23 minutos. Entonces el artista salió un momento de la pantalla de transmisión, y al volver la app le ofrecía empezar un show nuevo: había olvidado que estaba en vivo. No tuvo forma de terminarlo desde ISYOU; lo cortó desde su app de transmisión.

Al reconstruir la tarde con los registros aparecieron dos cosas más. El show no se grabó: en una transmisión externa el video nunca pasa por el navegador del creador, que es donde ISYOU grababa — así que no había nada que recuperar, ni lo habría habido terminándolo bien. Y el palco siguió anunciándose «EN VIVO» después de terminado, igual que otros dos de días anteriores.

Ahora, al abrir la pantalla de transmisión, ISYOU le pregunta a la base —no a la memoria de la pantalla— si el creador tiene un show al aire, y le ofrece volver a él o finalizarlo. Y el palco sale del aire solo cuando su transmisión termina, sea cual sea el camino por el que termine. No se cierra: vuelve a estar a la venta, porque el artista puede volver a transmitir para ese mismo palco cuando quiera.

Recreación con los datos del show del 30: lo que veía el artista, lo que ve ahora, y el cierre de una transmisión externa.

El palco en el perfil del artista, antes y después — y la regla que ahora aplica el servidor.

De paso se cerró un engaño menor: al terminar una transmisión externa, el botón «guardar repetición» creaba una publicación de video que en realidad era la foto de perfil. Ahora, si no hay grabación, se dice.

Y el mismo día quedó resuelta la causa de fondo: las transmisiones externas ahora se graban en la nube, del lado del proveedor de video, sin depender de ningún navegador. El archivo queda en una carpeta que nadie más puede leer —el show de un palco es contenido de pago— y el artista lo descarga desde su pantalla de transmisión con un enlace que vence en dos horas. Costo: los primeros 10.000 minutos de cada mes son gratis; después, unos 36 centavos de dólar por hora de show.

Por dónde pasa el video, antes y ahora — y dónde encuentra el artista sus grabaciones.

Un video que solo se veía en Safari — y otros veintisiete igual

Un creador publicó un video grabado con su teléfono y no se reproducía en ningún navegador. Ni un mensaje de error: un recuadro negro y nada más. El archivo estaba perfecto por dentro —los mismos formatos de video y audio que usa toda la web— pero venía envuelto en un contenedor de Apple, y así se guardó. Chrome, Firefox y Edge rechazan ese envoltorio sin siquiera intentar leerlo. Solo Safari lo abría, que es justo el navegador del teléfono donde se grabó: quien publicaba veía su video perfectamente y no tenía forma de sospechar que su público no.

Al revisar el catálogo completo, el caso puntual resultó ser un patrón: 27 publicaciones vivas, de 11 creadores distintos, estaban exactamente igual — el 14% de todos los videos de la plataforma. Una de ellas, de pago.

Las 28 publicaciones quedaron reparadas sin recomprimir un solo fotograma: el video por dentro ya era correcto, solo había que guardarlo con el envoltorio y el tipo que los navegadores sí leen. Los archivos originales no se borraron.

Y la causa de raíz quedó cerrada donde nace: al elegir el video, antes de subirlo. Lo que se puede corregir se corrige solo y en silencio; lo que no tiene arreglo sin recomprimir se rechaza ahí mismo, diciendo qué pasa y qué hacer. Publicar algo que nadie puede ver es peor que no dejar publicarlo.

El último candado del contenido de pago — y lo que apareció al ir a cerrarlo

Quedaba un cabo suelto de la semana: la lista de «contenido desbloqueado» vivía en el documento del propio comprador, que él mismo puede escribir. Ya no daba acceso al archivo —eso lo decide el servidor desde la semana pasada— pero mientras siguiera siendo suya, la interfaz podía mentir.

Al ir a cerrarlo apareció algo bastante peor: las compras no estaban dejando comprobante en el servidor. La aplicación cobraba, pero nunca le decía al servidor qué se había comprado. El comprobante es exactamente lo que el servidor exige después para entregar el archivo. O sea: quien compraba un contenido ya mudado a la bóveda pagaba, y el archivo no se le abría.

Corregido en los cuatro puntos de compra de la aplicación, con el comprobante escrito dentro de la misma operación que mueve el saldo: o se cobra y queda constancia, o no pasa ninguna de las dos cosas. Recién entonces tuvo sentido bloquear la lista del usuario, que ahora se lee de los comprobantes del servidor y nadie puede escribir desde la aplicación.

De paso apareció un tercer candado pintado, de la misma familia: el enlace que un creador vende dentro de su transmisión viajaba dentro del documento de la transmisión, que se lee sin cuenta siquiera. La aplicación se limitaba a taparlo hasta que alguien pagara. Ahora vive aparte, donde solo lo leen su dueño y el servidor, y se entrega contra el comprobante de compra.

Ocho intentos de compra caídos por cada compra que llega

Mirando el embudo completo apareció la proporción: 48 órdenes quedaron a medias y 38 fueron rechazadas, contra 10 completadas. Y con ninguna de las 86 se hacía absolutamente nada: ni recordarla, ni explicar el rechazo, ni ofrecer otro medio de pago. La orden se quedaba muda en la base de datos y la persona se iba — muchas veces creyendo que su dinero había quedado en el aire.

Ahora, al volver a la billetera, quien dejó una compra sin terminar en las últimas 72 horas la ve: cuánto era, cuándo fue, y un botón para retomarla con el mismo monto. Si el pago fue rechazado, se dice el motivo real del banco —no un «algo salió mal»— y el botón propone intentar con otro medio.

Dos decisiones de redacción que importan: a una compra sin terminar se le dice «no se te cobró nada», porque es cierto y es justo lo que la persona teme; y el botón de descartar dice que oculta el aviso en ese navegador, no que cancela la orden — desde la aplicación no se puede cancelar nada en el banco, y decir lo contrario sería mentir.

El panel iba a congelarse en 1.000 cuentas sin decirlo

El tablero de administración pedía «las cuentas» con un tope fijo de mil. Hoy hay 933. Al pasar ese número no habría fallado: habría seguido mostrando «1.000 usuarios» —y verificados, ISY repartido y progreso de migración calculados sobre una parte— sin que nadie lo notara. Un número que se congela en silencio es peor que un error.

Ahora recorre la lista completa y, si algún día llega a su tope de seguridad, lo dice en pantalla en vez de dejar creer que los totales son totales.

En la misma revisión: el buscador de creadores descargaba las 933 cuentas completas cada vez que alguien abría esa pestaña, para mostrar una lista que nadie recorre entera. Ahora trae una página, y solo baja el resto si la persona de verdad escribe algo. Menos costo por cada visita, y una pestaña que abre de inmediato.

Llamarse con una sola palabra impedía comprar, y el aviso llegaba tarde

Nuestros rieles de pago rechazan cualquier nombre sin apellido. El formulario de compra se prellena con el nombre del perfil, así que quien tenga ahí una sola palabra intentaba pagar y recibía un rechazo técnico —código 350— después de que el cobro ya había salido hacia el proveedor.

Antes el proveedor devolvía el error; ahora se corrige antes de que el cobro salga.

Lo que convirtió un caso puntual en prioridad fue medir el alcance: 101 de 886 usuarios con nombre en su perfil tienen una sola palabra, un 11%. Solo una orden había fallado por esto — el resto simplemente todavía no lo había intentado. Era una bomba de tiempo con el reloj corriendo.

Y un hallazgo que vale más que el arreglo: varios de esos nombres son literalmente «Unknown». Eso no lo escribió nadie — parece un valor por defecto al crear la cuenta. Esas personas no saben que tienen un nombre inválido, y el sistema no se los diría hasta el momento de pagar.

La comprobación va en los tres formularios de compra y también en el servidor, antes de crear la orden. Dos capas a propósito: la pantalla da el mensaje que se puede corregir, el servidor garantiza que ningún camino se salte la regla.

Ninguna publicación queda sin dueño

Al reparar las repeticiones de transmisiones aparecieron dos grupos distintos de publicaciones sin creador. Veinte eran repeticiones reales a las que solo les faltaba el campo: recuperaron a su dueño y vuelven a aparecer en el perfil de quien las grabó.

Las otras quince no eran nuestras: tenían otra estructura por completo, de una importación de otra plataforma. Sin título, sin imagen y sin autor, invisibles en la aplicación pero contando como contenido en cada consulta. Se borraron, con copia de respaldo guardada antes.

Resultado: 803 publicaciones, todas con autor identificado. Importa más de lo que parece — el autor es lo que decide quién puede editar, quién cobra y, desde esta semana, quién puede abrir el archivo de un contenido de pago.

Dos funciones llevaban meses fallando en silencio, y nadie las reportó nunca

Un creador terminó una transmisión de un minuto y eligió «guardar la repetición». No se guardó. Al revisarlo apareció algo peor que el caso puntual: esa función llevaba meses sin funcionar para nadie, y ni un solo reporte había llegado.

La causa: la publicación se creaba sin el campo que identifica a su creador, y la regla de la base de datos exige que ese campo coincida con quien escribe. Toda repetición era rechazada. En la base hay 24 repeticiones y 20 no tienen ese campo — son de cuando la regla todavía no existía. Desde entonces, ninguna más pudo guardarse.

Sospechando que no sería la única, se revisaron todas las escrituras de la aplicación contra las reglas. Apareció la segunda, idéntica en forma: cancelar una suscripción estaba prohibido para todo el mundo, y la aplicación lo intentaba igual sin manejar el error. La persona tocaba cancelar, confirmaba, y seguía suscrita — sin un solo aviso.

Ese es el tipo de fallo más caro que existe: el que el usuario atribuye a su propia torpeza. No genera tickets, no genera alertas, y va erosionando la confianza sin dejar rastro.

Lo que queda para que no se repita: un archivo de pruebas con las escrituras reales de la aplicación —la misma forma de datos que envía— corriendo contra las reglas reales. Guardar una repetición, cancelar, empezar una transmisión, registrar actividad, abrir una conversación. Si alguien cambia una regla o un dato y dejan de coincidir, falla ahí antes que en producción. Y las 20 repeticiones huérfanas recuperaron a su dueño: vuelven a aparecer en el perfil de quien las grabó.

La plataforma le impidió a un creador transmitir desde su propia ciudad

Evento de El Palco exclusivo de Medellín. Creador en Medellín. La plataforma: «no detectamos que estés transmitiendo desde ahí».

La comprobación usaba la ciudad de la dirección de internet, y en datos móviles el operador enruta el tráfico por un nodo central — normalmente la capital. Por esa vía, un teléfono «está» donde está la antena del operador, no donde está la persona. Dicho de otro modo: fallaba justo en el caso que El Palco existe para servir, alguien transmitiendo desde la calle.

Ahora se pregunta primero al dispositivo, que es la única fuente que sabe dónde está la persona, con 60 km de radio para que el área metropolitana cuente como la ciudad. Sin permiso o sin respuesta, se intenta por internet — pero una discrepancia ahí ya no bloquea: solo queda anotada. Se bloquea únicamente con evidencia positiva, y el mensaje dice a cuántos kilómetros detectó a la persona.

La regla de fondo, que aplica más allá de este caso: no saber no es motivo para cerrarle la puerta a nadie. El costo de equivocarse en contra —un show que no empieza, un cupo pagado que no se puede ver— es mucho mayor que el de un caso excepcional que se cuele. Y la pantalla previa ahora muestra qué ciudad detectamos y de dónde sale el dato, para que nadie lo descubra cuando ya es tarde.

El módulo en vivo era inusable para quien no ve la pantalla

Auditoría de accesibilidad sobre la transmisión en vivo: 19 botones no decían nada. Silenciar el micrófono, apagar la cámara, compartir pantalla, enviar una propina, mandar un mensaje. Quien usa un lector de pantalla oía «botón» y nada más — es decir, no podía transmitir ni participar.

Se corrigieron también 39 animaciones que ignoraban a quien pidió reducir el movimiento —en una pantalla con video, chat moviéndose y reacciones flotando, eso no es un detalle para alguien con vértigo o migraña—, 23 textos por debajo del contraste legible, y los regalos de pago, que ahora anuncian qué mandan y cuánto cuestan: mandar plata sin saber cuánta no es aceptable para nadie.

Vale registrar un error propio, porque la lección es de método: las primeras etiquetas se pusieron en bloque, con un script que las infería del icono. Seis salieron mal — el botón de pagar la entrada anunciaba «Cerrar». Una etiqueta equivocada es peor que ninguna: quien no ve la pantalla actúa sobre lo que se le dice, y ahí había un botón de pago presentado como si cerrara una ventana. Se revisaron una por una contra lo que hace cada botón.

La sala de espera del espectador: antes de empezar, señal cortada, y al terminar.

Del lado del espectador se rehízo la espera, que antes era un círculo girando: ahora dice de quién es el show, cuánto falta y cuánta gente espera. Y distingue dos situaciones que se veían idénticas y son opuestas: «todavía no empieza» es expectativa; «se cortó la señal» es duda — ahí se explica que el creador sigue conectado y que no cierre la pantalla.

Transmitir desde tu propio equipo: el show desaparecía solo, y el creador no tenía forma de saberlo

Un creador puede transmitir desde su propio equipo —una cámara, un computador, unas gafas— en vez de la cámara del navegador. Lo hizo, la señal salía bien, y en la plataforma no se veía nada. Pasó dos veces antes de que entendiéramos por qué.

La causa tiene su ironía: una transmisión se da por muerta a los dos minutos sin «señal de vida», y esa señal la manda el navegador del creador. Pero transmitir desde tu propio equipo significa justamente eso — no hay navegador transmitiendo, el creador puede cerrar el computador y caminar. Así que la plataforma borraba el show mientras el video seguía llegando.

Ahora la señal de vida la da el servidor: cada minuto pregunta si hay alguien emitiendo, y solo cierra tras cinco minutos sin señal. Ese margen es deliberado: un ascensor, un cambio de antena o una esquina sin cobertura no pueden tumbar un show en la calle.

Y apareció un segundo fallo, más silencioso y que afectaba a todos: la función que la aplicación llama «transmisiones activas» devolvía todas, sin comprobar si seguían al aire. Cuatro pantallas usan esa lista y solo una filtraba por su cuenta, así que un show terminado se seguía anunciando durante media hora. Gente entrando a transmisiones que ya no existían.

Una sala de control para quien transmite a ciegas

El fallo de arriba dejó al descubierto algo peor que el fallo: aun funcionando, la pantalla no respondía la única pregunta que importa en vivo. Mostraba una dirección y una clave. Nada más. Media hora sin saber si el problema era el equipo, la aplicación de transmisión o nosotros.

Los tres estados: esperando, al aire, y señal cortada.

Se rediseñó empezando por los estados incómodos, no por el feliz — porque el estado incómodo era el problema. Arriba, siempre, la respuesta: ¿estoy al aire, y desde hace cuánto? Debajo, lo que ve el público, que no es decoración sino la prueba: si ahí se ve, se ve en todas partes.

Cuando la señal se corta, la pantalla dice hace cuánto, qué revisar y cuántos minutos faltan antes de que el show se cierre solo. Cuando la señal llega, los datos de conexión se pliegan: ya cumplieron, la pantalla es del show.

La pasada de acabado dejó siete correcciones, y dos merecen mención porque no son cosméticas. El reloj saltaba cada segundo —los dígitos no eran de ancho fijo— y en una pantalla cuyo trabajo es decirte hace cuánto estás al aire, un número que baila roba la atención que le corresponde al show. Y había un hueco sin diseñar: la señal llega, el video tarda un segundo en pintar, y en ese segundo la pantalla no decía nada — justo cuando el creador se pregunta si funcionó.

Una clave de transmisión sobrevivía a su propio show — para siempre

La encontró una pregunta, no una alerta: «si termino el show en la plataforma pero conservo la clave en mi programa de transmisión, ¿puedo seguir transmitiendo?». Se podía. Indefinidamente.

La clave nacía sin fecha de vencimiento, y quien la borraba al terminar era el navegador del creador. Cerrar la pestaña de golpe, perder la conexión o simplemente descartar el show dejaba la llave viva.

La tercera es la que convierte esto de un problema de costos en uno de confianza: el canal de un show es el identificador del creador, y no cambia entre un show y el siguiente. Una llave vieja abre la puerta de mañana.

Se cerró con dos defensas, porque una sola falla. Vigencia: la clave nace con seis horas de vida y muere sola aunque todo lo demás falle. Revocación desde el servidor: al cerrar el show y en un barrido cada diez minutos, sin depender de ningún navegador. El barrido espera diez minutos a propósito — un creador que cierra y reabre en segundos tiene que poder reconectar su equipo.

Es la misma familia del hueco de los pases de video de la semana pasada: un permiso sin vencimiento. Vale la pena nombrarlo así, porque es el patrón que hay que buscar en el resto del sistema.

Un show de pago se veía idéntico a uno gratis

La tarjeta que anuncia una transmisión —la misma en inicio, en Comunidad y en el perfil del creador— no decía si entrar costaba algo. Un show con cupo de 20 ISY y uno abierto se veían iguales. La persona entraba ilusionada y chocaba contra el cobro.

Arriba, la versión anterior. Abajo, el mismo show con su etiqueta, uno con entrada, y la versión compacta de inicio.

Eso no es un detalle estético: quema la confianza, y el siguiente show de ese creador recibe menos clics. El precio ahora va en la tarjeta, antes de entrar.

Revisarla destapó tres cosas más. Era un contenedor con un clic encima: sin teclado, sin foco visible, invisible para un lector de pantalla. Decía «LIVE» en mayúsculas, en una aplicación en español. Y sin portada quedaba rota — ahora muestra la inicial del creador sobre el fondo de marca.

El video se veía a saltos, y la culpa no era de la red

Reportado sobre la vista previa del creador: el video tartamudeaba. La causa no estaba en la conexión ni en el equipo que transmite. La instrucción que monta el reproductor estaba escrita dentro del dibujado de la pantalla, así que se interpretaba como nueva en cada cambio y volvía a llamar a «reproducir». Con un reloj corriendo en pantalla, eso ocurría cada segundo: el reproductor se reiniciaba antes de terminar de arrancar.

Lo importante es dónde más estaba el mismo error: en la vista del público. Ahí se disparaba con cada mensaje del chat y cada actualización del contador de espectadores — o sea, permanentemente en cualquier show con conversación. Nadie lo reportó nunca, y se entiende: se siente como «internet malo», no como un fallo de la plataforma. Los fallos que el usuario se atribuye a sí mismo son los que más tardan en encontrarse.

El candado del contenido de pago era solo visual: 141 archivos mudados

Un creador publica una foto o un video con precio. Quien no ha pagado lo ve borroso, con el candado encima. Esa era la experiencia — y era exactamente eso: una experiencia. El archivo original estaba detrás del desenfoque, en una dirección pública que venía dentro de la publicación.

Dicho sin rodeos: el desenfoque era de pantalla, no de contenido. Cualquiera que abriera las herramientas del navegador, o copiara esa dirección en otra pestaña, veía el original sin pagar. Y había un segundo camino aún más simple: la lista de "contenidos desbloqueados" vivía en el documento del propio usuario, que él mismo puede escribir. Anotarse un contenido bastaba.

El arreglo tenía una parte incómoda: no bastaba con cerrar la puerta nueva, había que mudar los 141 archivos ya publicados, 2,5 GB, y borrar cada original. Ese borrado es lo único que corta los enlaces que alguien pudiera tener guardados. Es irreversible, y por eso se hizo en tres tiempos: dos contenidos primero, comprobando que quedaran inalcanzables; después un lote de treinta; después el resto.

Verificado al final uno por uno, no por muestreo: ninguno conserva dirección pública, ningún original sobrevive en la carpeta abierta.

Dos hallazgos de producto aparecieron en el camino, y los dos apuntan a lo mismo. Hay infoproductos a la venta cuyo archivo ya no existe — quien los compre hoy paga y no recibe nada — y una publicación marcada como imagen cuyo archivo es en realidad un audio. Nadie comprueba, al publicar, que el archivo sirva. Es lo siguiente.

Un enlace compartido era una pared — y durante diez minutos después de cada publicación, ni siquiera abría

Un creador comparte su contenido en redes. Quien lo recibe toca el enlace y lo primero que ve es una pantalla de acceso: sin saber de quién es, qué es ni cuánto cuesta. La mayoría se va ahí, y ese es justo el momento en que alguien nuevo decide si esta plataforma le interesa.

Ahora ve el envoltorio —el creador, el título, el precio y la portada difuminada— y decide con información. Esto se pudo hacer justo hoy y no antes: hasta esta mañana, mostrar la portada de un contenido de pago habría sido regalar el archivo. Desde que el contenido vive en una carpeta cerrada, el envoltorio es solo eso.

Al probarlo aparecieron dos fallos que llevaban días activos, y ninguno se había reportado — porque los dos se ven como "el enlace no sirve", y quien lo sufre no es usuario nuestro todavía.

El primero es el más caro de los dos y el más fácil de pasar por alto: cada publicación cambia el nombre de los archivos de la app, así que durante diez minutos esa página apuntaba a archivos ya borrados. Llevaba así desde el 17 de septiembre. Es el tipo de fallo que nadie reporta: quien lo ve no tiene cuenta, no tiene a quién escribirle, y simplemente cierra.

Vale anotar un error propio: el primer arreglo atacó la parte equivocada. Se corrigió que el aviso de «abre esta publicación» no se perdiera por tiempo — pero el aviso llegaba bien; lo que faltaba era la publicación. Probar con la pantalla delante, y no solo razonar sobre el código, es lo que lo mostró.

Transmitir El Palco desde unas gafas: la investigación que terminó en no, y lo que dejó

La pregunta venía de la Gira ORIGEN: ¿se puede transmitir un show en primera persona, desde los ojos del creador, usando unas gafas inteligentes con cámara? La respuesta corta es que con ese modelo no. Lo interesante es cómo llegamos a saberlo, porque el camino dejó más de lo que quitó.

Primero revisamos lo que el fabricante publica: su kit de programación deja encender la grabación, apagarla y pedir los archivos después. Nada que entregue la imagen mientras ocurre. Podíamos haber parado ahí, pero la documentación de un fabricante no siempre cuenta todo: varias cámaras del mercado tienen una vista en vivo sin documentar. Así que fuimos al aparato.

Conclusión con evidencia propia: esas gafas graban para sí mismas y entregan archivos al terminar. No existe la imagen en curso, así que no hay programa que la pueda tomar — ni con una aplicación nuestra, ni con un puente. Lo que no existe en el aparato no se construye desde afuera.

Vale decir por qué se investigó igual: descartar bien cuesta horas; equivocarse cuesta meses. La alternativa era construir dos aplicaciones nativas sobre un kit con licencia del fabricante para descubrir al final que no había señal que transmitir.

Y el camino dejó tres cosas. La primera, la más importante: la entrada de señal externa quedó probada de punta a punta. Enviamos una señal de prueba real y entró limpia — era un pendiente desde que cambiamos de proyecto de video, y ahora está confirmado que cualquier cámara o programa que transmita puede conectarse a El Palco.

La segunda, un fallo de interfaz que apareció de paso: la pantalla de conexión externa no se podía recorrer entera — el contenido se salía por arriba y no había forma de alcanzarlo. Corregido.

La tercera es una decisión que quitamos: durante la investigación se agregó una pantalla que recomendaba una aplicación de transmisión para teléfono. Al revisarla sobraba, porque transmitir con la cámara del celular ya funciona desde el navegador, sin instalar nada. Se retiró. La conexión externa quedó para lo que de verdad sirve: un computador o una cámara profesional. Quedó el aviso que más falta hacía: que un programa diga «conectado» no significa que esté transmitiendo, y esa confusión ya nos costó una prueba entera.

Las suscripciones no se renovaban solas, y nadie lo había notado

Dos tareas diarias sostienen las suscripciones: una cobra la renovación mensual, otra avisa tres días antes del vencimiento y marca como vencidas las que ya pasaron. Al revisar la salud del sistema aparecieron ambas fallando todos los días desde que existen, en junio.

La causa era una sola línea que nunca se escribió: esas tareas le piden a la base de datos las suscripciones activas ordenadas por fecha de vencimiento, y una consulta así necesita estar declarada de antemano. No lo estaba. La base rechazaba la pregunta y la tarea moría antes de hacer nada.

El efecto encadenado importa más que la causa: como nadie marcaba vencida una suscripción, y el acceso se decide por ese estado, el acceso siguió abierto sin cobrarse. Ni renovaciones, ni avisos, ni cierres.

Se arregló, pero antes de encenderla se auditó la renovación, porque llevaba meses sin correr y el resto del sistema de pagos avanzó en agosto y septiembre. Tenía tres repartos sin aplicar: no pagaba la comisión del socio comercial vinculado a un creador, no repartía el bono por referido, y usaba una retención fija en vez de la configurada para cada creador. Una renovación repartía distinto que cualquier otra venta del mismo creador. Ahora reparte igual.

Verificado al día siguiente: ambas tareas corrieron sin errores por primera vez. No quedaron cobros atrasados por reparar.

La alarma de saldos sonó sin motivo, y eso también es un problema

Cada movimiento de saldo se revisa después de ocurrir: el sistema compara lo que debería haber quedado contra lo que quedó de verdad, y si no cuadra, avisa. Ese día avisó: una diferencia de 0,015 ISY en una compra.

No faltaba plata. Quien pagó era, además, el socio comercial que cobra comisión sobre ese creador, así que la misma operación le descontó la compra y le abonó su comisión. La cuenta del control solo restaba la compra, y por eso no cuadraba.

Se podría haber ignorado: eran 0,015 ISY y el dinero estaba bien. Se corrigió por otra razón — esa persona habría disparado la alarma en cada compra a ese creador, y una alarma que suena sin motivo deja de mirarse. El día que el descuadre sea real, nadie lo vería.

El cálculo ahora incluye lo que la misma operación le abonó a quien paga, con siete pruebas automáticas nuevas, una de ellas con las cifras exactas de esta alerta.

El video en vivo tenía la puerta abierta: ahora cada entrada pasa por el servidor

Lo encontramos buscando otra cosa. Revisando cuánto cuesta el video en vivo, apareció que el motor de video ISYOÜ aceptaba a cualquiera que conociera el nombre de un canal, y el nombre del canal de un live era el identificador del creador, visible en su perfil. La revisión de «¿pagaste tu cupo?» existía, pero solo en la pantalla de la app; el video no la conocía.

En la práctica eso abría tres puertas: ver El Palco sin cupo, transmitir dentro del live de otro creador frente a su público, y gastar minutos de video que paga ISYOÜ, todo desde fuera de la app. No encontramos evidencia de que alguien lo hubiera usado. Lo tratamos como incidente igual, porque estuvo abierto en producción.

El cambio de fondo es que nadie entra al video sin un pase firmado por el servidor, y el servidor solo lo entrega después de comprobar el derecho con sus propios datos: el cupo, la entrada cobrada, la llamada activa. Los pases duran poco y cada renovación vuelve a comprobarlo; si alguien pierde el acceso a mitad del show, el siguiente pase ya no sale.

El orden de la publicación importó tanto como el arreglo. Exigir el pase antes de que la app supiera pedirlo habría cortado todos los lives en curso. Primero salió la app que pide el pase, después se activó la exigencia. En el camino apareció además que el video estaba conectado a un proyecto de pruebas y no al de producción; quedó corregido en el mismo cambio.

De paso, un ahorro directo: el espectador que todavía no ha pagado ya no consume video. Todo cubierto con 29 pruebas automáticas nuevas.

El correo enviaba los mensajes sin los archivos adjuntos, y nadie se enteraba

Reporte real de un colaborador: adjuntó varios archivos, envió el correo, vio «Correo enviado» — y los archivos nunca salieron. Ni él, ni los registros del sistema, ni la copia guardada en «Enviados» tenían rastro de que hubiera habido adjuntos. Ese es el peor tipo de fallo: el que le hace creer a alguien que cumplió.

Al revisarlo aparecieron cinco caminos distintos por los que un archivo desaparecía sin dejar rastro, no uno. El principal era una pareja: la app convertía el archivo a texto para mandarlo y, si esa conversión fallaba, devolvía un valor vacío sin avisar; el servidor lo descartaba y enviaba el correo igual.

El cambio de fondo es que el archivo ahora se sube antes de enviar, con su propia ficha, su barra de progreso y su estado. «Enviar» no se habilita mientras alguno no haya terminado, y el servidor verifica cada archivo contra lo que de verdad se guardó — tamaño y tipo reales, nunca los que declare la app. Si alguno no se puede verificar, el correo no sale.

Esa regla es deliberada y vale la pena explicarla: un correo que no sale cuesta treinta segundos de reintento con el problema a la vista; uno que sale sin el contrato cuesta el contrato, la reunión y la credibilidad — y el remitente no se entera. La asimetría solo admite una respuesta.

El segundo síntoma era que no se distinguía qué correo traía archivos. El indicador contaba también las imágenes incrustadas en las firmas, así que se encendía en casi todos los correos y había dejado de informar. Ahora se distingue al recibir: un logo de firma no cuenta, un documento sí, y la lista muestra el nombre del primer archivo y cuántos más.

Tres fallos más aparecieron de paso, ninguno reportado por nadie. Un archivo entrante que fallara atascaba el buzón entero: abortaba el ciclo y reintentaba el mismo correo cada dos minutos, sin recibir ninguno nuevo. En el iPhone los adjuntos no se abrían, sin ningún aviso. Y archivar un correo borraba sus demás etiquetas. Todo cubierto con 52 pruebas automáticas nuevas.

Compartir un enlace de ISYOÜ ya muestra de qué se trata

Hasta hoy, cualquier enlace de ISYOÜ que alguien compartiera —el perfil de un creador, una publicación, un show— mostraba la misma imagen genérica. La causa es que las redes no ejecutan la aplicación: leen el texto crudo de la página, y como la app se dibuja entera después de cargarse, solo veían lo mismo para todo.

Ahora el servidor arma la vista previa antes de responder, con los datos de lo que se está compartiendo. Un perfil muestra el nombre, la verificación y la foto; un show de El Palco muestra la ciudad, la fecha, el precio del cupo y si quedan pocos o está agotado — que es justo lo que hace que un enlace por mensajería venda una entrada.

Dos decisiones que no son obvias. Una publicación de pago nunca muestra su propia imagen: sería regalar justo aquello que el creador está cobrando; esas usan una tarjeta con el título y el nombre del creador. Y todo texto escrito por un usuario se limpia antes de entrar en la página: un título con comillas rompía la vista previa, y uno con código la habría convertido en un agujero de seguridad.

Además, los tres sitios estrenan tarjeta propia. La página principal compartía una imagen casi vacía y la aplicación compartía su logo cuadrado, que en mensajería se ve diminuto. Un detalle corregido en el camino: al limpiar la dirección se estaban borrando los códigos de referido y de promotor, que son comisiones reales.

El Palco cambió cómo cobra: el reparto por porcentaje no cubría el costo de transmitir

Hasta hoy, cada cupo vendido se repartía 95% para el creador y 5% para ISYOÜ. Suena razonable, pero no cubría el gasto: el costo de un show tiene una parte fija por espectador —llevarle el video a cada pantalla cuesta lo mismo sea el cupo de 10 o de 500— y un porcentaje puro nunca alcanza a pagarla. Con cupos baratos, cada venta costaba más de lo que dejaba.

El cobro nuevo copia la forma del costo, no la del ingreso: 3,5% del precio más 0,75 ISY por cupo y por hora de transmisión. Así cada cupo paga su propio costo a cualquier precio. El comprador no paga nada adicional: esto es entre el creador y la plataforma.

Tres decisiones que hacen que esto no le cambie el trato a nadie por sorpresa. Cada evento guarda las tarifas con las que nació y se liquida con esas para siempre, aunque el cobro cambie mañana; ni el creador ni administración pueden modificarlas después. El cobro se descuenta en el momento de la compra, nunca al cerrar el show: nadie va a recibir una factura por un evento que ya hizo. Y los términos de servicio se actualizaron con el cobro, la no retroactividad y la aclaración de que el comprador paga el precio publicado.

Como ahora cada cupo cubre su costo, el precio mínimo bajó de 50 a 10 ISY — antes ese piso existía solo para que la cuenta no diera pérdida — y se habilitaron shows gratuitos con aforo acotado. El creador ve, antes de publicar, cuánto va a recibir si vende todos los cupos, y cada evento de su lista muestra su neto por cupo y con qué reglas se liquida.

Entrar con un código por correo, con una regla que manda sobre todo: un correo, un solo usuario

Hasta hoy solo se entraba con una cuenta de Google. Eso dejaba fuera a quien no tiene una, y dejaba a toda la plataforma dependiendo de un solo camino de entrada. Ahora se puede entrar con un código de seis dígitos enviado al correo, desde la misma pantalla.

El riesgo real de una funcionalidad así no es que no funcione: es que la misma persona termine con dos cuentas distintas, una por cada forma de entrar, con su saldo partido en dos. Por eso la identidad se resuelve siempre contra nuestro sistema de autenticación y nunca contra la base de perfiles, donde el correo no es único y hay duplicados heredados. Quien entró alguna vez con Google y hoy entra con código cae exactamente en la misma cuenta; quien se registró con código y luego usa Google conserva su identificador, porque la app vincula ambos accesos. Ante cualquier ambigüedad el acceso se rechaza: preferimos que alguien no entre a que entre a una cuenta que no es la suya.

Un fallo propio quedó atrapado antes de llegar a producción: el rechazo de un código incorrecto se lanzaba dentro de la operación que contaba el intento, lo que la deshacía — con eso, el límite de cinco intentos no habría existido y se podrían haber probado los seis dígitos sin límite. La lógica vive en un módulo probado con 40 pruebas automáticas, y las colecciones donde vive el código están cerradas a cualquier cliente, con pruebas que lo verifican.

Safari no dejaba entrar con Google, y la causa llevaba tiempo escondida a plena vista

Reporte real: en Safari se elegía la cuenta de Google, la página volvía a ISYOÜ y se quedaba en la pantalla de ingreso, sin ningún error. En Chrome funcionaba, lo que hacía el fallo difícil de creer y fácil de atribuir al navegador.

La causa estaba en la dirección a la que Google devolvía a la persona: la app vive en app.isyou.io pero la vuelta se enviaba a isyou.io. Son sitios distintos, y Safari corta por diseño el traspaso de datos entre sitios distintos — justo el traspaso del que depende ese regreso. Chrome todavía lo permite, y por eso ahí pasaba inadvertido.

El valor equivocado no venía del código publicado, sino de un archivo de configuración local que se incorporaba al compilar. Ahora, en producción, el dominio de autenticación es siempre el mismo que la persona está visitando, y esa configuración local ya no puede sobrescribirlo. Con los dominios alineados, Safari vuelve a usar la ventana emergente en vez del regreso frágil.

Hubo un intento anterior que no funcionó, y vale la pena registrarlo: se cambió la lógica que decide qué camino usar, sin comprobar antes qué dominio estaba usando la app de verdad. La condición era correcta; el dato que leía, no. Medir antes de corregir habría ahorrado ese despliegue.

Iniciar sesión podía reescribirte el nombre, el apodo y la foto

Un usuario reportó que, tras volver a entrar, su perfil aparecía con el nombre de su cuenta de Google y un apodo generado a partir de él. La causa: al iniciar sesión, la app enviaba el nombre, el apodo y la foto junto con el resto del perfil, tomados de la cuenta de Google. Bastaba con que la lectura del perfil guardado no devolviera nada para que los datos reales quedaran pisados.

Ahora, si el perfil ya existe, esos tres campos no se envían nunca al entrar: solo cambian cuando la persona edita su perfil a propósito. Además, el apodo que se genera para una cuenta nueva se sanea — antes solo se quitaban los espacios, así que un nombre con barras y tildes producía un apodo inservible para una dirección de perfil.

Las cuentas de un show en vivo, explicadas para que las entienda cualquiera

La página pública de costos explicaba el modelo anterior y terminaba en una conclusión que el cobro nuevo volvió falsa. Se reescribió entera, sin palabras técnicas: quién pone la plata y quién se la lleva, con un simulador donde se cambia el precio del cupo, cuánta gente entra y cuánto dura el show, y los números se recalculan solos.

Incluye una comparación honesta contra el modelo de suscripción que usan las plataformas grandes de streaming, con sus condiciones publicadas: allá hay que alcanzar metas de seguidores, de espectadores y de horas antes de cobrar; en ISYOÜ se cobra desde el primer show. La comparación también dice dónde no ganamos —el porcentaje es parecido— y reconoce para qué sirve mejor el otro modelo. Una tabla que esconda eso se desmonta sola en cuanto un creador haga la cuenta.

Los colores de la página se validaron con la misma comprobación automática que el panel de administración, incluida la separación para personas con daltonismo, en modo claro y oscuro.

El panel de administración pasó de pantalla decorativa a tablero de decisiones: filtros, mapas y mapas de calor

El tablero anterior mezclaba datos reales con secciones que no ayudaban a decidir nada: niveles «bloqueados», una consulta «Elite» y una terminal de eventos. Se reemplazó por uno construido alrededor de las preguntas que de verdad se hace el equipo: cuánto dinero entra y sale, cuántas personas llegan y se verifican, qué contenido rinde y qué está fallando.

Una sola fila de filtros —período, ambiente real o de pruebas, y país— recalcula todo lo que hay debajo con el mismo corte, para que los números de cada bloque coincidan entre sí. Cada indicador se compara con el período anterior del mismo largo.

La parte superior del tablero nuevo. Interfaz real renderizada con los estilos de producción, con datos de ejemplo — no son cifras reales de la plataforma.

Los números salen solo de fuentes que registra el servidor: órdenes de compra y retiro, registros de actividad, publicaciones y cupos vendidos. El historial de movimientos que ve cada persona en la app no se usa, porque ese historial lo puede escribir la propia persona. Los colores se validaron con una comprobación automática —incluida la separación para personas con daltonismo— contra el fondo real del panel, y cada gráfico se puede ver también como tabla.

Para el mapa de usuarios, la app registra desde ahora el país de cada persona al entrar, detectado por su conexión: solo el país, nunca la ciudad ni la ubicación exacta, y en un espacio privado que solo administración puede consultar en conjunto. El mapa se irá llenando a medida que la gente vuelva a entrar; mientras tanto se usa el país declarado en la verificación de identidad.

Al revisar el tablero contra la estructura real de los datos apareció un faltante que habría pasado desapercibido: las cuentas nunca guardaron su fecha de registro. El gráfico de registros, el calendario y el embudo habrían salido en cero. Las cuentas nuevas la guardan desde hoy, y no se puede modificar después. Para las anteriores, la primera idea fue usar la fecha en que aceptaron los términos, pero al compararla resultó engañosa: solo la tenía un tercio de las cuentas, y en promedio llegaba 85 días después del registro real, porque la aceptación se añadió cuando muchas personas ya estaban dentro. Así que el mismo día se reconstruyó la fecha exacta de 812 cuentas a partir de nuestro sistema de autenticación, que sí la conserva; solo quedaron fuera 38 perfiles cuya cuenta de acceso ya no existe.

Las recompensas pagaban lo que la app pidiera: ahora el servidor decide qué se ganó y cuánto

Misiones, tareas de anuncios, bono de referidos y recompensas de holders funcionaban igual por dentro: la app calculaba el monto y le pedía al servidor que lo acreditara. El servidor solo revisaba que el monto no fuera desproporcionado y que la persona se lo acreditara a sí misma; no comprobaba que la recompensa se hubiera ganado. Con conocimientos técnicos, alguien podía pedir recompensas una y otra vez y generar saldo que ninguna compra respaldaba, y ese saldo se puede retirar al banco.

La prueba de que alguien cumplió una misión ya no sale del historial que muestra la app, porque ese historial lo podía escribir la propia persona. Solo cuenta lo que registra el servidor: movimientos reales de saldo, compras, retiros y publicaciones. En las tareas de anuncios, la foto de evidencia la revisa ahora nuestro modelo de IA en el servidor, antes de pagar; antes la revisaba la app, así que una app modificada podía saltarse la revisión.

Cinco misiones se retiraron porque no había forma honesta de verificarlas: una pagaba sin comprobar absolutamente nada y las otras dependían de contadores que el sistema nunca registró. Vuelven cuando exista el dato real.

Cada cobro deja ahora un registro que impide cobrar dos veces lo mismo, y la corrección quedó cubierta con 35 pruebas automáticas de las reglas de pago y 14 de permisos sobre nuestras bases de datos. Queda pendiente revisar el historial para confirmar si alguien aprovechó el hueco antes del cierre.

Usuarios reales no lograban verificar su identidad, y la aprobación la escribía la propia app

Varios usuarios nuevos intentaron verificarse el mismo día sin conseguirlo. No era una caída: nuestro modelo de IA respondía con normalidad. El problema era un proceso demasiado estricto: nombres que debían coincidir letra por letra, fotos rechazadas por un reflejo, 21 años como edad mínima, la selfie obligada a abrir la cámara frontal —en varios teléfonos Android no dejaba usar una foto ya tomada— y un bloqueo al tercer intento.

Al revisarlo apareció algo más serio. La decisión se tomaba en el navegador y era la app la que escribía «verificado». Alguien con conocimientos técnicos podía marcarse verificado sin pasar por la revisión, y con eso acceder a lo que exige identidad, como los cupos de El Palco o la creación de campañas.

Ahora decide el servidor, a través de nuestros agentes AI, y nadie puede escribir ese estado desde la app. El criterio es más justo sin perder seguridad: tolera tildes, el orden de nombres y apellidos o que falte el segundo apellido; acepta reflejos o algo de desenfoque si los datos se leen; y en la selfie el documento tiene que estar en la mano, pero no necesita leerse. Sigue rechazando capturas de pantalla, fotocopias, documentos editados y personas distintas.

El nuevo paso del documento en celular: guía de cómo fotografiarlo y, para cada cara, tomar la foto o elegirla de la galería. Interfaz real con datos de ejemplo.

La experiencia cambió en lo que más frenaba a la gente. La edad mínima pasa a 18 años. Cada foto se puede tomar con la cámara o elegir de la galería. Apenas se elige, se revisa si está pequeña, oscura o movida, y se avisa en el momento en vez de un minuto después con un rechazo; el aviso no bloquea, para que un falso positivo no frene a nadie. Los reintentos no tienen límite y llevan directo al paso que falló, sin repetir lo que ya estaba bien.

Y una lección de fondo: antes el motivo del rechazo solo lo veía la persona en su pantalla, así que no había forma de saber por qué alguien no pasaba. Ahora cada intento queda registrado con su motivo, y la próxima vez que alguien reporte que no puede verificarse, la respuesta estará a la vista.

Los retiros a Colombia fallaban por un dato que el formulario mostraba pero no exigía

Dos retiros seguidos fallaron con un mensaje de nuestros rieles de pago según el cual no había una ruta disponible para enviar el dinero. El mensaje apuntaba a un problema del lado del proveedor, y así se investigó. Al día siguiente el proveedor confirmó la causa real: la solicitud llegaba sin el tipo de documento del titular, un dato obligatorio.

El formulario sí mostraba el selector de tipo de documento, pero nada obligaba a elegirlo, y el sistema solo incluía ese dato cuando venía con valor. En los dos intentos el saldo se devolvió automáticamente: nadie perdió dinero, pero el retiro no salía.

Ahora el formulario exige tipo y número de documento, y el servidor revisa los datos antes de descontar el saldo, no después: descubrir el faltante tras el descuento obliga a devolverlo, y cada devolución es una oportunidad más de equivocarse con dinero real. También se envía el nombre del banco, que el proveedor pedía y no se estaba mandando. La lección: un mensaje de error que apunta al lugar equivocado cuesta más que el defecto mismo.

El perfil de cada creador muestra ahora cuánto cuesta en promedio su contenido y su El Palco

El perfil mostraba un «Valor Est.»: la suma de los precios de todo el catálogo. Era un número que crecía con cada publicación y no le decía nada útil a quien visitaba el perfil. Se reemplazó por dos tarjetas: el precio promedio de las publicaciones de pago y el precio promedio de un cupo de El Palco, cada una con su mínimo, su máximo y el equivalente en la moneda local de quien mira.

Las dos tarjetas con datos, sin datos y cargando. Interfaz real renderizada con los estilos de producción, con valores de ejemplo.

Las publicaciones gratuitas no entran en el promedio, porque bajarían el número a un precio que nadie paga, y los eventos de El Palco en borrador tampoco, porque ese precio el creador todavía no lo publicó. Las tarjetas se animan al aparecer y al pasar el cursor, y respetan la preferencia de «reducir movimiento» del sistema.

El período de espera antes de retirar ganancias se podía saltar; ahora lo controla solo el servidor

Lo que un creador recibe de otros usuarios espera un período —10 días por defecto— antes de poder retirarse al banco, porque el pago que lo originó todavía podría revertirse. Ese control existía en la pantalla, pero no en el servidor: quien llamara al sistema directamente podía retirar dinero todavía retenido.

Había dos formas más de saltarlo. La lista de ingresos retenidos se podía editar desde la propia cuenta. Y varios tipos de ingreso —propinas en vivo, El Palco, comisiones— nunca quedaban retenidos, así que bastaba con pasar el dinero a otra cuenta y retirarlo desde ahí.

Ahora la retención se registra en la misma operación que acredita el saldo, para todo lo que se recibe de otros usuarios; el retiro la valida en el servidor, y nadie puede modificar la lista desde la app. De paso se corrigió el Adelanto, que permite liberar lo retenido pagando un 1,5%: cobraba ese porcentaje sobre un monto que escribía la persona pero liberaba todo lo retenido. Ahora se cobra sobre lo que realmente se libera.

Compras por PSE: el aviso culpaba al usuario de un rechazo que no había hecho

Una parte importante de las compras por PSE llega a la página del banco pero no se completa: de 17 intentos en toda la historia, 5 terminaron bien. Cuando fallaban, la app decía «Rechazaste el pago en tu app bancaria», cuando la respuesta real de nuestros rieles de pago era «intenta más tarde», y llegaba entre 11 y 21 minutos después: el patrón de una sesión bancaria que vence, no el de alguien que rechaza. El mensaje ahora dice que el pago no se completó y que se puede reintentar o usar otro banco.

Para poder mejorar esa tasa, cada compra guarda ahora el banco elegido —no es un dato personal—, de modo que se pueda ver si los fallos se concentran en uno. Y el estado de las órdenes ya no se queda en «pendiente» cuando fallan o se aprueban, algo que confundía al revisarlas.

El mismo día, los pagos con tarjeta quedaron pausados temporalmente por decisión del equipo. La opción se ocultó en toda la app, y así apareció un detalle: la compra rápida del inicio la seguía mostrando disponible aunque no funcionaba. Con la tarjeta apagada, la app ya no consulta al proveedor en cada apertura de la billetera.

El panel mostraba 148 errores acumulados; al clasificarlos, dos causas explicaban el 83%

El registro automático de errores llevaba 148 casos sin revisar. En lugar de atenderlos uno por uno, se agruparon por causa raíz —el mismo defecto genera decenas de registros distintos— y el panorama cambió por completo.

Las tres cuartas partes salían de una sola línea. Cada dispositivo que estuviera en la sección Explorar intentaba borrar las transmisiones que habían quedado sin dueño, cada cinco segundos. Pero solo el propietario de una transmisión puede borrarla, así que todos los demás recibían un rechazo por cada transmisión huérfana y por cada persona mirando — multiplicándose con la audiencia. Y encima casi nunca limpiaba nada: solo funcionaba si el dueño estaba justo en esa pantalla en ese momento.

Se movió al servidor, que ya recorría esas mismas transmisiones cada quince minutos. Con una decisión deliberada: el plazo para borrar una transmisión es de treinta minutos, mucho más largo que los dos minutos para dejar de mostrarla. Ocultarla es reversible, borrarla no, y un corte de conexión pasajero no puede costarle a un creador su transmisión.

El 8% de cámara y micrófono resultó ser un problema de producto más que técnico: cuando alguien negaba el permiso, la aplicación no le decía nada. Quedaba mirando una pantalla que no funcionaba, sin saber que la decisión había sido suya y que podía revertirla. Ahora se le indica cómo activarlo, o que revise si otra aplicación tiene la cámara ocupada.

El 10% restante —«versión antigua en el navegador»— no es un defecto: aparece cuando alguien tiene la aplicación abierta y se publica una versión nueva, y la recuperación automática que ya existía lo resuelve sin que el usuario haga nada. Este día concreto hubo muchas publicaciones seguidas por las urgencias del chat en vivo, lo que explica el número. La medida que queda es de proceso, no de código: agrupar los despliegues en lugar de publicar tras cada ajuste pequeño.

El chat de las transmisiones en vivo tenía tres fallas encadenadas, y las tres eran mudas

Reportado en el peor momento posible: reunidos con los organizadores de un evento de 10.000 personas, el chat de la transmisión no enviaba mensajes y las reacciones tampoco. Resultaron ser tres problemas distintos, uno detrás del otro. Cada corrección destapó la siguiente: se arregló el envío y volvieron las reacciones, pero no los mensajes; se arregló eso y los mensajes ya salían, pero no aparecían en pantalla.

Primera falla — mensajes sin firmar. Desde el 5 de mayo, en una revisión de seguridad, se exige que cada mensaje del chat venga firmado con la identidad de quien lo envía, para que nadie pueda escribir a nombre de otro. La regla era correcta y sigue siéndolo; lo que faltó fue actualizar la aplicación para cumplirla. Durante cuatro meses, cada mensaje y cada reacción se rechazaban al llegar al servidor.

Segunda falla — cada camino resolvía distinto a qué transmisión escribir. Los stickers usaban tres alternativas para averiguarlo; el envío de texto, solo dos. Para un espectador, justamente la tercera es la que tiene el dato. De ahí el síntoma desconcertante de que las reacciones salieran y los mensajes no: el mismo chat, dos maneras distintas de resolver lo mismo.

Tercera falla — los mensajes salían, pero no se veían. El chat no se lee mensaje por mensaje: el servidor los agrupa y publica un aviso combinado cada pocos segundos. Es una decisión de costo deliberada y correcta — con 10.000 espectadores, que cada uno leyera cada mensaje por separado serían millones de lecturas. El problema era que, si llegaba un mensaje antes de cumplirse ese plazo, el aviso se descartaba sin volver a programarse. En un chat movido se notaba como retraso; en uno tranquilo, el último mensaje podía quedarse sin aparecer hasta que otra cosa disparara el siguiente aviso.

Se corrigió por los dos lados. El servidor ya no descarta el aviso: espera lo que falte y lo publica, de modo que ningún mensaje se queda sin salir. Y quien escribe ve su propio mensaje al instante, sin esperar el aviso combinado. Esa segunda parte no cambia el costo en absoluto y es la que hace que el chat se sienta inmediato. El intervalo para el resto de espectadores se dejó igual: acortarlo multiplica el gasto justo en el evento donde más gente hay, y ese número estaba elegido a conciencia.

El chat en vivo funcionando: mensajes, stickers con su valor en ISY y la bandeja de reacciones y regalos. Interfaz real renderizada con los estilos de producción, con datos de ejemplo — no es una conversación de nadie.

Lo que une a las tres fallas es lo que de verdad hay que corregir: ninguna hacía ruido. El envío no esperaba confirmación del servidor; la función que mandaba el mensaje envolvía todo en una condición sin salida alternativa; y el aviso que se descartaba no dejaba rastro de haberse descartado. En los tres casos, si algo no cuadraba, la operación terminaba sin avisar. No había alerta, ni marca roja, ni registro visible: simplemente no pasaba nada. Un fallo que grita se arregla el mismo día; estos duraron meses porque quien los vivía no tenía nada que reportar salvo «no hace nada».

Por eso la corrección no se limitó a los dos defectos. La firma se aplica ahora en un único punto por el que pasan todos los envíos, en vez de confiar en que cada lugar la recuerde. La transmisión se resuelve también en un solo punto, usado por los cuatro caminos que escriben al chat. Y si algo falla —no hay sesión, la transmisión aún no está lista, el servidor rechaza— el usuario ve un mensaje concreto y recupera el texto que había escrito, en lugar de perderlo en un botón que parece muerto.

Con la urgencia encima era tentador publicar y comprobar sobre la marcha. Se hizo al revés: primero doce pruebas automáticas contra las reglas reales —mensaje firmado pasa, sin firmar se rechaza, firmado a nombre de otro se rechaza, sticker gratis y de pago pasan— y solo después se publicó. Quedan permanentes: si la regla y la aplicación vuelven a separarse, ahora falla una prueba en vez de fallar un evento con 10.000 personas mirando.

El correo del equipo ahora avisa al teléfono cuando llega algo a tu dirección

La bandeja de correo interna funcionaba, pero había que entrar a mirarla. Para correspondencia comercial eso es un problema real: un socio escribe un martes por la tarde y nadie se entera hasta el jueves. Ahora, cuando llega un correo a la dirección de un colaborador, le aparece la notificación en la aplicación y le suena el teléfono, con el remitente y el asunto a la vista y un toque para abrir la conversación.

Dos decisiones de diseño que valen más que la función en sí:

Un aviso por revisión, no uno por correo. El sistema revisa el buzón cada dos minutos y puede traer hasta 25 mensajes de una vez. Notificarlos uno a uno le sonaría el teléfono 25 veces a la misma persona por lo que para ella es un solo hecho: «me llegó correo». Cuando llega más de uno, el aviso los agrupa y lleva a la bandeja en lugar de elegir un mensaje al azar.

Los correos devueltos también avisan. Si un mensaje que envió un colaborador no llegó a su destino, la notificación lo dice con esas palabras. Es la clase de silencio que sale caro: enterarse tarde de que una propuesta comercial nunca llegó es mucho peor que una notificación de más.

Cada persona recibe únicamente los avisos de su propia dirección, con la misma separación que ya rige la bandeja. El correo que no corresponde a ningún destinatario conocido —que es donde cae todo el correo no deseado del dominio— no le suena el teléfono a nadie. Verificado de punta a punta contra producción con un correo real: llegó, se atribuyó a la dirección correcta y generó su aviso, con el enlace directo a la conversación.

La auditoría de saldos ahora distingue los movimientos actuales de los registros heredados de la etapa anterior de la plataforma

El panel audita los saldos comparando lo que muestra cada cuenta contra el historial de movimientos que lo respalda. Al revisar esa herramienta a fondo encontramos algo que no estaba contemplado en su diseño: el historial de un usuario guarda hoy dos generaciones de registros en el mismo lugar, y solo una de ellas corresponde al saldo que se está auditando.

Los registros de la etapa anterior son historial de la wallet del usuario en la red —comisiones, otras monedas, incluso tokens basura que llegan solos por campañas de estafa— y no tienen relación con el saldo de ISY que la aplicación administra hoy. La auditoría se construyó sobre el ledger nuevo, y esos registros históricos quedaron entrando en la misma cuenta. El resultado eran cifras infladas en el reporte: a una cuenta con 6,94 ISY se le señalaban 1.163 ISY de diferencia que en realidad nunca existieron como saldo.

Corregida la distinción, la auditoría cuadra 17 de 25 cuentas frente a 8 antes. Las 8 restantes son cuentas con saldo originado en esa etapa anterior, sin movimientos del ledger actual que lo respalden; ahora se reportan como categoría propia —"saldo sin movimientos que lo respalden"— en lugar de mezclarse con los descuadres de suma, que son un problema distinto y se atienden distinto.

Se reforzó además la corrección automática. La auditoría incluye una acción que ajusta el saldo de una cuenta a lo que dice su historial, y ese ajuste solo tiene sentido cuando el historial es el registro completo de esa cuenta. Ahora se niega a ejecutarse si no lo es —por ejemplo en las cuentas que vienen de la etapa anterior— o si aparece algún movimiento que el sistema no sepa clasificar. Verificado contra producción antes de publicar: con la nueva condición ninguna cuenta queda expuesta y ocho quedan explícitamente protegidas.

Y se endureció el criterio de fondo: un tipo de movimiento que el sistema no reconozca ya no se interpreta por defecto. Antes cualquier registro inesperado se asumía como salida; ahora la auditoría declara que no sabe clasificarlo y marca el total como no confiable. Una herramienta de control que no puede explicar un dato debe decirlo, no entregar una cifra con aplomo. Ese criterio es lo que hará que el próximo cambio en cómo se guardan los datos se detecte solo, en lugar de pasar inadvertido.

Escribimos las pruebas automáticas que faltaban — y encontraron cuatro fallas que nadie había visto

El correo interno salió a producción con su separación entre bandejas garantizada por razonamiento sobre las reglas de seguridad, no por algo que fallara automáticamente si alguien las rompía. Eso se cerró: hay 112 pruebas, 26 de ellas ejercitando las reglas directamente contra la base de datos, saltándose la aplicación. Comprueban que un colaborador no pueda leer el correo de otro ni conociendo el identificador exacto del mensaje, ni pidiendo la lista con el alias ajeno, ni cambiándose su propia asignación.

En la primera ejecución encontraron cuatro defectos reales que no habían dado la cara:

Ese es exactamente el argumento a favor de escribir pruebas: los cuatro llevaban días en producción sin que nadie los notara, porque ninguno se manifiesta como un error visible — se manifiestan como datos que se pierden en silencio. La lógica que fallaba vivía enterrada dentro de archivos de miles de líneas; se movió a piezas pequeñas y aisladas, que es lo que la hace comprobable.

Con esto el correo queda plenamente operativo: ya hubo un envío real desde la dirección propia de un colaborador, distinta a la del buzón principal, que era la última pieza sin verificar. También se completaron las reglas de reparto automático para el correo que no coincide con ningún destinatario conocido, la carga por páginas de la bandeja, y la guía de despliegue del equipo, que no mencionaba nada de este sistema.

En el teléfono, el botón de enviar quedaba tapado por la barra de navegación

Reportado desde el uso real: al responder un correo en el celular, el botón «Enviar» no se alcanzaba a ver porque la barra de navegación inferior le quedaba encima. El origen no era el orden de las capas, que ya estaba bien configurado, sino que la ventana de redacción colgaba de una sección animada de la pantalla, y eso la encerraba en su propio plano: su prioridad de dibujado dejaba de competir con la de la barra. En iPhone el efecto empeora porque la barra usa un desenfoque de fondo que la aísla todavía más.

Se corrigió la causa y no el síntoma: la ventana de redacción ahora se dibuja fuera de esa sección, siguiendo el mismo mecanismo que la aplicación ya usa para las pantallas de llamada. Se aprovechó para arreglar otras dos incomodidades de la misma familia: el botón respeta el área reservada del indicador de inicio del iPhone, y el alto de la ventana se calcula contra la parte de pantalla realmente visible, no contra una altura mayor que incluye la barra del navegador cuando está desplegada. Verificado reproduciendo la pantalla a tamaño de teléfono con los estilos de producción, antes y después.

Los primeros correos del equipo llegaban a Spam — y la hipótesis correcta la dio una observación del negocio, no el diagnóstico técnico

Al día siguiente de poner en marcha el correo interno, los primeros envíos reales caían en la carpeta de Spam del destinatario. Para correspondencia comercial esto no es un detalle estético: un correo a un socio o a un cliente que nadie ve equivale a no haberlo enviado, y no genera ningún aviso de que se perdió.

La primera revisión descartó lo obvio: la autenticación del dominio estaba impecable. Se leyeron las cabeceras reales de un correo entregado y los tres mecanismos que usa la industria para probar que un remitente es legítimo pasaban sin objeción. También se verificó que la dirección de salida tuviera DNS inverso válido y que no estuviera en listas negras. Nada de eso explicaba el rechazo.

dkim  = pass   (firma válida del dominio)
spf   = pass   (servidor autorizado a enviar)
dmarc = pass   (política alineada)
DNS inverso = correcto, coincide ida y vuelta
listas negras = no listado

Con eso, el diagnóstico técnico apuntó a la reputación del dominio: una dirección nueva, sin historial, tiende a caer en Spam aunque todo esté bien configurado. Esa conclusión era equivocada, y llevaba a un callejón sin salida — "espere a que el dominio gane reputación" no es un plan. La corrigió una observación de negocio: las alertas automáticas del sistema salen del mismo buzón, por el mismo servidor y hacia el mismo destinatario, y siempre llegan bien. Si la causa fuera la reputación, esas también caerían.

Eso aisló la variable de inmediato. La diferencia no estaba en el remitente sino en la forma del mensaje: las alertas se envían como un documento HTML completo y bien formado, mientras que las respuestas del correo salían como un fragmento suelto de texto. Un mensaje con HTML incompleto es una señal de spam reconocida desde hace años. Se corrigió para que todo correo salga como documento completo.

Vale la pena registrar el paso en falso, porque es la parte útil: la segunda versión —agregar una versión en texto plano del mensaje— se hizo por buena práctica y no resolvió nada. La prueba de que no era la causa estaba a la vista todo el tiempo: las alertas del sistema ni siquiera incluyen esa parte y llegan perfecto. Se conservó igual, porque sigue siendo lo correcto, pero no era el problema. La causa quedó documentada dentro del propio código para que la próxima persona que lo toque no repita el rodeo.

La bandeja dentro de ISYOÜ. Cada colaborador ve únicamente los correos dirigidos a su propia dirección; la carpeta "Sin asignar", en ámbar, solo aparece para el administrador. Interfaz real renderizada con los estilos de producción, con datos de ejemplo — no es la correspondencia de nadie.

El redactor. El campo "De" se muestra fijo y no editable a propósito: el remitente lo resuelve el servidor a partir de la sesión, nunca lo manda el navegador, de modo que nadie puede escribir correo a nombre de otra dirección. Datos de ejemplo.

Construimos nuestro propio correo corporativo dentro de ISYOÜ — cada colaborador con su dirección, sin comprar una casilla más

El correo del equipo tenía un problema estructural: existe un solo buzón real, y las direcciones de los colaboradores son alias que caen todas en esa misma bandeja. Darle su dirección a alguien significaba, en la práctica, darle la contraseña del buzón de todos — sin separación, sin poder revocar el acceso de una persona sin cambiársela a los demás, y sin manera de saber quién respondió qué. La salida habitual es pagar una casilla por persona, o contratar un software de bandeja compartida que cobra por asiento todos los meses.

Hicimos otra cosa: construimos la bandeja dentro de la propia plataforma, sobre el plan de correo que ya estaba pagado por un año. Cada colaborador entra con la sesión que ya tiene en ISYOÜ —sin una contraseña nueva, sin un login más que administrar— y ve únicamente los correos dirigidos a su dirección. Responde, y el correo sale a nombre de esa dirección, no de la cuenta madre. El administrador asigna y revoca direcciones desde el panel, en segundos. Costo adicional recurrente: cero.

Antes de escribir una línea de código de producción, probamos los supuestos contra el servidor real — y uno se cayó. Dábamos por hecho que el correo entrante conservaría la marca de a cuál alias había llegado; resultó que el proveedor borra esa información antes de entregar el mensaje, y todos los rastros técnicos apuntan al buzón madre. Verificarlo a tiempo, con correos reales enviados desde afuera, cambió el diseño: la asignación se hace por los destinatarios visibles del mensaje. Lo que no se puede atribuir con certeza no se adivina — cae en una bandeja "Sin asignar" que solo ve el administrador, y él la enruta a su dueño con un clic.

La separación entre bandejas no depende de la pantalla: está impuesta en la base de datos. Aunque alguien manipulara la aplicación en su navegador, no puede listar ni abrir el correo de otro colaborador. Y como estos mensajes vienen de desconocidos, cada correo se muestra dentro de un contenedor aislado que no puede ejecutar nada, con las imágenes remotas bloqueadas por defecto: esas imágenes son, muchas veces, el píxel que le avisa al remitente que abriste su correo.

Dos límites que preferimos dejar escritos: el buscador cubre asunto y remitente, no el cuerpo del mensaje —la interfaz lo dice explícitamente en vez de devolver resultados incompletos en silencio—, y la recepción no es instantánea: el sistema revisa el buzón cada dos minutos. Ya está en producción, verificado de punta a punta con un correo real: llegó, se atribuyó a la dirección correcta y quedó en la bandeja de su dueño, sin errores. La primera dirección asignada fue la del área de alianzas comerciales.

Un reporte de "no puedo desbloquear este contenido" destapó que todas las compras con comisión estaban fallando

Un usuario reportó que al intentar comprar el contenido de una creadora, el botón le devolvía error. Los registros del servidor dieron la causa exacta en segundos: la función que reparte la comisión de un manager vinculado consultaba la base de datos después de haber empezado a mover el saldo, dentro de la misma operación atómica. La base de datos exige que todas las lecturas ocurran antes de cualquier escritura, así que la operación completa se cancelaba y el usuario veía un error.

El alcance real resultó mucho mayor que el reporte: rompía toda transacción donde la plataforma retiene un margen — desbloqueo de contenido, suscripciones, entrada a streams con precio y compra de cupos de El Palco. Los regalos y las propinas seguían funcionando solo por casualidad: como no dejan margen, el código retornaba antes de llegar a la consulta problemática, lo que hacía parecer el fallo como un caso aislado de una sola creadora. Se separó la lógica en dos fases explícitas —primero leer y calcular, después acreditar— y se corrigieron los dos puntos afectados. De paso se desplegaron unos índices de base de datos que estaban definidos en el repositorio pero nunca se habían activado en producción.

Los retiros bancarios no aparecían en "Actividad" — el dinero salía bien, pero el usuario no lo veía en su historial

Reporte real: "en actividad reciente no está registrando los retiros". La causa: el retiro sí debitaba el ISY correctamente, pero solo quedaba guardado en un registro de auditoría interna, nunca en la colección que de verdad lee la pantalla de "Actividad" tanto en Inicio como en el Wallet. El dinero se movía bien; el usuario simplemente nunca veía la prueba de que había pasado.

Se corrigió para que el retiro quede registrado al momento del débito real, y también se agregó el registro correspondiente si un retiro llega a fallar y el ISY se devuelve — para que el historial siempre refleje exactamente lo que pasó con el dinero, en ambos sentidos.

Nuevo historial completo de movimientos en el Wallet

La pantalla de "Actividad" mostraba como máximo tus últimos movimientos en vivo. Se agregó un botón "Ver todo" que abre el historial completo, paginado ("cargar más" en vez de un tope fijo), para poder revisar cualquier transacción pasada — retiro, compra, propina, desbloqueo de contenido, cupo de El Palco — sin importar cuánto tiempo haya pasado.

El proveedor que procesa pagos con tarjeta llevaba más de un día con la cuenta en mora — y nadie se había enterado

Revisando un reporte puntual encontramos que el proveedor externo que procesa los pagos con tarjeta tenía la cuenta de ISYOÜ suspendida por una factura pendiente desde el 3 de septiembre — más de un día y medio. El sistema ya tiene, desde un incidente similar en junio, un chequeo que detecta esto automáticamente y desactiva el pago con tarjeta apenas ocurre, así que ningún usuario perdió dinero ni quedó con un cobro a medias. El problema real era otro: esa detección solo quedaba anotada en los registros internos, sin avisarle a nadie — se descubrió por casualidad, revisando logs a mano.

Se agregó una alerta automática por correo al equipo apenas el sistema detecta esta situación, para enterarnos en minutos en vez de por accidente días después. PSE, transferencia bancaria, PIX y Nequi no dependen de este proveedor y siguieron funcionando con normalidad durante toda la mora.

Spinner visible mientras carga la lista de bancos al retirar

El selector de banco del formulario de retiro solo cambiaba el texto a "Cargando bancos..." mientras esperaba la lista real de tu país — ahora también se ve un spinner girando, más claro que algo está pasando y no que el selector quedó vacío o roto.

Compras por transferencia/PSE/PIX/Nequi mostraban ~10% más ISY del que realmente se acredita — y disparaban alertas falsas de fraude

Reporte real: un retiro de 15 ISY mostraba un estimado de 51.000 COP, pero llegaron 46.000 COP. Al revisar ese formulario a fondo también revisamos el camino contrario (comprar ISY pagando en moneda local), donde encontramos algo con más impacto: el estimado de cuánto ISY se recibe al pagar con transferencia bancaria, PSE, PIX o Nequi no aplicaba el mismo margen que sí calcula el servidor al acreditar de verdad — mostraba consistentemente ~10% más ISY del real. Como esa diferencia superaba el margen de tolerancia del chequeo de seguridad que blindamos el 3 de septiembre, cada compra por esos métodos disparaba, de forma silenciosa, una alerta real de "intento de manipulación de monto" al correo del equipo — sin que hubiera ningún intento real de nadie.

Se corrigió en ambos sentidos: el estimado del retiro y el de la compra ahora usan exactamente la misma fórmula que ya usa el servidor para acreditar de verdad, así que lo que se muestra antes de confirmar siempre coincide con lo que realmente llega o se recibe.

El retiro ya recuerda tus datos bancarios — solo hay que digitarlos la primera vez

Moneda, banco, tipo de cuenta y documento quedan guardados después del primer retiro, y se precargan solos la próxima vez que abres el formulario — incluida la selección de banco, una vez carga la lista de esa moneda. Solo queda por digitar el monto.

Encontramos una plataforma descontinuada escribiendo cuentas duplicadas en la base de usuarios real — y una cuenta real había sido baneada por error

Investigando un reporte puntual de una cuenta duplicada encontramos algo más grande: MYGOV, una plataforma hermana sin uso desde mayo, seguía compartiendo la misma base de usuarios que la app principal, y su login (por wallet o por Google) creaba una cuenta nueva cada vez que alguien con el mismo correo entraba ahí, sin que la app principal se enterara. Antes de tocar nada, medimos el daño real: 40 personas con al menos una cuenta duplicada, y una herramienta administrativa de esa plataforma (pensada para "fusionar" esas cuentas) había marcado por error como baneada la cuenta real de un usuario legítimo, además de dejar 43.594 ISY reales huérfanos, repartidos entre 12 cuentas, invisibles para sus dueños.

Se corrigió por completo: la cuenta afectada quedó restaurada, los 43.594 ISY se acreditaron de vuelta a quienes les pertenecían (cada uno con su propio registro de auditoría), y los registros duplicados que quedaron sin dueño real se archivaron sin borrar nada — reversible por diseño. Ninguna de las 40 personas afectadas terminó con más de una cuenta activa.

Cerramos por completo el acceso a la plataforma descontinuada que causó el problema anterior

Para que ese origen no pueda repetirse nunca, se eliminó de raíz: el login y el registro de esa plataforma quedaron desactivados (si alguien entra, se cierra la sesión automáticamente sin tocar ningún dato), la herramienta de "fusionar duplicados" que causó el baneo indebido se eliminó del panel administrativo, y el dominio ahora muestra una única pantalla estática, sin ningún inicio de sesión ni interacción posible, con una invitación a visitar la plataforma real.

Las cuentas archivadas dejaron de aparecer en el buscador de creadores y en cualquier búsqueda por @handle

Como parte de la limpieza anterior encontramos que el buscador de creadores, la búsqueda por @handle y la detección de cuentas duplicadas al iniciar sesión no filtraban las cuentas archivadas — así que un mismo nombre real podía seguir apareciendo varias veces en los resultados, con cuentas que ya no existían de verdad. Se corrigió en las funciones de búsqueda del backend, y luego se encontró una segunda ruta independiente (la caché propia del feed de exploración, que hacía su propio filtrado sin pasar por esas funciones) — también corregida.

Rediseñamos las tarjetas de búsqueda de creadores: ahora se ve la portada y si tiene un Palco activo

Las tarjetas de resultados de búsqueda solo mostraban la foto de perfil, en una grilla apretada de hasta 4 columnas. Se rediseñaron a un máximo de 3 columnas, con la foto de portada del creador de fondo en la tarjeta y una insignia "El Palco" visible cuando ese creador tiene un evento a la venta o en vivo — más fácil de reconocer, y con más motivo real para dar clic.

El nombre y el @handle guardados por el usuario ya no se sobreescriben solos al iniciar sesión con Google

Reporte real: el nombre y el @handle de un usuario cambiaban solos, en cualquier momento, después de haberlos editado varias veces a mano. La causa: si la lectura del perfil guardado fallaba por cualquier razón pasajera, el sistema no distinguía eso de "es una cuenta nueva" — y en ambos casos usaba el nombre y la foto de la cuenta de Google como si fueran los datos reales, los mostraba, los guardaba localmente, y los volvía a escribir en la base de datos, borrando lo que el usuario había guardado.

Se corrigió separando ambos casos: ahora una lectura fallida nunca se confunde con una cuenta nueva. Si falla, se usan los últimos datos reales conocidos en ese dispositivo, y no se sobreescribe ni se guarda nada hasta que la lectura real se confirme.

El Palco ahora tiene un precio mínimo de 50 ISY, exigido por el servidor

Por debajo de ese precio el margen no alcanza a cubrir el costo real de una transmisión en vivo a escala. El mínimo se exige del lado del servidor —no solo como validación del formulario, que cualquiera podría evitar— tanto al crear como al editar un evento, para el creador y para el panel administrativo por igual. De paso se corrigieron 5 eventos ya activos que habían quedado con precios de prueba muy por debajo del mínimo; ninguno tenía cupos vendidos todavía, así que el ajuste no afectó a ningún comprador real.

El Palco ahora respeta la ciudad del evento: el creador solo transmite desde ahí, y solo esa audiencia puede verlo

Un evento de El Palco queda ligado a una ciudad desde que se crea. Ahora el creador solo puede iniciar la transmisión si detectamos que está conectándose realmente desde esa ciudad, y la audiencia solo puede ver el live si también se conecta desde ahí — aplica incluso con el cupo ya comprado. La detección es por IP (la misma que ya se usaba para autocompletar la ciudad del comprador), así que es una señal razonable pero no infalible — no reemplaza una verificación estricta de ubicación. Los eventos sin ciudad asignada no quedan afectados por esta regla.

Blindamos 4 puntos del sistema de pagos donde el servidor confiaba en un monto que debía calcular él mismo

Auditamos a fondo cómo se calcula cada monto sensible del sistema de pagos real — compra con tarjeta nueva, compra con tarjeta guardada, compra con métodos alternativos (PSE, SPEI, PIX y similares) y retiro bancario — y encontramos el mismo patrón repetido en los 4 puntos: dos cifras relacionadas (cuánto se cobra o se debita, y cuánto se acredita a cambio) llegaban desde el cliente por separado, sin que el servidor las cruzara contra una tasa de cambio real antes de mover el dinero. En la práctica, eso dejaba una fisura real: el servidor confiaba en una relación entre dos números que nunca verificaba por su cuenta.

Se corrigió de raíz en los 4 puntos: ahora el servidor calcula esa relación él mismo, con su propia tasa de cambio (para pesos colombianos, contra la TRM oficial del Banco de la República — ver la entrada siguiente). Cualquier discrepancia entre lo que pide el cliente y lo que calcula el servidor queda registrada y dispara una alerta al equipo, pero el valor del cliente nunca se usa para mover dinero. Se probó con un caso simulado de manipulación antes de desplegar: el sistema ignoró correctamente el monto solicitado y acreditó solo lo que correspondía a lo realmente cobrado.

La plataforma estaba pagando 10% de más en cada retiro bancario — sin que nadie lo pidiera

Al revisar la fórmula de retiro (en el marco del blindaje de arriba) encontramos que reutilizaba, sin invertir, el mismo recargo del 10% que se cobra al comprar ISY — aplicado al lado equivocado de la operación. El efecto real: por cada 100 ISY retirados, la plataforma pagaba el equivalente a 110 dólares reales en vez de 100, en cada retiro bancario legítimo, desde que existe esa función.

Se corrigió a valor justo: el retiro estándar ya no lleva ningún recargo. Cobrar ahí habría sido doble cobro sobre dinero que ya dejó su margen de plataforma en la venta original. El único camino de pago-por-rapidez sigue existiendo sin cambios: el Adelanto (1.5% de fee, reduce el tiempo de espera a 2 días).

El saldo ya se muestra en la moneda local de cada usuario, no solo en USD

Como 1 ISY vale siempre 1 USD, varias pantallas mostraban el saldo repitiendo el mismo número dos veces con "USD" al lado — información redundante para alguien fuera de Estados Unidos. Ahora se detecta el país del visitante por IP (sin GPS, sin pedir ningún permiso, nada se guarda) y el saldo se muestra convertido a su moneda local en las 4 pantallas donde aparece: el saldo principal de Wallet, el panel lateral, la barra de navegación de escritorio y el perfil.

Para pesos colombianos, la conversión usa la TRM oficial del Banco de la República en vez de una aproximación de mercado — la misma cifra que cualquier banco colombiano usa como referencia real, no una estimación. Para el resto de monedas soportadas (peso mexicano, sol peruano, peso chileno, peso argentino, real brasileño) se usa una fuente de tasas con dos niveles de respaldo; de paso se encontró que uno de los respaldos que ya existía llevaba tiempo caído sin que nadie lo notara, y se reemplazó por uno verificado en vivo. El mismo mecanismo de detección se reutilizó en El Palco: la ciudad del comprador ahora se autocompleta al abrir el mapa de asientos, en vez de pedirla siempre a mano.

Documentamos con precisión qué interacciones dejan margen para la plataforma y cuáles son 100% gratuitas para el creador

Como parte de robustecer el modelo de reparto de ingresos con creadores y colaboradores, auditamos y dejamos documentada —de forma exacta, no aproximada— cada interacción real dentro de la plataforma: cuáles dejan un margen operativo para ISYOÜ y cuáles son completamente gratuitas para el creador. Envíos directos, propinas y stickers no dejan ningún margen hoy — el 100% de esos ISY va directo al creador. Desbloquear contenido pago, suscribirse a un creador, entrar a un stream con acceso restringido, y comprar cupo de El Palco sí dejan un margen operativo, que es la base de cómo la plataforma se sostiene y de cómo se calcula cualquier reparto adicional con colaboradores.

De paso corregimos un detalle de precisión real: los cálculos de reparto que dependen de ese margen (una fracción de una fracción) estaban redondeando a centavos, lo que en montos chicos podía perder hasta un tercio del valor real por puro redondeo, o incluso llevarlo a cero. Se ajustó la precisión del cálculo para que ese margen se calcule y se reparta exacto, sin impacto perceptible en ningún saldo mostrado al usuario.

Rediseño móvil de El Palco en vivo: el chat y los botones ya no compiten por espacio

Reporte real: "desde móviles es imposible interactuar con el live... no se visualiza bien el chat... los botones no se entienden". La causa era estructural — chat, campo de texto y hasta 4 botones de acción compartían una sola fila apretada en el 28% inferior de la pantalla, y todos los botones (regalo, trading, chat, encuadre de cámara) usaban exactamente el mismo círculo translúcido, indistinguibles entre sí salvo por el ícono.

Se rediseñó validando contra un crítico independiente en 3 rondas (referencia: los patrones ya establecidos de TikTok Live e Instagram Live) hasta que el diseño pasó sin objeciones. El chat y el campo de texto ahora viven en su propia columna a la izquierda; las acciones pasaron a un rail vertical a la derecha con jerarquía real — "Regalo" es inequívocamente la acción principal (círculo grande, dorado, sólido), el resto son utilitarios de contorno fino, cada uno con su etiqueta debajo. El escritorio no se tocó — cero riesgo de regresión ahí.

El rail de acciones a la derecha (Regalo, Trading, Chat, Encuadre) y el chat legible a la izquierda — versión final, aprobada por el crítico independiente en la ronda 3

Incidente real en vivo: espectadores sin cupo lograron entrar a un stream de El Palco — encontramos la causa exacta y la corregimos en minutos

Reporte en caliente durante una transmisión real de Nelson en modo El Palco: personas que nunca compraron su cupo estaban viendo el stream. El bloqueo al entrar sí funcionaba bien — un espectador sin cupo se conectaba y quedaba correctamente bloqueado, sin ver el video. El problema apareció después: el listener que sincroniza el contador de espectadores y el chat corre cada ~10 segundos (el mismo mecanismo que optimizamos para bajar costos hace unos días), y ese bloque de código solo sabía reconocer un tipo de bloqueo — contenido pagado desbloqueable — pero no los otros dos que sí existen en la plataforma: entrada de pago y cupo de El Palco. Para esos dos casos, el código caía siempre en un else genérico que desbloqueaba al espectador sin verificar nada. En la práctica: cualquiera sin cupo quedaba bien bloqueado los primeros ~10 segundos, y después el propio sistema lo dejaba entrar solo — sin que hiciera falta ningún truco técnico de su parte.

Corregido y desplegado el mismo día: ese listener periódico ya no toca el estado de bloqueo para streams de entrada de pago o de El Palco — respeta el resultado de la verificación real que ya se hace una sola vez al entrar (contra el cupo comprado en nuestras bases de datos), en vez de resetearlo a ciegas cada 10 segundos. Aplica de inmediato a cualquiera que entre o recargue de ahí en adelante — quien ya estaba conectado desde antes del fix necesita recargar o que el host reinicie la transmisión para quedar cubierto, porque un despliegue no puede desconectar por sí solo una pestaña que ya está abierta.

Queda anotado como revisión pendiente, no urgente pero real: hoy la protección de estos streams depende enteramente de la lógica de la aplicación (qué se monta o no en pantalla), no de una barrera en el canal de video mismo — el motor de video ISYOÜ todavía corre en modo de prueba, sin tokens de acceso por canal. Con este bug corregido ya no hay una forma fácil de saltárselo, pero antes de una transmisión de gran escala vale la pena evaluar si conviene cerrar también esa capa.

Investigamos crashes reales del feed, corregimos dos causas concretas, y construimos un rastreador de errores automático — para dejar de investigar a ciegas

Reporte real: la app se estaba crasheando "demasiado", con un síntoma puntual — dejar el feed abierto unos segundos y la página se reiniciaba sola. Investigamos dos frentes en paralelo. El primero: las tarjetas del feed reproducen un video de vista previa al pasar el mouse por encima, montado y desmontado por el estado de la interfaz. En móvil, muchos navegadores disparan el evento de "entrar con el mouse" al tocar la pantalla, pero nunca el correspondiente "salir" cuando el usuario simplemente hace scroll — el video se quedaba reproduciendo indefinidamente, y con varias tarjetas así acumuladas a la vez, el feed llegaba a mantener varios decodificadores de video activos al mismo tiempo, una causa conocida de crash en Safari e incluso Chrome móvil. Se corrigió en dos partes: el preview con hover ahora solo se activa en dispositivos con mouse real (nunca en touch, donde no tiene sentido), y al dejar de hacer hover se pausa el video, se le quita el src y se fuerza .load() para liberar el decodificador de inmediato en vez de confiar solo en el recolector de basura del navegador.

El segundo frente: el ISYOÜ Coach (el asistente de IA del feed) le pide a nuestro modelo de IA una respuesta en JSON estructurado, pero cuando esa extracción fallaba —o el propio modelo devolvía el JSON pegado dentro de su propio campo de texto—, el usuario veía el bloque JSON crudo en el chat, sin entender nada. Se agregaron dos redes de seguridad (detectar cuándo un texto todavía parece JSON sin extraer, y rescatar solo el contenido real antes de rendirse) para que eso ya no vuelva a pasar, verificado contra 6 casos sintéticos distintos de respuesta mal formada.

Para no seguir investigando crashes a ciegas, se construyó un rastreador automático (crash_logs en nuestras bases de datos) que registra cada error real —de la interfaz, o cualquier error/promesa sin manejar en toda la app— con el contexto completo: quién, en qué pantalla, cuánto tiempo llevaba ahí, qué estaba haciendo justo antes (últimas 15 acciones), el error puntual con su stack, y diagnóstico de dispositivo, red, memoria y del propio DOM (incluye contar cuántos <video> hay activos en pantalla — justo para poder confirmar o descartar la hipótesis de arriba con datos reales la próxima vez). Se descubrió de paso que el botón manual "Reportar error" nunca había funcionado — no tenía regla propia en nuestras bases de datos, así que sus envíos llevaban fallando en silencio desde siempre mientras el cliente mostraba "reporte enviado" de todas formas. Ambas colecciones quedan visibles y accionables desde el panel de administración.

Estructura real del panel — quién, dónde, cuándo, qué estaba haciendo y el error puntual. Datos de ejemplo, no registros reales de usuarios.

Aplicamos una checklist completa de 26 puntos de SEO — y en el camino descubrimos que ISYOÜ son en realidad dos sitios distintos, no uno

Al ponernos a aplicar la checklist encontramos algo que cambiaba todo el enfoque: ISYOÜ son dos propiedades web separadas. isyou.io (repo hermano isyou-landing) es el sitio de marketing puro, sin login, y es el único que de verdad puede rankear en Google. app.isyou.io —esta misma app— está casi toda detrás de login; lo único públicamente indexable ahí son 4 rutas puntuales. Con eso claro, la checklist se aplicó completa en isyou.io, y en app.isyou.io el trabajo pasó a ser higiene técnica y control de indexación selectiva, no SEO de contenido.

1. Metatítulos únicos por página — título distinto para cada una de las 6 rutas de isyou.io, antes compartían todas el mismo.
2. Metadescripciones únicas por página — misma lógica, una descripción real por ruta.
3. Un solo H1 por página — auditado en las 6 rutas de isyou.io y las 3 páginas estáticas de app.isyou.io: ya cumplía, sin cambios necesarios.
4. H1 distinto al metatítulo — los 6 títulos se redactaron a propósito con una variante distinta al H1 visible de cada página.
5. Intención de búsqueda — cada título/descripción redactado según lo que esa página específica responde (documentación, whitepaper técnico, economía del token, legal).
6. TL:DR / puntos clave — componente nuevo con un resumen de 3-5 puntos por página.
7. El TL:DR va después de la intención — se coloca justo después del H1/hero, antes de cualquier otro contenido.
8. CTA después del primer párrafo — componente de llamado a la acción insertado tras el primer párrafo real de cada página, distinto al CTA del hero.
9. Estructura H1 → H2 → H3 — auditada, sin saltos de nivel.
10. Interlinkeado y clusters — enlaces nuevos entre Whitepaper, Tokenomics, Docs y Home, más enlaces salientes reales a app.isyou.io/costos y /report-cto como evidencia de transparencia.
11. Tablas y listas en vez de prosa — la distribución del token pasó de <div>s a una tabla semántica real; las capas de arquitectura del whitepaper pasaron a lista de definición.
12. FAQ — ya existía en la home (6 preguntas reales), quedó conectado a datos estructurados.
13. Schema de FAQ — JSON-LD FAQPage generado en vivo desde el mismo contenido visible, así nunca se desincroniza.
14. Nombres de imagen — auditado: las imágenes reales ya tenían nombres descriptivos; se eliminaron 4 PNG de respaldo sin usar.
15. Alt text — correcto en isyou.io; se corrigió un alt text duplicado ("Venesti" repetido en dos fotos distintas) encontrado de paso en /oficial-influencer.
16. Schema de negocio — JSON-LD Organization + WebSite (no LocalBusiness: ISYOÜ es una plataforma sin local físico).
17. Robots.txt — nuevo en isyou.io (abierto) y en app.isyou.io (bloquea solo los links personales de cobro).
18. URLs sin número ni conectores raros — ya cumplía (/docs, /whitepaper, etc.); queda como regla a mantener en rutas futuras.
19. Desindexar subcarpetas tipo /page/ — no aplica hoy, no hay blog paginado en ningún dominio; anotado para revisar si se agrega uno.
20. LLMS.txt — nuevo en ambos dominios, describe el sitio para crawlers de IA (convención llms.txt).
21. CTA fijo en móvil — barra inferior fija, solo visible en pantallas móviles.
22. Botón de compartir — Web Share API nativo, con respaldo de copiar al portapapeles.
23. GA4 — código listo con placeholder en el HTML.pendiente crear la propiedad real
24. Google Search Console — meta de verificación lista con placeholder.pendiente crear la propiedad real
25. Sitemap.xml — nuevo en ambos dominios.
26. Sitemap enviado en Search Consolependiente — requiere la propiedad verificada del punto 24

En app.isyou.io, el criterio fue distinto: /report-cto (este mismo diario) se dejó indexable — es contenido de marca real, no un secreto. /mejorar y /costos quedaron con noindex —siguen siendo accesibles por link directo, pero fuera de resultados de búsqueda— porque son reportes internos y financieros, no contenido pensado para rankear. La forma correcta de lograr eso no es bloquearlos por robots.txt (Google puede seguir mostrando la URL "pelada" en resultados si algo la enlaza, y report-cto sí enlaza a ambos): se permite el rastreo pero se marca noindex directamente en la página, que es la única forma de garantizar que no aparezcan.

isyou.io en vivo, ya con título/descripción únicos por ruta, JSON-LD y el bloque de resumen (TL:DR) recién agregado

El saldo ISY ya no muestra el badge "TEST" un instante en cada carga, incluso en producción real

El ambiente (sandbox o producción real) arranca asumido como sandbox por defecto hasta confirmarlo contra nuestras bases de datos — una convención conservadora correcta para cualquier lógica real de dinero, pero que hacía que el saldo ISY se viera con el badge "TEST" un instante en cada carga, sin importar el ambiente real. Ahora, mientras el ambiente todavía no está confirmado, se muestra un spinner corto en su lugar — nunca un dato que puede estar mostrando el badge equivocado.

Antes: el badge "TEST" aparecía un instante siempre. Ahora: un spinner corto mientras se confirma el ambiente real (montos ilustrativos)

Calculamos el costo real de transmitir El Palco en vivo, encontramos un riesgo de arquitectura escondido en el cálculo, y lo corregimos el mismo día

Antes de fijar el precio del cupo para la Gira ORIGEN necesitábamos saber, con números reales y no estimaciones genéricas, cuánto cuesta sostener una transmisión de El Palco a 1.000, 10.000 y 100.000 espectadores simultáneos: motor de video, base de datos, agentes de compra, alojamiento, notificaciones y comisión de los rieles de pago — todo contra tarifas públicas vigentes, con el reparto real de ingresos (95% para el creador, 5% para ISYOÜ). Haciendo ese cálculo apareció algo que no estábamos buscando: el contador de espectadores en vivo y el chat escribían y notificaban por cada entrada, salida o mensaje individual, a cada persona conectada — un patrón que crece con el cuadrado de la audiencia, no en línea recta como el video. A 100.000 espectadores esa sola pieza ya costaba $6.900 por hora, con una curva que la habría hecho superar al costo del video mismo pasado cierta escala.

Lo corregimos con el mismo patrón de "contador repartido" que ya usábamos para la venta de cupos: la escritura del conteo se reparte en 20 particiones al azar en vez de competir todas por el mismo registro, y un proceso automático combina el conteo y los mensajes nuevos del chat en un solo aviso cada 10 segundos, en vez de uno por cada cambio — cada espectador pasa de dos conexiones en vivo a una sola. Desplegado y verificado en producción: la misma pieza que costaba $6.900/hora a 100.000 espectadores ahora cuesta $21.60/hora. De paso corregimos un bug real que encontramos en el camino — las reglas de acceso a la base de datos solo dejaban escribir el conteo al dueño del stream, nunca a la audiencia, así que el contador de espectadores probablemente ya estaba fallando en silencio para todo el que no fuera el propio anfitrión.

Publicamos el desglose completo, con el precio del cupo editable en vivo para simular cualquier escenario, en app.isyou.io/costos.

app.isyou.io/costos en producción — el precio de 10 ISY por cupo es editable en vivo, y las tres tarjetas se recalculan solas

Encontramos y corregimos una falla real de dinero: los retiros bancarios estaban pagando 100 veces menos de lo debido

Un retiro real —dinero de verdad saliendo de la plataforma hacia una cuenta bancaria— reveló un error de conversión de unidades en el envío del monto al proveedor de pagos: el sistema mandaba el monto en pesos, pero el proveedor lo interpretaba como centavos. Quien retiraba el equivalente a $35,337 pesos colombianos recibía apenas $353.37 — cien veces menos, sin ningún mensaje de error de por medio, porque desde la perspectiva del proveedor la operación fue perfectamente válida.

Se confirmó la causa exacta contrastando la operación real contra la respuesta real del proveedor de pagos (no una suposición: la aritmética coincidió al peso), se corrigió y desplegó el mismo día, y se compensó manualmente al usuario afectado por la diferencia exacta faltante. Se revisó además el historial completo de retiros de la plataforma para confirmar que ningún otro usuario había sido afectado antes de la corrección — el hallazgo llegó a tiempo.

Segunda falla real de pagos: una opción de recarga duplicada y rota bloqueaba transferencias bancarias en Colombia

En el flujo de recarga de saldo aparecían dos opciones distintas de "transferencia bancaria" para Colombia, pero solo una de las dos pedía la información necesaria para completarse — la otra fallaba siempre, justo antes de cobrar, sin que la persona hubiera hecho nada mal. Se eliminó la opción rota; queda una sola vía de transferencia bancaria, la que sí funciona de principio a fin.

El saldo ISY dejó de parpadear a cero al recargar la página — esta vez, la causa raíz real

Semanas atrás corregimos un primer intento de este mismo síntoma. Un usuario reportó que lo seguía viendo, así que se investigó más a fondo y apareció una segunda causa, independiente de la primera: en el instante exacto de iniciar sesión, un punto distinto del código pisaba el saldo ya confirmado con un valor por defecto conservador, antes de que la aplicación terminara de confirmar en qué ambiente está operando. Ahora existe un único lugar responsable de mostrar el saldo, y solo actúa cuando está seguro de lo que muestra.

Blindamos el envío de correos del sistema — ya no depende de una sola cuenta que un tercero puede bloquear sin aviso

Alertas internas, recibos de compra y notificaciones a inversionistas dependían de una sola cuenta de correo que su propio proveedor podía bloquear en cualquier momento por revisión de seguridad — y lo hizo, en silencio, sin que nadie se enterara hasta que se buscó explícitamente. Se migró ese envío a un proveedor de correo dedicado, manteniendo la misma dirección institucional, y se confirmó en producción que vuelve a entregar con normalidad.

Animaciones y microinteracciones en la landing de la Gira ORIGEN

Se pulió la landing de app.isyou.io/oficial-influencer con animaciones pensadas para transmitir la seriedad de la alianza: las secciones se revelan suavemente al hacer scroll, el contador de personas ya registradas en el roster sube en vivo en vez de saltar de golpe, y cada tarjeta del roster tiene una pequeña celebración visual en el instante exacto en que alguien queda confirmado. Todo respeta la preferencia de movimiento reducido para quien la tenga activada.

app.isyou.io/oficial-influencer en producción — el hero con las animaciones ya pulidas

Publicamos la landing oficial de la Gira ORIGEN — identidad visual real de Venesti, login y verificación de identidad integrados

app.isyou.io/oficial-influencer es la puerta de entrada oficial de la alianza: identidad visual tomada directo del brandbook real de Venesti (paleta, tipografía y fotografía del propio artista, no una plantilla genérica), con el login de Google real de ISYOÜ y la verificación de identidad (KYC) integrados en el mismo flujo — cuando el artista o alguien de su equipo entra ahí y se loguea, su cuenta real en ISYOÜ queda creada de una, sin pasos manuales de por medio.

La landing en producción — identidad visual tomada del brandbook real de Venesti

La página también lleva el roster de la gira: cada persona que debe estar lista antes de salir a la ruta aparece como una tarjeta, en gris hasta que se registra. Ahí encontramos y cerramos un hueco de seguridad real antes de que llegara a usarse mal: la primera versión dejaba que cualquier cuenta logueada se marcara como "Venesti" con un solo click, sin ninguna verificación. Ahora "Soy yo" es una solicitud —exige verificación de identidad ya aprobada— que un admin confirma a mano viendo el nombre legal real del documento antes de que aparezca como registrado públicamente.

La estrategia explicada sin tecnicismos, y el roster de la gira debajo

Primer uso real con dinero real: encontramos y corregimos 4 fallas en producción el mismo día del lanzamiento

Con El Palco ya en producción, hicimos la primera compra real de un cupo —dinero de verdad, no una prueba simulada— y usamos ese mismo flujo para hacer control de calidad en vivo. Aparecieron 4 fallas reales, las 4 corregidas y desplegadas el mismo día:

• El asiento que se pintaba "ocupado" en el mapa después de comprar no era el mismo que el fan había elegido — ahora tu asiento elegido siempre queda marcado como tuyo, con un check visible.
• El indicador de "procesando pago" se veía superpuesto sobre el resto del formulario — se reemplazó por un panel de carga dedicado y limpio.
• El creador, al elegir con qué evento salir en vivo, veía siempre la capacidad total del show en vez de los cupos que de verdad quedaban disponibles.
• El saldo de un usuario podía parpadear a $0 por una fracción de segundo justo al recargar la página, antes de que la app confirmara que el ambiente es de producción y no de pruebas — quien mirara en ese instante exacto podía pensar que su plata había desaparecido. Ya no se pisa el saldo conocido mientras se confirma.

De la propuesta a un producto real: construimos El Palco de punta a punta, de la primera idea publicada el 10 de agosto a un sistema completo de escasez, pagos y transmisión en vivo

Diecisiete días después de publicar la primera propuesta en "Mejorar", El Palco dejó de ser una idea en discusión y se convirtió en un producto construido: un sistema completo de acceso premium por escasez, con su propio motor de ventas, su propia mecánica de renovación, y su propia capa de transmisión en vivo. No es una función aislada — es una segunda economía de acceso dentro de ISYOÜ, construida sobre los cimientos que la plataforma ya tenía (live streaming, créditos ISY, verificación de identidad) pero con reglas propias diseñadas específicamente para generar demanda real, no solo contenido.

La construcción se hizo en capas, cada una resolviendo una pregunta de negocio concreta antes de pasar a la siguiente: primero, que cualquier creador verificado pudiera crear y publicar su propio Palco sin depender del equipo (self-service); después, que un fan pudiera descubrir y comprar un cupo desde el perfil del creador con una experiencia visual de escasez real — un mapa de asientos estilo cine, ocupándose en vivo frente a sus ojos; luego, que ese cupo no fuera una compra pasiva sino algo que hay que defender activamente, con un cronómetro de 24 horas que arranca cuando el show sale al aire y libera el lugar para otro fan si no se renueva a tiempo; y finalmente, que un creador pudiera transmitir con equipo profesional externo (OBS Studio) en vez de depender solo de la cámara del navegador, para producciones del nivel que una gira real exige.

Cada una de esas piezas se probó contra sistemas reales antes de darla por buena — no solo contra el diseño en papel. Eso es lo que documentan las siguientes entradas de este mismo día: el lanzamiento formal, la validación en vivo contra la cuenta real del motor de video (con dos fallas reales encontradas y corregidas en el camino), y finalmente la preparación explícita para vender a la escala que la alianza con MiaClip y Venesti va a exigir — miles de cupos, todos los días, sin que el sistema se trabe justo en el momento de más demanda.

ISYOÜ v5.0.1 — Lanzamos "El Palco": cupos de acceso premium que se renuevan cada 24 horas

Después de publicar la propuesta en "Mejorar" el 10 de agosto, construimos y pusimos en operación "El Palco": cualquier creador verificado por KYC puede crear su propio evento de acceso limitado a un live específico — cupos, precio y fecha los define el propio creador, sin intervención del equipo. Desde el perfil de cada creador, sus fans compran su cupo en una experiencia de selección tipo cine (asientos disponibles/ocupados en tiempo real), con verificación de identidad obligatoria y sin reembolsos, ambos puntos explícitos en los Términos y Condiciones antes de pagar.

La pieza central del diseño es la escasez real: cada cupo dura 24 horas desde que el show se pone en vivo — no desde el momento de la compra, así una compra anticipada no vence antes de que el evento ni siquiera haya empezado. Pasadas esas 24 horas sin renovarse, el cupo se libera automáticamente para que otro fan lo tome. Esta lógica corre sola en el servidor, sin intervención manual, y quedó verificada para no perjudicar a nadie si el creador sufre una caída de conexión o cierra el live por error: el cronómetro no se reinicia mientras el evento siga siendo el mismo. Los repartos de ingresos con socios comerciales externos quedan reservados exclusivamente al creador ancla oficial de la plataforma y solo pueden asignarse desde el panel administrativo — un creador nunca puede auto-asignarse un socio ni redirigir parte de sus ventas a otra cuenta.

ISYOÜ v4.8.77 — cierre del ciclo previo a "El Palco"

Versión de referencia que cierra el ciclo de estabilización de agosto antes de comenzar el desarrollo de "El Palco": incluye el refuerzo de acceso a los documentos de verificación de identidad (KYC) y la corrección de propinas/desbloqueos que fallaban en silencio, ambas del 13 de agosto. Queda como el punto de partida verificado sobre el que se construyó la v5.0.1.

El Palco en vivo real: probamos la transmisión externa contra el motor de video y corregimos dos fallas que dejaban al creador sin poder salir al aire

La transmisión externa de El Palco (un creador transmite desde OBS Studio u otra app de streaming, en vez de la cámara del navegador, para producciones más ambiciosas como la Gira ORIGEN) se había construido con base en la documentación pública del motor de video, sin poder probarla todavía contra la cuenta real — quedó marcada explícitamente como pendiente de verificar. Hoy hicimos esa prueba real y encontramos dos problemas concretos: el método HTTP que la documentación indicaba para pedir la clave de transmisión estaba mal (decía uno, la cuenta real exige otro), y el complemento de recepción de señal externa —necesario para aceptar una señal de video externa— ni siquiera estaba activado en la cuenta de ISYOÜ. Corregimos el primero apenas lo confirmamos con una prueba directa, y activamos el segundo. Con los dos resueltos, probamos el flujo completo de punta a punta: generar la clave de transmisión, conectar OBS, salir en vivo, y cerrar la transmisión al terminar — funciona.

En el camino de esa prueba aparecieron dos fallas reales de confiabilidad, ambas ya corregidas. La primera: si a un creador se le cae la conexión o el motor de video devuelve un error a mitad de una transmisión y decide cerrarla, no podía volver a salir en vivo para ese mismo evento de Palco — el sistema lo "escondía" de la lista de eventos disponibles en cuanto había estado en vivo una vez, dejando al creador sin forma de reconectarse a su propio show (y, con eso, sin forma de que sus fans volvieran a verlo). La segunda: si la transmisión externa fallaba al activarse, la aplicación igual marcaba el show como "en vivo" por dentro, aunque en realidad no hubiera ningún video publicándose — una transmisión fantasma, invisible para el creador pero registrada como activa en el sistema. Ahora, si la transmisión externa falla, todo el intento se cancela limpio en vez de dejar un show a medias, y un creador siempre puede reconectarse a su propio evento sin importar cuántas veces se le haya caído antes.

Preparamos El Palco para la escala real de la Gira ORIGEN: 1.000 cupos diarios sin cuello de botella, y crear una gira completa de una sola vez

Con la conversación de alianza con MiaClip y Venesti avanzando hacia una gira de fechas diarias vendiendo hasta 1.000 cupos por show, encontramos y corregimos una limitación real de escala antes de que se volviera un problema en producción: nuestras bases de datos soportan, en la práctica, aproximadamente una escritura por segundo sobre un mismo registro — y el contador de cupos vendidos de cada evento vivía en un solo registro. Un "drop" real de mil fans comprando su cupo casi al mismo tiempo —el efecto FOMO que el propio diseño de El Palco busca provocar— habría generado justo el peor momento posible para que las compras empezaran a fallar o demorarse. Lo resolvimos con un patrón de "contador repartido": en vez de un solo contador, son 20, y cada compra se registra en uno elegido al azar — la carga se reparte entre los 20 en vez de competir todos por el mismo, sin que el creador, el fan, ni el panel de administración noten ninguna diferencia en cómo se ve o se usa el sistema.

También construimos una herramienta para cargar una gira completa de una sola vez, en vez de crear cada fecha a mano en el panel: se listan las ciudades en el orden real del itinerario y el sistema crea automáticamente un evento de Palco independiente por cada una, todas con el mismo precio, cupos y reparto de ingresos, listas para publicarse. Y para que el tablero de ventas por ciudad sea confiable de verdad, estandarizamos cómo se captura la ciudad —tanto cuando se crea un evento como cuando un fan compra su cupo— a una lista curada de ciudades de referencia en los cuatro países de la Fase 1 (Brasil, México, Colombia, Argentina), con autocompletado al buscar el creador o el socio comercial del evento. Antes, un texto libre sin estandarizar podía registrar "Bogotá" y "bogota" como dos ciudades distintas en las métricas; ahora caen en el mismo valor, lo que hace posible segmentar y hacer seguimiento real por ciudad — la base necesaria para decidir, con datos, qué fechas priorizar en la ruta de la gira.

Reforzamos el acceso a los documentos de verificación de identidad (KYC) de los usuarios

Durante la investigación de un reporte de propinas encontramos, como hallazgo colateral, que los datos que los usuarios suben para verificar su identidad —número de documento, fecha de nacimiento y las fotos del documento y la selfie— podían ser leídos por cualquier persona con una sesión iniciada en la app, incluso una cuenta recién creada sin ninguna verificación propia. No encontramos evidencia de que alguien externo haya explotado esto; lo detectamos nosotros mismos durante una revisión de rutina.

Movimos esos documentos a un almacenamiento separado donde solo el dueño de la cuenta y el equipo administrador pueden leerlos, y migramos los 106 registros existentes a la nueva ubicación sin perder ni un dato —verificado uno por uno antes y después del cambio—. De paso cerramos una segunda grieta relacionada: la forma en que la app comprobaba si un número de documento ya estaba registrado permitía, indirectamente, consultar esa información desde fuera; ahora esa validación la hace exclusivamente nuestro servidor.

Propinas y desbloqueos que "no pasaban nada": la app ahora avisa en vez de fallar en silencio

Un reporte directo de que una propina de 1 ISY no se había descontado del saldo nos llevó a auditar a fondo esa transacción específica: confirmamos con el registro contable real que sí se cobró correctamente, y que el saldo de prueba (nunca dinero real) que arrastraba esa cuenta desde una corrección de julio quedó saneado. Pero en el camino encontramos un problema real y distinto: cuando una publicación queda sin un creador asignado en la base de datos —algo raro, pero posible—, la pantalla de pagar/dar propina se cerraba como si todo hubiera salido bien, sin cobrar nada y sin avisarle a nadie que la operación no se había procesado.

Ahora, en ese caso puntual, la app muestra un error claro en vez de simular un pago exitoso, y el intento queda registrado para que el equipo lo pueda revisar. No hubo pérdida de dinero de ningún usuario en ningún momento —el problema era de retroalimentación visual, no de manejo de fondos—.

"El Palco": publicamos la primera propuesta estratégica en el nuevo espacio de Mejorar, abierta a comentarios

Lanzamos "Mejorar", un espacio público donde documentamos y sometemos a comentario propuestas de negocio antes de construirlas. La primera propuesta publicada ahí es "El Palco": acceso premium a transmisiones en vivo por escasez — un número fijo de cupos personales, verificados por KYC y no revendibles, pensado primero para artistas con giras en vivo. La idea es convertir a los fans más comprometidos de un creador en algo más que seguidores, dándoles un lugar reservado y exclusivo en el show.

La propuesta no reinventa la plataforma — se apoya en el streaming en vivo, los pagos internos y la verificación de identidad que ISYOÜ ya tiene. El presupuesto estimado para llevarla del primer cupo vendido a un lanzamiento real es de USD 6.750; de ese total, el CTO financia el 70% (USD 4.725) directamente, y se buscan inversionistas para el 30% restante desde esta primera etapa. El documento completo, con pros, contras y las preguntas de negocio aún sin resolver, está publicado para quien quiera comentarlo.

Cambiar entre cámara frontal y trasera ya funciona, tanto en transmisiones en vivo como al crear contenido

Un usuario reportó que no podía alternar entre la cámara frontal y la trasera de su celular, ni al grabar en vivo ni al crear contenido desde la cámara. Al revisar encontramos dos fallas distintas detrás del mismo síntoma: en la pantalla de crear contenido, el botón pensado para cambiar de cámara existía visualmente pero en realidad solo volvía a activar la misma cámara frontal, sin ningún efecto; y en el estudio de transmisión en vivo, la opción para elegir cámara solo estaba disponible en la configuración previa a salir al aire —una vez transmitiendo, no había ninguna forma de cambiarla.

Corregimos ambos casos: el botón de crear contenido ahora sí alterna entre cámara frontal y trasera cada vez que se presiona, y agregamos un control nuevo, visible mientras se está transmitiendo en vivo, que permite cambiar de cámara sin interrumpir la transmisión ni perder la conexión con la audiencia.

Pagos en efectivo por OXXO y 7-Eleven en México: encontramos por qué fallaban desde el primer intento y quedaron funcionando

Una alerta automática del sistema de pagos avisó de una compra de ISY Credits rechazada al elegir pagar en efectivo en una tienda 7-Eleven en México. Al revisar el historial completo encontramos que ese método —y también OXXO— nunca había completado una compra exitosa desde que se agregaron como opción en la app: la solicitud llegaba a nuestro proveedor de pagos con un identificador de método que ese proveedor no reconoce como válido, así que la rechazaba antes de siquiera generar el código de pago para la tienda.

Corregimos la forma en que la app le informa al proveedor cuál método usar para ambas tiendas, sin cambiar nada de lo que el usuario ve ni tiene que hacer: la pantalla de compra sigue mostrando "OXXO" y "7-Eleven" como opciones separadas, cada una con su logo. Como parte de la misma revisión detectamos un problema relacionado en el retiro de saldo en efectivo por estas mismas tiendas, que quedó identificado y documentado para una corrección aparte.

Compras de ISY Credits que "desaparecían": encontramos la causa raíz y blindamos el sistema para que no vuelva a pasar

Varios usuarios reportaron que pagaban por ISY Credits pero su saldo no subía, y en paralelo otros no podían desbloquear contenido pagado aunque la app les mostraba saldo suficiente. Investigamos a fondo —incluyendo revisión de logs de los últimos días— y encontramos la causa: el sistema usa un interruptor interno, presente tanto en la app como en el servidor, para distinguir operaciones reales de operaciones de prueba. En ciertos casos ese interruptor podía quedar leído de forma distinta en cada lado, así que el servidor registraba un pago real como "de prueba" mientras la app seguía mostrando el saldo real, dejando el ISY comprado atrapado sin que el usuario lo viera ni pudiera usarlo.

Unificamos esa lógica en un único punto de verdad, compartido por app y servidor, para que ambos lados nunca más puedan interpretar la misma señal de forma distinta. Construimos además una herramienta en el panel de administración que detecta automáticamente si alguna compra pasada quedó atrapada de esta forma y permite corregirla con un clic, dejando esta vez un registro contable completo del ajuste —a diferencia de correcciones manuales antiguas, que no dejaban rastro.

Como parte del mismo trabajo, reforzamos la vigilancia sobre el proveedor de pagos con tarjeta: el sistema ahora prueba activamente el paso más sensible del proceso —el que realmente autoriza el cobro—, no solo la creación inicial de la sesión de pago. Si el proveedor tiene un problema técnico o de facturación, el equipo se entera de inmediato por correo en lugar de descubrirlo cuando un usuario se queja, y la app ofrece automáticamente completar la compra por PSE, SPEI o PIX en vez de mostrar solo un error genérico.

El flujo de "recargar y desbloquear" contenido pagado vuelve a ser confiable de principio a fin

Cuando un usuario intenta ver contenido pagado sin saldo suficiente, la app le ofrece completar la compra sin salir de esa pantalla. Encontramos dos fricciones puntuales en ese atajo: algunas compras iniciadas por transferencia bancaria, PSE, PIX o SPEI desde ahí no se estaban procesando correctamente y el usuario recibía un error técnico sin poder completar el pago; y el monto que la app calculaba automáticamente en la moneda local —para cubrir el precio exacto del contenido— a veces se reemplazaba por un monto genérico apenas el usuario elegía su método de pago, obligándolo a corregir la cifra a mano o arriesgándose a pagar de más o de menos.

Ambos casos ya están corregidos: el monto autocalculado se mantiene estable sin importar cuántas veces el usuario cambie de método de pago, y las compras desde ese atajo se procesan con la misma confiabilidad que desde la billetera principal. También agregamos un mensaje claro para cuando es el propio usuario quien cancela el pago dentro de la app de su banco —antes se mostraba como un error genérico y confuso, ahora se explica con claridad que puede intentarlo de nuevo o elegir otro banco.

Auditoría automática de saldos: el equipo ahora detecta y corrige discrepancias sin tocar el dinero de nadie por error

Con miles de usuarios generando ISY Credits por decenas de vías distintas —compras, propinas, desbloqueos, referidos— era cuestión de tiempo que aparecieran pequeñas discrepancias entre el saldo visible de una cuenta y el historial completo de movimientos que lo respalda. El panel de administración ahora ejecuta una auditoría completa que compara ambos valores para cada cuenta y clasifica el resultado automáticamente: si el historial respalda un saldo mayor al registrado, lo corrige con un solo clic; si el historial está vacío o no cuadra —algo habitual en cuentas que recibieron ISY por transferencias internas, no por compra directa— lo marca para revisión manual en lugar de tocarlo. Esto evita el riesgo real de que una corrección automática mal calibrada le borre saldo legítimo a un usuario.

Como parte del mismo trabajo, el indicador de "salud del ecosistema" del panel —que compara cuánto ISY existe en circulación contra cuánto ha sido efectivamente comprado— ahora refleja con precisión cuándo el equipo ha revisado y aceptado formalmente una discrepancia histórica, en lugar de seguir mostrando una alerta roja sobre un problema que ya fue evaluado y cerrado.

La guía de compra ya se puede recorrer completa en móvil

La pantalla que orienta al usuario justo antes de comprar ISY Credits —la que explica el precio, la equivalencia en dólares y los pasos del proceso— quedaba parcialmente cortada en dispositivos móviles cuando el contenido era más alto que la pantalla, sin forma de desplazarse para ver el resto. Se corrigió el comportamiento de desplazamiento de esa pantalla para que se comporte igual que el resto de paneles de la plataforma, garantizando que el usuario siempre pueda ver y usar todos los botones, sin importar el tamaño de su pantalla.

Comprar ISY Credits, a un clic desde cualquier pantalla de la app

El indicador de saldo que aparece en la esquina superior de la aplicación ahora funciona también como acceso directo para comprar más ISY Credits, sin necesidad de navegar primero hasta la sección de billetera. Un usuario que está viendo contenido, chateando o explorando el feed puede iniciar una recarga en un solo clic desde donde se encuentre. Se simplificó además el panel de billetera, eliminando un banner promocional que repetía la misma función ya disponible desde la cabecera de la app.

El usuario ve ISYOÜ en menos de 1 segundo — sin importar la velocidad de red

En modo incógnito (sin caché del Service Worker), el navegador tiene que descargar 1.5 MB de código antes de poder mostrar cualquier cosa. En una conexión 3G eso puede tardar entre 10 y 15 segundos — y durante ese tiempo la pantalla estaba completamente en blanco. Un usuario que no conoce la plataforma lo interpreta directamente como que la página está caída.

La solución fue insertar una pantalla de bienvenida directamente en el HTML inicial — el archivo más ligero de la plataforma, que el alojamiento del dominio entrega en menos de 100 ms desde su CDN, sin depender de ningún archivo JavaScript o CSS externo. El usuario ve el logo animado de ISYOÜ y una barra de carga con los colores de la marca desde el primer instante. En cuanto la interfaz termina de cargarse, esa pantalla se desvanece suavemente y da paso a la experiencia normal.

No se tocó el bundle, no se modificó la arquitectura. El cambio fue de dos archivos y resuelve uno de los problemas de primera impresión más importantes que puede tener cualquier aplicación web.

Grabados en modo incógnito · red 3G simulada · iOS Safari — mismas condiciones, mismo dispositivo, mismo día.

El visor de contenido funciona correctamente en iPhone — navegación y scroll resueltos

Dos problemas afectaban al visor de contenido (imágenes, videos, infoproductos) en dispositivos Apple. Por un lado, la barra de navegación inferior permanecía visible encima del visor aunque éste estuviese abierto a pantalla completa. Por otro, el área de detalle del contenido —donde se ven el precio, la descripción y los botones de acción— no respondía al scroll táctil.

Ambos problemas tenían la misma raíz técnica: el visor se estaba dibujando dentro de una zona de la app que iOS Safari no reconoce como independiente del flujo de desplazamiento de la página. Al sacar el visor de esa zona y dibujarlo directamente sobre el lienzo raíz de la aplicación, el sistema operativo lo trata correctamente: cubre toda la pantalla, oculta la barra de navegación por debajo, y el scroll interno funciona de forma nativa. Se añadió además el relleno necesario para que los botones de acción no queden parcialmente ocultos detrás del indicador de inicio del iPhone.

Login con Google en Safari — de varios segundos de espera a respuesta inmediata

Los usuarios de Safari —tanto en iPhone como en Mac— experimentaban una demora notable al intentar entrar con Google. En iPhone el botón parecía no reaccionar durante varios segundos; en Mac se abría un popup que tardaba en cargar o simplemente no respondía. Ambos síntomas tenían causas distintas pero relacionadas.

El problema en Mac: Safari bloquea el canal de comunicación interno que nuestra plataforma necesita para gestionar los popups de autenticación. El resultado es un popup que se congela o tarda demasiado. La solución fue usar el mismo flujo de redirección que ya funcionaba en iPhone — Safari en todas sus versiones ahora redirige directamente a Google y vuelve sin pasar por el popup bloqueado.

El problema en todos los navegadores: La app consultaba al servidor de autenticación de Google en cada carga, independientemente de si el usuario había iniciado un proceso de login o no. Esa consulta podía tardar entre 2 y 8 segundos. Se añadió una comprobación previa que descarta esa llamada instantáneamente si no hay ningún proceso de login en curso — lo que cubre el 99% de las cargas habituales de la app.

Como mejora adicional, cuando el usuario vuelve desde la pantalla de Google, la app ahora muestra un mensaje específico — "Verificando tu cuenta con Google…" — en lugar del loader genérico, para que sepa exactamente en qué punto del proceso está.

El botón de Google ahora tiene un indicador circular de progreso

Al hacer clic en "Ingresar con Google", el botón mostraba un spinner básico — una forma de media luna que giraba sin más contexto visual. Se reemplazó por un indicador circular con pista de fondo: un anillo completo en gris muy suave marca el recorrido total, y un arco coloreado con extremos redondeados gira sobre él. El resultado es visualmente más claro, más alineado con los estándares de diseño actuales y transmite mejor la sensación de que algo está en proceso.

El botón "Ingresar con Google" ahora responde visualmente al instante

Los usuarios reportaban que al hacer clic en el botón de Google, nada sucedía visualmente durante varios segundos — el botón seguía igual y no había ninguna señal de que la acción se había registrado. Esto generaba clics múltiples y confusión sobre si el sistema había respondido.

La causa era un error arquitectónico: en el momento del clic, la app reemplazaba la pantalla de login por una pantalla de carga genérica antes de que el botón pudiera mostrar su propio estado activo. El botón nunca llegaba a verse en modo "cargando" porque ya había desaparecido de la pantalla.

Con la corrección, el botón reacciona en el mismo instante del clic: el indicador circular de progreso aparece, el texto cambia a "Conectando con Google…" y un efecto de luz deslizante confirma visualmente que el sistema está en marcha. Mientras el proceso está activo, el botón bloquea automáticamente cualquier clic adicional. La sensación de respuesta es inmediata y no da lugar a dudas.

Canal de contacto unificado — un solo email para toda la plataforma

La plataforma tenía tres direcciones de correo distintas visibles para los usuarios según la sección que visitaran: soporte técnico, consultas generales y privacidad. Se unificó todo a una sola dirección operativa — info@imodelentertainment.io — que aparece de forma consistente en el modal de soporte, el perfil de usuario y la página de política de privacidad. Un solo punto de contacto simplifica la operación y da una imagen más profesional y ordenada.

Calculadora automática de ISY: el comprador nunca más calcula cuánto necesita

Hasta hoy, cuando un usuario intentaba desbloquear contenido premium sin saldo suficiente, veía un overlay genérico con el precio y un botón "Comprar ISY" — sin contexto del producto, sin cálculo visible, sin nada que conectara la recarga con la compra. El usuario tenía que entender por su cuenta cuánto recargar, a qué equivale en pesos, y luego volver al contenido a intentarlo de nuevo.

Implementamos la calculadora automática de ISY — una tarjeta contextual que aparece en el momento exacto en que el usuario no tiene saldo suficiente. Muestra de forma clara: cuánto cuesta el contenido en ISY, cuánto tiene el usuario, cuánto le falta — y un CTA que dice exactamente qué va a pasar: "Recargar 32.20 ISY y comprar IOCUS". El badge 1 ISY = 1 USD ancla la equivalencia sin que el usuario tenga que buscarla. El estimado en moneda local (COP, MXN, BRL o ARS según el país) se calcula automáticamente desde el navegador.

Cuando el usuario completa la recarga, la plataforma detecta automáticamente que el saldo ya es suficiente y ejecuta el desbloqueo sin ninguna acción adicional. El contenido se abre solo. El flujo de compra de ISYOÜ ahora es completamente guiado: el usuario nunca necesita calcular, nunca pierde el contexto del producto que quería comprar, y no tiene que volver a tocarlo después de recargar.

Compra de ISY Credits sin salir del contenido que te interesa

Hasta hoy, si un usuario quería desbloquear un libro o recurso exclusivo y no tenía saldo suficiente, debía abandonar el contenido, ir a la billetera, recargar ISY y volver al feed para encontrar y desbloquear de nuevo. Con el nuevo flujo, el panel de compra aparece directamente encima del contenido — sin cerrar nada. El usuario recarga, el saldo se actualiza en tiempo real, el panel se cierra solo y puede desbloquear en ese mismo instante. Cero fricciones, cero navegación extra.

El panel de compra aparece sobre el contenido. Al completar el pago se cierra automáticamente y el usuario desbloquea de inmediato.

Guía interactiva contextual: cada contenido explica su propio precio

Antes de llegar al formulario de pago, el usuario ahora recibe una pantalla de orientación personalizada para ese contenido específico: muestra el título, el precio en ISY, la equivalencia en dólares y un recorrido de cuatro pasos que explica el proceso de principio a fin. No es una pantalla genérica — se adapta en tiempo real al contenido que el usuario quiere desbloquear, eliminando la incertidumbre de los usuarios que compran ISY por primera vez.

El acceso pagado es permanente — los creadores no pueden retirar contenido con compradores

Se identificó y resolvió un caso crítico real: un usuario había comprado contenido y el creador, al renombrarlo y volver a publicarlo, provocó sin saberlo que el comprador perdiera su acceso. A partir de hoy, tres capas de protección garantizan que esto no vuelva a ocurrir. Primero, la interfaz informa al creador claramente que no puede retirar contenido que ya tiene compradores. Segundo, el sistema de acceso lo bloquea a nivel operativo antes de intentar la operación. Tercero, los permisos de la plataforma hacen imposible el borrado de contenido con compradores desde cualquier punto de acceso, no solo desde la interfaz. Los compradores que hayan adquirido contenido posteriormente retirado verán un aviso informativo, pero su acceso se mantiene íntegro de forma indefinida.

Izquierda: el creador recibe un bloqueo explícito al intentar retirar contenido con compradores. Derecha: el comprador accede normalmente con un aviso transparente.

Las transacciones no pueden quedar en el limbo

Se eliminó un caso extremo pero real: si el pago se procesaba correctamente pero una falla de red impedía registrar el acceso al contenido en ese preciso instante, el usuario quedaba sin acceso pese a haber pagado. Ahora el sistema detecta ese escenario de forma automática — otorga el acceso de inmediato, notifica al equipo para revisión y no expone ningún error al usuario. El comprador nunca queda atrapado entre "pagué" y "no tengo acceso". Adicionalmente, la operación de registro de acceso fue reforzada para tolerar condiciones de red inestables sin perder datos.

Blindaje de saldos, mensajería renovada y privacidad en documentos

La plataforma incorporó una nueva capa de auditoría automática que detecta inconsistencias en los saldos de los usuarios en tiempo real, sin necesidad de intervención manual. Simultáneamente, el módulo de mensajería fue revisado en profundidad: los nuevos chats aparecen al instante cuando un usuario comenta una publicación, las fotos de perfil se muestran correctamente y el estado en línea refleja la presencia real del usuario. Adicionalmente, la visualización de documentos adjuntos protege por completo el almacenamiento interno de la plataforma — el usuario ve el archivo sin ningún rastro de dónde está guardado.

Corrección visual en dispositivos Apple

Se resolvió un problema de presentación en la barra de navegación al usar la plataforma desde un iPhone o iPad, donde la barra superior se superponía incorrectamente con el contenido de la pantalla, afectando la experiencia de navegación móvil.

Panel de control centralizado para el equipo directivo

El equipo ahora dispone de un panel unificado donde puede verificar en tiempo real el estado de todos los servicios de pago, detectar problemas antes de que afecten a los usuarios y habilitar o deshabilitar métodos de cobro sin publicar una nueva versión de la plataforma. Una herramienta de operación directa pensada para los co-fundadores.

Control de métodos de pago desde el panel

El pago con tarjeta de crédito o débito puede ahora activarse o desactivarse directamente desde el panel de administración, sin ninguna intervención técnica adicional. Esto permite al equipo reaccionar de forma inmediata ante cualquier situación operativa relacionada con los procesadores de pago.

Unificación de la identidad visual

La aplicación adopta los mismos colores, tipografías y proporciones del sitio público, consolidando una imagen de marca coherente en todos los puntos de contacto con el usuario. La experiencia visual ahora es continua desde la landing hasta el interior de la plataforma.

Recuperación automática ante versiones desactualizadas

Cuando un usuario tiene cargada en su navegador una versión antigua de la plataforma, el sistema detecta la situación y se actualiza automáticamente, sin que el usuario tenga que hacer nada. Esto elimina una fuente frecuente de errores silenciosos en la experiencia de uso.

ISYOÜ v4.8.11 — Plataforma 100% FIAT operativa

Versión de referencia de la plataforma: el ciclo de pago real → ISY Credits queda completamente cerrado y verificado en producción. Se activan herramientas administrativas para el equipo, se refinan los mensajes de error con identidad de marca y se mejora la experiencia de compra en dispositivos móviles. Hito de madurez del modelo económico de ISYOÜ.

Saldo ISY actualizado al instante

El saldo de ISY Credits del usuario ahora se actualiza en tiempo real dentro de la aplicación. No es necesario recargar la página para ver los cambios tras una acreditación, una compra o una transferencia. La experiencia de saldo pasa a ser verdaderamente instantánea.

Mejora en la generación de imágenes con IA

Los modelos de inteligencia artificial utilizados para la generación de imágenes fueron actualizados a versiones más capaces y precisas, con mejor registro interno de operaciones para el seguimiento del equipo y la detección temprana de anomalías.

ISY Credits — nombre oficial de los créditos de plataforma

Los créditos internos de la plataforma adoptan su nombre definitivo: ISY Credits. El cambio se refleja en todos los textos, notificaciones, documentos y pantallas. Es el cierre de un proceso de rebranding que consolida la identidad económica de ISYOÜ.

Resumen de compra antes de confirmar el pago

Los usuarios ahora ven un resumen claro y detallado de lo que están adquiriendo antes de confirmar cualquier pago. Este paso adicional de transparencia reduce dudas, rechazos y contactos de soporte por cargos no reconocidos.

El servidor como única fuente de verdad para pagos

La configuración del entorno de pagos ahora es administrada exclusivamente desde el servidor. Esto elimina una fuente potencial de inconsistencias que podía surgir cuando diferentes clientes operaban bajo configuraciones distintas sin que el equipo lo detectara.

Navegación más limpia y enfocada

Se eliminaron secciones y opciones que ya no corresponden al modelo actual de la plataforma. La experiencia de navegación resulta ahora más directa, coherente con la propuesta de valor de ISYOÜ y libre de ruido que distrae al usuario.

Despliegue exclusivo en modo FIAT

Con la migración al modelo FIAT ya integrada en el código, se despliega la primera versión de producción que opera exclusivamente bajo este esquema — sin dependencias de activos externos visibles para el usuario final. El punto de no retorno hacia la economía de ISY Credits que hoy sostiene a la plataforma.

Gran actualización: ISYOÜ migra completamente al modelo FIAT

Primera versión de la plataforma completamente desligada de activos externos. Actualización integral de todos los módulos para adoptar el modelo de créditos internos. Un paso fundacional que define el rumbo económico de ISYOÜ hacia todos los mercados de LATAM.

Nuevo landing + build sincronizado con la app

Se estrena una nueva versión del landing público y se sincroniza su proceso de construcción con el de la aplicación principal, garantizando que ambos reflejen siempre la misma versión de marca y contenido sin desincronizarse entre despliegues.

v4.3.34 — Compra, transmisiones en vivo y auditoría completa

Se completa el flujo de adquisición de ISY Credits con pago en moneda local, se mejora la estabilidad y calidad del estudio de transmisiones en vivo, y se realiza una auditoría integral de todos los módulos de la plataforma. Versión que marca el inicio de la fase de estabilización y crecimiento.

Cumplimiento legal implementado

Se incorporan los documentos y flujos de cumplimiento legal requeridos para operar la plataforma de forma responsable — términos, políticas y avisos alineados con los mercados donde ISYOÜ opera. Una base necesaria antes de escalar el volumen de usuarios y transacciones.

V4.3.9 — listo con Google

Una serie de versiones intermedias (V4.3.2 a V4.3.9) refina la interfaz y corrige comportamientos detectados en producción, cerrando con la disponibilidad estable del inicio de sesión con Google como método de acceso principal.

V4.1.5 — nuevo landing page

Se rediseña por completo el landing público de ISYOÜ, la primera impresión de la marca para cualquier usuario nuevo, alineándolo con la identidad visual que la aplicación ya venía consolidando internamente.

V4.1.0 / V4.1.1 — fixes críticos de notificaciones

Se corrigen fallas críticas detectadas en el sistema de notificaciones que podían dejar a usuarios sin avisos de actividad relevante en su cuenta, junto con una ronda de ajustes de interfaz sobre la misma versión.

V4.0.57 — KYC listo

Entra en funcionamiento el módulo de verificación de identidad (KYC), requisito indispensable para habilitar operaciones de mayor volumen y cumplir con las exigencias regulatorias de los mercados donde opera ISYOÜ.

V4.0.53 — refuerzo de seguridad

Ronda dedicada de endurecimiento de seguridad sobre la plataforma, en preparación para el volumen creciente de usuarios y transacciones que empezaba a manejar ISYOÜ en ese momento.

V4.0.40 — infoproductos + P2P completo

Se completa el módulo de infoproductos —contenido digital empaquetado y vendible directamente en la plataforma— junto con el sistema de intercambio persona a persona (P2P), ampliando las formas en que los creadores pueden generar ingresos dentro de ISYOÜ.

V4.0.27 — RAMP con tarjeta de crédito

Se habilita la compra de créditos directamente con tarjeta de crédito, sumando un método de pago clave junto a las transferencias bancarias ya disponibles, y ampliando notablemente quién puede convertirse en comprador.

V4.0.13 — ISYOU LABS

Lanzamiento de ISYOU LABS, el espacio de generación de contenido con inteligencia artificial dentro de la plataforma — el punto de partida de las herramientas de creación asistida por IA que hoy forman parte central de la propuesta de valor para creadores.

V4.0.5–V4.0.10 · nuestro motor de notificaciones

Se integra nuestro motor de notificaciones push, reemplazando la solución anterior y sentando las bases de un sistema de avisos más confiable y escalable para mantener a los usuarios informados de actividad relevante.

Wallets v2 + sistema de pago Vault

Se rediseña por completo el módulo de billeteras (Wallets v2), corrigiendo una falla crítica detectada en la versión anterior, y se introduce Vault, el sistema que gestiona de forma segura las claves y operaciones de pago de cada usuario.

v3.9.8 desplegada

Versión de estabilización tras la ronda de pruebas de videollamada y RAMP de la semana anterior, con ajustes sobre los hallazgos detectados en ese ciclo de pruebas.

v3.9.7 — videollamada y RAMP listo para pruebas

Se habilitan para pruebas dos capacidades mayores en simultáneo: videollamadas dentro del chat de la plataforma, y la primera versión del sistema RAMP para convertir dinero fiat en créditos de plataforma.

v3.5 live screenshare · v3.6.9 referidos al 1%

Los streams en vivo suman la opción de compartir pantalla, se ajusta el porcentaje del programa de referidos al 1%, y se agregan reacciones con emoji al chat en vivo, mejorando la interacción durante las transmisiones.

v3.4 — módulo TRADERS

Se lanza el módulo TRADERS, una nueva forma de interacción económica dentro de la plataforma orientada a usuarios con perfil de trading/inversión — parte de la exploración de distintos modelos de monetización previos a la consolidación en el modelo FIAT actual.

v3.2 — mercado P2P + nuevo contrato

Se lanza el mercado persona a persona (P2P) junto con un nuevo contrato inteligente que respalda las operaciones económicas de la plataforma, ampliando las opciones de intercambio directo entre usuarios.

ISYOU 3.0

Relanzamiento mayor de la plataforma bajo la identidad ISYOU 3.0, retomando y consolidando el rumbo de la aplicación tras el paréntesis dedicado al desarrollo del juego/mapa multijugador de finales de 2025.

ISYOU MAP 2.1 — multiplayer, mapa e IA completos

Cierra un ciclo de desarrollo intenso con la versión completa del componente de mapa/juego multijugador de la plataforma, incorporando mundo propio totalmente personalizado e inteligencia artificial integrada — una exploración de gamificación que informaría el rumbo posterior del producto.

Versión online multiplayer

El mapa/juego pasa de una experiencia local a una versión completamente online y multijugador, permitiendo que varios usuarios coincidan e interactúen en tiempo real dentro del mismo espacio.

Arranque del juego — mapa propio

Arranca el desarrollo de un componente de gamificación con mapa propio dentro de la plataforma, una línea de exploración de producto que el equipo desarrolló en paralelo a la app principal durante ese periodo.

v2.6 + campaña "race" · i18n de toda la plataforma

Se lanza una campaña temática ("race") para dinamizar la actividad de la comunidad, y se traduce la plataforma completa a múltiples idiomas — un paso clave para abrir la puerta a usuarios fuera del mercado hispanohablante.

AdminCRM — primer panel administrativo

Nace AdminCRM, el panel de administración interno que con el tiempo se convertiría en la herramienta central del equipo para monitorear salud del sistema, auditar saldos, gestionar usuarios y operar la plataforma día a día.

v2.2 y v2.5

Dos versiones consecutivas de estabilización y mejoras incrementales sobre la base de ISYOU V2, refinando el producto tras su relanzamiento reciente.

v2.1 (Ads) + "Referral Championship"

Se introduce el módulo de publicidad (Ads) como nueva vía de monetización, junto con "Referral Championship", una campaña competitiva de referidos diseñada para acelerar el crecimiento orgánico de la comunidad.

ISYOU V2

Relanzamiento completo de la plataforma bajo la identidad ISYOU V2, marcando el inicio de la era moderna del producto tras la etapa de Web3 Monetizer.

Arranque de la versión Web3 Monetizer

El proyecto pivota hacia "Web3 Monetizer", una versión centrada en la monetización de creadores mediante tecnología Web3 — un paso de transición entre la app social original y el modelo de creator economy que ISYOÜ consolidaría después.

Login con Google, WebAuthn y wallet API

Se incorpora el inicio de sesión con Google, una primera implementación de autenticación sin contraseña (WebAuthn), y las primeras pruebas de integración con una API de billetera — sentando las bases de identidad y wallet que la plataforma seguiría desarrollando.

Nuevo feed y autenticación

Se renueva el feed de contenido con un nuevo formato de publicaciones y se actualiza el sistema de autenticación de usuarios, dos piezas centrales de la experiencia de la app en su etapa temprana.

Arranque de v1.6.39

Arranca el desarrollo de la versión 1.6.39, tras varios meses de pausa desde el lanzamiento inicial en iOS — el punto de partida de una nueva etapa de desarrollo activo sobre la base social original.

V1.5.0 / V1.5.1 en iOS

Dos versiones de ajuste rápido desplegadas en iOS a solo días del lanzamiento inicial, corrigiendo comportamientos detectados en los primeros usuarios reales de la app.

V1.4.8 desplegada en iOS

Primera versión de la aplicación desplegada formalmente en iOS, un mes después del lanzamiento web inicial — el comienzo de la presencia de ISYOU como app móvil nativa.

V1 desplegada en Web

Un día después del primer commit, la primera versión de la plataforma ya está desplegada y accesible en la web — el arranque real de ISYOU como producto en producción.

Primer commit — base social de ISYOU

El primer commit del repositorio: una base de red social lista para operar. Es el punto de partida de todo lo que vendría después — casi dos años y decenas de versiones más tarde, la creator economy que es ISYOÜ hoy.