Mantenimiento de apps Android heredadas, con backlog y releases controladas

Entro en una app creada por otro equipo, hago reproducible la base y convierto errores y evolutivos en un plan de entregas verificable.

  • Puedo tomar una app creada por otro proveedor.
  • Diagnóstico inicial antes de prometer fechas o alcance.
  • Backlog priorizado, QA, publicación y notas de versión.

Experiencia con Android de campo y sistemas existentes

En +DERA para MaderaPlus diagnostiqué una app Android Java con sincronización offline, backend y web legacy. El caso documenta el diagnóstico; Kotlin/KMP son recomendaciones de evolución.

Revisar el caso y el alcance entregado

Staging de diagnóstico con datos anonimizados.

203 llamadas backend/API documentadas.

115 incidencias revisadas y 23 acciones priorizadas.

Cuéntame el proyecto

Cuéntame qué debe quedar resuelto.

Objetivo, estado actual y fecha son suficientes para valorar el encaje y proponerte una entrada concreta.

Respuesta humana habitual en un día laborable. Sin alta automática en listas comerciales.

Solicitud de servicio para empresas, agencias y consultoras; no es una oferta de empleo.

¿Desde qué contexto escribes?
Unas líneas sobre el proyecto son suficientes.
Añadir más informaciónEmpresa, presupuesto y plazo, si ya los conoces.
Datos utilizados y cómo retirar el consentimiento

Acepto que Google Ads mida esta consulta mediante el identificador del envío, la fecha, mi email normalizado y transformado con SHA-256 y, si existe y sigue vigente, el identificador de clic. Es opcional, no activa remarketing y puedo retirarlo usando el contacto indicado en la política de privacidad.

Verificación antispam

Se cargará al empezar a completar el formulario.

Respuesta habitual en un día laborable.

Casos habituales

Para empezar necesito acceso al repositorio, entorno reproducible, contexto de publicación y una persona que pueda validar.

01

Errores recurrentes

Bugs, regresiones o comportamientos frágiles en flujos importantes.

02

Evolutivos

Nuevas funcionalidades, cambios de API, mejoras de UX o adaptación a producto.

03

Release y publicación

Preparación de versión, revisión de riesgos y acompañamiento hasta producción.

Cómo se ordena

La continuidad necesita un marco simple para no convertir todo en emergencia.

01

Diagnóstico inicial

Build reproducible, estado de la app, dependencias, deuda visible, accesos de publicación y flujos críticos.

02

Prioridades

Lista de tareas, responsable de validación y criterios para separar urgencia de mejora.

03

Seguimiento

Entregas pequeñas, pruebas, notas de cambio y criterios de release y rollback claros.

Preguntas habituales

Lo mínimo que conviene aclarar antes de abrir una colaboración.

¿Puedes mantener una app que no has creado?+

Sí, si hay acceso a repositorio, entorno, contexto mínimo y responsable para validar.

¿Trabajas por bolsa o proyecto?+

Puede ser bolsa si hay continuidad o proyecto cerrado si hay un release/evolutivo concreto.

¿También revisas publicación?+

Sí. Puedo ayudar con checklist, cierre de riesgos, pruebas y acompañamiento de release.

Seguir orientando

Si todavía estás comparando opciones, estas rutas ayudan a decidir.