ISYOÜ
en movimiento

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.