Mantenimiento de aplicaciones y páginas web
¿Tienes una página o sistema que necesita correcciones y nadie lo mantiene?
Revisamos aplicaciones, páginas y automatizaciones existentes para conocer su estado, identificar riesgos y proponer una forma ordenada de corregirlas y darles continuidad.
Antes de aceptar correcciones o mantenimiento, necesitamos comprobar el código, accesos, dependencias, base de datos y entorno donde funciona la aplicación.
Señales de que una aplicación necesita atención
Presenta errores frecuentes
Algunas funciones dejaron de trabajar correctamente o los usuarios encuentran fallas que interrumpen sus actividades.
La persona que la desarrolló ya no está disponible
La empresa conserva la aplicación, pero no cuenta con alguien que conozca el código, las cuentas o la forma de publicarla.
Lleva mucho tiempo sin actualizarse
Las dependencias, el entorno o los servicios utilizados pueden estar desactualizados y generar riesgos de seguridad o compatibilidad.
No se conocen todos los accesos
El dominio, alojamiento, repositorio, base de datos o servicios externos están distribuidos entre distintas cuentas.
No existe documentación
No hay instrucciones para instalar, ejecutar, publicar o respaldar la aplicación.
Se necesitan cambios, pero se desconoce su impacto
Una función aparentemente sencilla puede depender de código, datos o servicios que primero deben revisarse.
No corregimos código sin entender primero su estado
Trabajar sobre una aplicación desconocida sin revisar su estructura puede provocar nuevas fallas, pérdida de información o costos difíciles de controlar.
Por eso, el primer paso es una revisión técnica. Esta revisión permite determinar:
- Si el código disponible corresponde a la versión publicada.
- Si la aplicación puede ejecutarse.
- Qué tecnologías utiliza.
- Qué dependencias necesita.
- Dónde se almacena la información.
- Qué accesos están disponibles.
- Qué errores son visibles.
- Qué riesgos existen.
- Si es viable corregirla.
- Qué trabajo debe realizarse primero.
La revisión inicial tiene un precio de referencia desde $6,500 MXN. Es un servicio separado y no garantiza que todas las aplicaciones puedan recuperarse o mantenerse.
¿Qué necesitamos revisar?
Código y repositorio
- Ubicación del código.
- Historial disponible.
- Rama utilizada en producción.
- Archivos faltantes.
- Instrucciones de instalación.
- Estado general de la estructura.
Tecnología y dependencias
- Lenguajes y herramientas utilizadas.
- Versiones necesarias.
- Dependencias antiguas o vulnerables.
- Compatibilidad con el entorno actual.
- Servicios externos.
Configuración y accesos
- Variables de configuración.
- Claves y secretos.
- Cuentas propietarias.
- Dominio.
- Alojamiento.
- Servicios de publicación.
No mostramos ni copiamos secretos en reportes o capturas.
Base de datos
- Tecnología utilizada.
- Acceso disponible.
- Estructura general.
- Respaldos existentes.
- Migraciones pendientes.
- Riesgos visibles para la información.
Funcionamiento
- Posibilidad de ejecutar la aplicación.
- Errores reproducibles.
- Funciones principales.
- Registros de errores.
- Diferencias entre desarrollo y producción.
- Problemas reportados por usuarios.
Documentación
- Instalación.
- Publicación.
- Accesos.
- Respaldos.
- Funciones principales.
- Proveedores.
- Pendientes conocidos.
¿Qué recibes después de la revisión?
Dependiendo del alcance, la entrega puede incluir:
- Inventario técnico.
- Estado general de la aplicación.
- Lista priorizada de errores.
- Riesgos visibles.
- Dependencias que requieren atención.
- Accesos o información faltante.
- Recomendaciones inmediatas.
- Alternativas disponibles.
- Estimación de estabilización.
- Propuesta de mantenimiento.
- Recomendación de continuar, migrar, reconstruir o detener.
Si mantener la aplicación no es razonable, lo informamos antes de comenzar una inversión mayor.
¿Qué puede suceder después del diagnóstico?
Opción 01
Corregir primero lo que impide operar
Proyecto inicial para atender errores prioritarios, recuperar un entorno funcional, organizar accesos y reducir los riesgos más inmediatos.
Estabilización — puede incluir:
- Corrección de errores acordados.
- Actualización controlada de dependencias.
- Ajustes de configuración.
- Recuperación del proceso de publicación.
- Pruebas de funciones principales.
- Documentación básica.
Opción 02
Atender una corrección o cambio definido
Trabajo con alcance concreto para corregir un problema o realizar un ajuste previamente analizado.
Mantenimiento puntual — puede incluir:
- Corrección específica.
- Cambio menor.
- Pruebas relacionadas.
- Publicación acordada.
- Registro de lo realizado.
Opción 03
Mantener seguimiento después de estabilizar
Servicio mensual con horas y actividades definidas para correcciones, cambios menores, revisión básica y documentación.
Continuidad mensual — puede incluir según el plan:
- Revisión periódica.
- Corrección de errores.
- Cambios menores.
- Actualización controlada.
- Monitoreo básico acordado.
- Registro de actividades.
- Informe.
- Reunión de seguimiento.
La continuidad mensual no es soporte ilimitado, desarrollo constante ni atención 24/7.
No todos los cambios tienen la misma prioridad
Bloqueante
Una función principal no puede utilizarse y afecta directamente la operación acordada.
Importante
La aplicación funciona, pero existe un error relevante, riesgo o afectación para varios usuarios.
Corrección normal
Problema localizado que permite continuar trabajando mediante una alternativa temporal.
Mejora
Cambio solicitado para facilitar el uso o agregar comportamiento que no formaba parte de un defecto.
La prioridad final se acuerda según el impacto, alcance y capacidad disponible. Una mejora no se considera automáticamente un error de garantía.
¿Cómo tomamos el control de una aplicación?
Reunimos información
Solicitamos el código, accesos, documentación, contactos, errores conocidos y datos del entorno.
Protegemos el estado actual
Confirmamos respaldos y evitamos realizar cambios directos sin conocer primero cómo funciona la aplicación.
Ejecutamos y revisamos
Intentamos reproducir el entorno, identificamos tecnologías, dependencias, errores y riesgos.
Presentamos hallazgos
Explicamos qué encontramos, qué información falta y qué alternativas existen.
Definimos la estabilización
Priorizamos trabajos, entregables, tiempos, responsabilidades y costos.
Corregimos y probamos
Realizamos únicamente los cambios autorizados y comprobamos las funciones relacionadas.
Documentamos
Registramos lo realizado, accesos importantes, publicación y pendientes conocidos.
Definimos continuidad
Si la aplicación es viable, proponemos mantenimiento con horas, actividades y límites definidos.
La aplicación no debe depender de una sola cuenta personal
Durante la revisión buscamos identificar quién controla:
- Repositorio.
- Dominio.
- Alojamiento.
- Base de datos.
- Servicio de correo.
- Almacenamiento.
- Herramientas externas.
- Certificados.
- Analítica.
- Copias de seguridad.
Principios:
- Las cuentas productivas deben quedar bajo control del cliente cuando sea posible.
- Los accesos deben entregarse mediante medios seguros.
- Las contraseñas no deben escribirse en documentos públicos.
- Los secretos no deben guardarse dentro del código.
- Los respaldos deben verificarse antes de cambios importantes.
- Los accesos que ya no se necesitan deben revocarse.
Límites del servicio
El mantenimiento inicial no incluye automáticamente:
- Disponibilidad o atención 24/7.
- Monitoreo continuo.
- Infraestructura crítica.
- Recuperación forense.
- Reconstrucción completa.
- Migraciones mayores.
- Rediseño total.
- Nuevas funciones grandes.
- Cambios ilimitados.
- Soporte a computadoras y usuarios.
- Licencias, alojamiento o servicios externos.
- Corrección de problemas sin acceso al código o entorno.
- Sistemas médicos, bancarios o financieros críticos.
- Garantía sobre código que no ha sido revisado.
Cada trabajo adicional se analiza, documenta y cotiza antes de implementarse.
Ejemplos de situaciones que podemos evaluar
Página que dejó de publicar cambios
Situación: existe código disponible, pero ya no se conoce el proceso para actualizar el sitio. Revisión: repositorio, herramientas de construcción, alojamiento, configuración y proceso de publicación.
Aplicación con errores después de una actualización
Situación: una dependencia o servicio cambió y una función dejó de trabajar. Revisión: versiones, registros de error, compatibilidad, configuración y funciones afectadas.
Sistema sin documentación
Situación: la aplicación funciona, pero solamente una persona conoce los accesos y el proceso de mantenimiento. Revisión: cuentas, repositorio, entorno, base de datos, publicación, respaldos y documentación mínima.
Aplicación que necesita nuevas funciones
Situación: la empresa quiere ampliar el sistema, pero desconoce si la estructura actual puede soportarlo. Revisión: código, arquitectura, datos, dependencias, riesgos y esfuerzo necesario antes de cotizar las nuevas funciones.
Ejemplos ilustrativos con información ficticia. No representan resultados de clientes reales.
Preguntas frecuentes
¿Pueden corregir solamente un error?
Primero necesitamos revisar la aplicación y reproducir el problema. Si el entorno está disponible y el error tiene alcance claro, podemos cotizar una corrección puntual.
¿Por qué deben revisar el código antes de cotizar?
El mismo error visible puede tener causas diferentes. Sin revisar código, dependencias, configuración y datos, no es responsable prometer tiempo o costo fijo.
¿Qué pasa si no tenemos el código fuente?
Las posibilidades de mantenimiento son muy limitadas. Podemos revisar los accesos y el entorno disponible, pero no garantizamos que sea posible corregir la aplicación.
¿Pueden trabajar directamente en producción?
No es lo recomendable. Primero buscamos contar con respaldo y un entorno seguro para reproducir y probar los cambios antes de publicarlos.
¿Incluye alojamiento y dominio?
No. Estos servicios se pagan por separado. Podemos ayudar a identificar las cuentas y coordinar cambios autorizados.
¿Pueden agregar nuevas funciones?
Sí, después de revisar la aplicación. Las funciones nuevas se consideran desarrollo y se cotizan por separado del mantenimiento correctivo.
¿Ofrecen atención 24/7?
No. La atención se realiza dentro del horario, capacidad y tiempos establecidos en la propuesta.
¿Garantizan que podrán recuperar cualquier aplicación?
No. La viabilidad depende del código, accesos, datos, dependencias, documentación y estado general. La revisión inicial permite decidir si conviene continuar.
¿El mantenimiento mensual incluye cambios ilimitados?
No. El plan debe definir horas, actividades, prioridades y exclusiones. Los trabajos adicionales requieren autorización.
¿Necesitas recuperar el control de una aplicación?
Cuéntanos qué sistema utilizas, qué problema presenta y qué accesos o código tienes disponibles. Con esa información podremos definir el primer paso de revisión.
Solicitar revisión de una aplicaciónNo realizamos cambios en producción sin conocer primero el entorno y los riesgos.