WODFuel
Elige el formato, añade los movimientos, obtén las calorías. Una app gratuita financiada con anuncios y con un nivel Pro en RevenueCat. Sin backend, sin cuenta.
- Producto propio
- 2025–2026
- iOS y Android
- Rol: todo
- Estado: publicada en Google Play
Una clase de CrossFit termina con una marca: rondas, repeticiones, un tiempo. Nunca termina con un número de calorías, y las pulseras lo adivinan mal porque un WOD mezcla barra, gimnásticos y máquinas en veinte minutos. WODFuel existe para ponerle a esa sesión un número defendible.
La primera versión salió en 2025 como prueba de la idea: una pantalla, cuatro formatos de entrenamiento, una estimación de calorías y un banner. La versión 2.0 es el producto: un rebranding, un historial de verdad, un nivel Pro y la observabilidad necesaria para llevarlo como negocio y no como proyecto de fin de semana.
Estimar calorías en entrenamiento por intervalos no es consultar una tabla. Un AMRAP se puntúa en repeticiones por ronda multiplicadas por las rondas hechas; un EMOM repite cada bloque cada minuto; un Tabata son veinte segundos de trabajo y diez de descanso. Cada formato necesita su propia aritmética antes de que entre la fisiología, y el usuario nunca debería tener que hacerla.
En lo económico, una utilidad de fitness tiene que ser gratuita para conseguir instalaciones, pero gratuita sin ingresos es un hobby. La app necesitaba un modelo en el que el nivel gratuito sea útil de verdad, el de pago sea claramente mejor y ninguno de los dos necesite servidor ni cuenta para funcionar.
Una app en React Native con un solo bucle: elegir el formato, meter la marca, añadir los movimientos, pulsar «Calcular». El resultado es un número grande, el resumen del formato y, para los usuarios Pro, qué movimientos han quemado más. Cada entrenamiento se puede guardar, consultar y repetir desde el historial.
La estimación corre en el dispositivo. Una tabla de valores MET y segundos por repetición para 58 movimientos alimenta un motor en TypeScript puro; las reglas del formato expanden las repeticiones y derivan la duración total; gana la mayor entre la estimación por movimiento y la de la sesión completa. Los usuarios gratuitos ven un banner y un intersticial tras cada cálculo; WODFuel Pro quita los anuncios y desbloquea historial ilimitado, estadísticas semanales, rachas y el desglose.
Todo. Producto, el modelo de calorías, marca e iconos, la app en React Native, la integración de anuncios, el paywall y los entitlements de RevenueCat, las builds de EAS y las actualizaciones OTA, y la puesta en marcha de la observabilidad. La 2.0 supuso además migrar el código a Expo SDK 57 y Bun sin perder los perfiles de los usuarios existentes.
Decisiones clave, y por qué:
- Sin backend, otra vez. Perfil e historial viven en AsyncStorage. Las calorías son deterministas dadas las entradas, así que no hay nada que sincronizar ni nada que pagar por usuario. Las compras son lo único que necesita un servidor, y ese servidor es RevenueCat.
- El motor es una librería, la app es un cliente. El módulo de calorías no tiene React: tipos, una tabla MET y una función de estimación. El modelo del formulario, la validación y las reglas de cada formato están en un segundo módulo puro. Las pantallas solo conectan estado con componentes, lo que mantiene la matemática testeable y la interfaz reemplazable.
- Dos niveles, un solo entitlement. Cada puerta de la app pregunta un único booleano a un único contexto. Los anuncios nunca se montan cuando es verdadero, el paywall está a una llamada desde cualquier sitio y un flag fuerza Pro para las capturas. Los límites son constantes, no condiciones repartidas por las pantallas.
- Medido antes de ser público. EAS Observe envuelve la raíz y cada pantalla se marca como interactiva, EAS Insights cuenta arranques y EAS Update publica correcciones sin revisión de la tienda. Un producto de una sola persona no puede permitirse enterarse de un crash por una reseña.
- La aritmética del AMRAP sin hoja de cálculo. Las repeticiones se introducen por ronda, pero la marca son rondas más una ronda parcial. El motor multiplica cada movimiento por las rondas completadas y reparte las repeticiones extra entre los movimientos en proporción a su peso en una ronda, así que «4 rondas + 15 reps» da a cada ejercicio una cuenta justa.
- Anuncios que nunca tocan a quien paga. El banner espera a la comprobación del entitlement antes de renderizar y se pliega hasta que hay un anuncio cargado, así que no hay hueco gris ni destello de anuncio para Pro. El intersticial solo se crea para usuarios gratuitos, se precarga, se limita a uno cada tres minutos y se espera a que se cierre antes de mostrar el resultado.
- Cuatro versiones de SDK de un salto. Pasar del SDK 53 al 57 supuso un Reanimated nuevo, un React nuevo, reglas de lint que prohíben cambiar estado dentro de efectos y un proyecto nativo obsoleto. Regenerar las carpetas nativas y tratar cada error de lint como real fue más rápido que parchear alrededor.
Una 2.0 terminada: una app rediseñada con historial persistente, una separación gratuito/Pro que funciona, anuncios que respetan el entitlement y un panel que muestra tiempos de arranque, rutas y errores desde la primera build. Lo que queda está del lado de las tiendas: la oferta de RevenueCat y las unidades de anuncios de iOS.
Para ZubiLabs cubre el hueco entre los otros dos casos: un producto con un modelo de ingresos que no es ni pago único ni plataforma con backend.
- Guarda lo que el usuario ha hecho. La versión 1 calculaba y olvidaba. Persistir el entrenamiento convirtió una calculadora en un producto e hizo posible un nivel Pro.
- Monetiza la fricción, no la función. Anuncios en el resultado y un historial corto son motivo suficiente para pasar a Pro; esconder el número de calorías habría dejado inútil la app gratuita.
- Rebranding y migración, juntos. Hacer la subida de SDK en la misma pasada que el rediseño supuso tocar cada archivo una vez, con las convenciones nuevas, en lugar de dos.