No soy un ticket de soporte.
Soy la próxima pieza de
unrespiro.
He auditado la app, encontrado fricciones críticas y programado soluciones visuales.
He intentado contactar con vosotros por los canales tradicionales. Correos, mensajes, DMs... Pero un mensaje más se pierde en el ruido de una startup.
Me di cuenta de que para llamar vuestra atención no servía con llamar a la puerta. Tenía que construir la mía propia.
Esta web es la prueba. No busco un trabajo convencional; busco un proyecto en el que creo. Y estoy dispuesto a demostrarlo con hechos, código y diseño antes de nuestro primer 'Hola'.
Mi breve análisis:
Identificación quirúrgica de puntos de fricción críticos en la experiencia actual de unrespiro. Haz clic en un área para ver el análisis detallado.
El contexto:
Fallo en suscripciones
Cuando un usuario cancela una prueba de 3 días directamente a través de Apple y obtiene un reembolso por un cobro no deseado, la aplicación sigue concediendo acceso total.
El backend asume que la suscripción sigue activa basándose en un estado local obsoleto, perdiendo la trazabilidad real del ciclo de vida de la compra.
App Store Server Notifications (v2): Es imperativo configurar webhooks de notificaciones del servidor de Apple en el backend de unrespiro. Cuando Apple procesa un reembolso (REFUND) o una revocación (REVOKE), emite una alerta en tiempo real. El servidor debe capturar este evento y actualizar de forma inmediata la base de datos de usuario para revocar el acceso Premium.
Restauración de Estado (Restore Purchases): Asegurar que al abrir la app o verificar el token de sesión, se consulte la API de Apple (App Store Server API) para validar el estado actual del original_transaction_id en lugar de confiar ciegamente en cachés locales del dispositivo.
*(Nota: todo esto se ha hecho con ejemplos míos, no sé cómo está programado ni definida cada variable en producción, intento que el concepto lógico se entienda correctamente :).*
El contexto:
Fallo de Rutina + respiros
Una regla de negocio rota: las rutinas de bloqueo estricto (diseñadas para prohibir el acceso a ciertas apps en franjas horarias críticas) pierden su validez si el usuario activa la función de "respiros".
Esperar un contador de segundos no debería invalidar una restricción horaria impuesta por una rutina.
Jerarquía de Estados (State Machine): A nivel lógico, hay que redefinir la prioridad de los módulos. La "Regla de Bloqueo por Rutina" debe actuar como una capa superior (bloqueo absoluto).
Si una app se encuentra dentro de un horario de restricción estricta de rutina, el motor de control debe deshabilitar o ignorar la condición de bypass del "Respiro". La condición de horario bloqueado debe evaluar su prioridad antes de permitir que el temporizador del respiro descuente segundos.
*(Nota: todo esto se ha hecho con ejemplos míos, no sé cómo está programado ni definida cada variable en producción, intento que el concepto lógico se entienda correctamente :).*
El contexto:
Inicio y cierre de sesión
Un fallo crítico de persistencia de usuario. Al cerrar sesión y volver a entrar tras iniciar una prueba gratuita, el sistema rompe el vínculo con la transacción activa, forzando al usuario a empezar desde cero e intentando cobrarle de nuevo.
*Nota: Este fallo se detectó en las primeras pruebas de auditoría, sujeto a comprobación en la build actual.
Persistencia Backend e Identidad: Desacoplar el estado de la suscripción del almacenamiento puramente local del dispositivo. El identificador de usuario (user_id) en la base de datos debe estar fuertemente vinculado al identificador de la transacción de la tienda (original_transaction_id).
Flujo de Restauración Automática: Al realizar un inicio de sesión (Sign In), el sistema de autenticación debe disparar de forma transparente una rutina de verificación con la pasarela de pagos o la tienda de aplicaciones para comprobar si ese perfil ya cuenta con una prueba o compra histórica asociada, aplicando un Restore Purchases nativo en background.
*(Nota: todo esto se ha hecho con ejemplos míos, no sé cómo está programado ni definida cada variable en producción, intento que el concepto lógico se entienda correctamente :).*
Autodidacta
Guillermo P.
Soporte Técnico & Mantenimiento
Sigo a jaquebue desde los tiempos de Club Futuros Millonarios y he estado ahí desde que unrespiro era solo la primera idea en un tiktok. Este proyecto conecta conmigo a un nivel personal brutal.
Mi base es técnica, pero mi verdadero motor es ser 100% autodidacta. Esa obsesión por investigar y aprender me permite moverme con agilidad en cualquier terreno: desde auditar la arquitectura de una app y cazar fricciones, hasta obsesionarme con el soporte técnico y el mantenimiento diario de la aplicación. No busco un título elegante; busco aportar un valor tangible e inmediato.
Comparto firmemente esa filosofía de que las cosas no se esperan, se construyen. Esa misma disciplina mental de esfuerzo innegociable es la que aplico entrenando cada día, y es exactamente la energía que quiero inyectar en este equipo.
Esta web no es un currículum estándar, es una demostración de intenciones. Mi único objetivo es que Jacobo lea esto y me dé la oportunidad de cruzar un simple 'Hola'. Quiero demostrar con hechos que tengo el hambre y la capacidad para multiplicar en unrespiro.
"Necesito equipo: si te enseño lo que sé, en un futuro podremos trabajar juntos... ¿Qué c*ño quieres aprender de mí?"
Eso escribiste el 5 de septiembre en tu primera newsletter. Yo ya he aprendido. Ahora me toca sumar.
o contesta mis correos/Dm si quieres....
