Después de tres años escalando una app con millones de usuarios en ManoMano, recibí una oferta interesante: unirme a Macadam, una startup de 15 personas, como Lead Mobile Developer.
El pitch era directo: “Necesitamos a un experto que rescate nuestra app móvil”.
Acepté el desafío. Y durante el siguiente año y medio, transformé una app con código legacy crítico en una plataforma estable y escalable.
Esta es esa historia.
El Concepto: Walk-to-Earn
Macadam tiene un concepto simple pero adictivo: te paga por caminar.
No es una app de fitness. Es una plataforma de gamificación con múltiples modelos de monetización:
Revenue Streams:
- Anuncios integrados
- Promociones de juegos
- Challenges patrocinados por marcas
- Cashback en compras
El Gancho: Un mapa estilo Pokémon GO donde recolectas monedas virtuales mientras caminas por tu ciudad.
El modelo funcionaba. Los usuarios estaban enganchados. El problema no era el concepto.
El problema era la app.
El Estado Crítico al Llegar
Mi primer día revisando el código fue revelador.
Spaghetti code en su máxima expresión:
- Lógica de negocio mezclada con UI
- Componentes con 1000+ líneas
- Sin separación de concerns
- Patrones inconsistentes
Infraestructura inexistente:
- ❌ No CI/CD
- ❌ No tests automatizados
- ❌ TypeScript configurado pero no funcionando correctamente
- ❌ Sin linting funcional
- ❌ Sin procesos de release establecidos
El resultado:
- Bugs frecuentes en producción
- Crashes constantes
- Features frágiles que rompían otras features
- Imposible iterar rápido
Para una startup que necesitaba moverse rápido, esto era un cuello de botella crítico.
Mi Rol: El Experto Solitario
Me contrataron específicamente como el experto que resolvería esto.
La realidad del equipo:
- 15 empleados totales
- 3 personas en tech (incluyéndome)
- Mis compañeros: Ocupados 100% con features de producto
Básicamente: yo era el equipo mobile.
Esto significaba:
- Decisiones de arquitectura: mías
- Implementación de infraestructura: mía
- Rescate del código legacy: mío
- Nuevas features críticas: mías
Sin equipo de soporte. Sin segundo developer mobile para rebotar ideas. Sin red de seguridad.
Era aterrador. Y emocionante.
La Transformación: De Caos a Orden
Fase 1: Foundations (Meses 1-3)
No puedes construir sobre arena. Primero necesitaba foundations sólidas.
Prioridad #1: CI/CD
- Pipeline completo de GitHub Actions
- Tests automáticos en cada PR
- Builds automáticas
- Deploy automático a TestFlight y Google Play Beta
Prioridad #2: TypeScript Funcional
- Arreglar configuración de TypeScript
- Tipar componentes críticos gradualmente
- Enforcement en CI
Prioridad #3: Testing
- Setup de Jest y React Native Testing Library
- Tests de componentes críticos
- Tests de lógica de negocio
- Coverage incremental
El objetivo: No más sorpresas en producción.
Fase 2: Estabilización (Meses 4-8)
Con la infraestructura en su lugar, el siguiente paso era estabilizar.
Reducción de Crashes:
- Identificación de crash patterns en analytics
- Fixes sistemáticos
- Error boundaries en puntos críticos
- Better error handling
Refactoring Gradual:
- No podía reescribir todo (startup, necesitamos features)
- Refactoring incremental de componentes críticos
- Separación de concerns donde más importaba
- Documentación de patrones a seguir
Resultado:
- ✅ Crashes: Prácticamente eliminados
- ✅ Bugs en producción: Reducción drástica
- ✅ Confianza del equipo: Restaurada
Fase 3: El Mapa (Meses 9-15)
Con la app estable, pude enfocarme en la feature más crítica: el mapa.
El Mapa: Gamificación en el Mundo Real
El mapa de Macadam era el corazón de la app. Y era complejo.
Componente 1: Calles de la Ciudad
Integración con mapas reales:
- Renderizado de calles caminables
- Optimización de performance (muchos paths)
- Actualización en tiempo real conforme caminas
Componente 2: Monedas Aleatorias
Sistema de puntos generados dinámicamente:
Lógica:
- Puntos aparecen aleatoriamente en calles cercanas
- Usuario camina hacia ellos
- Al recoger una moneda, gana puntos
- Degradación de valor: El valor de una moneda disminuye con cada recogida por el usuario
¿Por qué degradación? Para incentivar exploración. No puedes farmear el mismo punto infinitamente.
Desafíos técnicos:
- Generación de puntos client-side vs server-side
- Validación de ubicación (anti-spoofing)
- Performance con muchos puntos en el mapa
- Sincronización de estado
Componente 3: Spots (La Feature Estrella)
Los Spots eran puntos de interés estáticos permanentes en el mapa.
Funcionamiento:
- Aparecen en ubicaciones fijas (monumentos, plazas, etc.)
- Usuario se acerca al spot (radio de ~50m)
- Se activa una slot machine
- Spin aleatorio con premios variables
- Sistema de tracking:
- Quién ganó
- Cuánto ganó
- Cuándo lo ganó
- Historial completo
Complejidad técnica:
- Geolocalización precisa
- Animación fluida de la slot machine
- Backend sync para premios
- Prevención de exploits
- UI engaging y responsive
Esta feature se convirtió en la más adictiva de la app. Los usuarios volvían diariamente para visitar sus spots favoritos.
Trabajando Solo: Ventajas y Desafíos
Ser el único mobile developer tenía sus pros y contras.
Ventajas:
- ✅ Autonomía total: Mis decisiones, mi arquitectura
- ✅ Velocidad de decisión: Sin debates infinitos
- ✅ Ownership completo: Responsable de todo, para bien y para mal
Desafíos:
- ❌ Nadie con quien rebotar ideas: Las decisiones son solitarias
- ❌ No hay backup: Si me bloqueo, no hay quien tome el relevo
- ❌ Burnout risk: Todo pasa por ti
La clave: Priorización implacable.
No podía hacer todo. Tenía que elegir:
- ¿Calidad técnica o nueva feature?
- ¿Refactor o mantener legacy?
- ¿Tests o velocidad?
Aprendí que en una startup, el balance es todo. Ni purismo técnico ni cowboy coding. El punto medio estratégico.
Resultados Medibles
Después de año y medio:
Métricas Técnicas
- ✅ Infraestructura: CI/CD completo, tests, TypeScript funcional
- ✅ Estabilidad: App infinitamente más estable
- ✅ Crashes: Prácticamente eliminados
- ✅ Bugs trazables: Sistema de logging y error tracking funcional
- ✅ Código: Mucho más mantenible y escalable
Métricas de Negocio
- ✅ App rating: Mejora significativa
- ✅ User retention: Aumento claro
- ✅ Engagement: Features como el mapa con spots aumentaron el daily active users
Mi Impacto
Cuando me fui este año:
- La app era production-ready a largo plazo
- El próximo developer podía iterar sin miedo
- Las foundations estaban sólidas
- El mapa funcionaba perfectamente
Dejé la app en un estado donde la startup podía escalar técnicamente.
Lecciones Aprendidas
1. Las Startups Pequeñas Son Diferentes
Muy diferentes de empresas grandes como ManoMano:
En ManoMano:
- Procesos establecidos
- Equipo grande
- Código legacy pero estructurado
- Tiempo para hacer las cosas bien
En Macadam:
- Sin procesos (hay que crearlos)
- Tú eres el equipo
- Código legacy caótico
- Velocidad crítica
Ambos tienen valor. Ambos enseñan cosas diferentes.
2. Ser “El Experto” Es Responsabilidad
Cuando eres el experto, la startup confía en ti completamente.
Esa confianza es:
- Empoderadora: Autonomía total
- Aterradora: Si fallas, el proyecto falla
- Educativa: Aprendes a tomar decisiones bajo presión
3. Balance > Purismo
En una startup no puedes ser purista técnico.
A veces necesitas:
- Escribir código quick-and-dirty para validar
- Posponer refactors para enviar features
- Aceptar deuda técnica estratégica
La clave es saber cuándo y cuánta.
4. La Infraestructura Es Inversión
CI/CD, tests, TypeScript: todo esto lleva tiempo inicial.
Pero se paga solo en semanas:
- Menos bugs
- Más confianza
- Iteración más rápida
- Menos fires en producción
En startups que ignoran esto, el caos es inevitable.
5. Features Importan, Pero Estabilidad Más
Macadam tenía features interesantes. Pero sin estabilidad, los usuarios se iban.
Primera regla: Hazlo estable. Segunda regla: Hazlo rápido. Tercera regla: Añade features.
En ese orden.
Reflexiones Finales
Macadam fue mi experiencia más intensa en mobile development.
No por la complejidad técnica (ManoMano era más complejo).
Sino por la responsabilidad total.
Era el experto. Era el equipo. Era el que tenía que transformar una app crítica en una plataforma estable. Solo.
Y lo logré.
Cuando me fui, dejé una app que:
- No crashea
- Tiene infraestructura sólida
- Puede escalar
- Tiene features que enganchan
Pero más allá de la app, dejé procesos y foundations que permiten al próximo developer continuar sin empezar de cero.
Eso es legacy del bueno.
¿Qué Sigue?
Después de:
- Aprender las bases en SiVasDescalzo
- Escalar a millones de usuarios en ManoMano
- Rescatar una startup como experto en Macadam
La pregunta es: ¿qué viene después?
La respuesta: Proyectos donde pueda aplicar todo esto. Consultoría. Freelancing. Startups que necesitan expertise mobile.
Porque ahora sé que puedo:
- Entrar en una codebase caótica y traer orden
- Construir features complejas que escalan
- Trabajar solo o en equipo
- Balancear velocidad y calidad
- Ser el experto cuando se necesita
Eso es lo que los años de SiVasDescalzo, ManoMano y Macadam me enseñaron.
¿Buscas el próximo nivel en tu carrera mobile? Acepta el proyecto difícil. La startup caótica. El rol donde eres el experto. Ahí es donde el crecimiento real sucede.