Cómo elegir una empresa de remediación o un contratista

Un SaaS roto creado con IA rara vez necesita «un desarrollador» en abstracto. Necesita a alguien que descubra qué hace realmente el prototipo, decida qué partes se pueden conservar, repare lo que no es seguro y demuestre que el resultado puede funcionar en producción. Un contratista full stack sénior puede hacer todo eso. Una empresa de remediación también. La diferencia útil no está entre talento y burocracia. Está en cómo absorbe cada opción la incertidumbre y quién se hace cargo de los huecos entre el diagnóstico, la reparación, la revisión de seguridad y el lanzamiento.

Para un defecto pequeño y bien entendido, con un conjunto de pruebas fiable, suelo preferir a un solo ingeniero sénior responsable. Para un código con límites poco claros, autenticación rota, secretos expuestos, reglas de datos incoherentes o un despliegue fallido, prefiero una empresa que presupueste y asuma la recuperación completa. Los fundadores salen perjudicados cuando eligen una etiqueta de contratación antes de saber qué clase de problema tienen.

Cómo cambia la contratación correcta según la certeza del alcance

Tener certeza sobre el alcance significa que puedes nombrar el comportamiento roto, los sistemas a los que afecta y las pruebas que demostrarán la reparación. Si puedes hacerlo antes de empezar, un contratista puede calcular el trabajo con sensatez. Si cada respuesta destapa otro subsistema, una empresa de remediación tiene más posibilidades de contener el trabajo de descubrimiento sin convertir cada sorpresa en una negociación nueva.

Distingo entre un defecto acotado y una aplicación en problemas. Un defecto acotado puede ser un webhook que repite intentos de forma incorrecta, un estado de facturación que no se actualiza o un despliegue que falla porque falta una variable de entorno. Los archivos relevantes, el comportamiento esperado y el fallo están a la vista. Una aplicación en problemas se comporta de otro modo: el inicio de sesión funciona para el fundador pero no para los usuarios invitados, las políticas de la base de datos contradicen las comprobaciones de la API, las acciones privilegiadas viven en el navegador y nadie sabe qué secretos llegaron a un repositorio público. Cada síntoma puede cruzar varios límites.

Pide a todos los candidatos que completen un mapa de alcance de una página antes de hablar de un precio final:

La columna de responsable importa. «El fundador debe aclararlo» es razonable para la intención del producto. No lo es para descubrir si un endpoint permite que un cliente lea el registro de otro. Quien se haga cargo del código debe asumir el descubrimiento técnico.

Los contratistas suelen presupuestar el diagnóstico por separado porque venden tiempo. Es justo si el fundador acepta que el alcance y el precio cambiarán después del diagnóstico. Las empresas suelen incluir una auditoría en la propuesta del proyecto y pueden repartir el trabajo entre especialistas en ingeniería, seguridad y despliegue. No des por supuesto ninguno de los dos modelos por la etiqueta. Incluye el mapa de alcance en la solicitud y comprueba quién responde de forma directa.

También existe un caso intermedio: contratar a un profesional sénior para un diagnóstico pagado y decidir después quién repara. Solo funciona si el diagnóstico produce pruebas transferibles, no una llamada llena de impresiones. Exige un inventario de dependencias, un esquema del flujo de datos, una lista priorizada de defectos, una lista de riesgos de lanzamiento y pruebas de aceptación. Si el siguiente proveedor no puede actuar con el informe, has comprado una opinión en vez de certeza sobre el alcance.

Un contratista sénior aporta criterio con poca distancia

Un buen contratista full stack sénior da al fundador acceso directo a la persona que lee el código y toma las decisiones. Ese canal corto de comunicación resulta útil cuando la intención del producto vive casi por completo en la cabeza del fundador. El ingeniero puede preguntar por qué existe un flujo de trabajo, inspeccionar la implementación y cambiar de rumbo sin pasar el contexto por un gestor de cuenta.

Este modelo funciona mejor cuando la aplicación usa principalmente una pila técnica, la lista de defectos ya es fiable y el contratista ha lanzado ese mismo tipo de sistema. «Full stack» es demasiado amplio para demostrar que alguien encaja. Una persona puede ser excelente con interfaces y API corrientes, pero floja con autorización en bases de datos, máquinas de estados de pagos u operaciones de producción. Pide pruebas que coincidan con la parte arriesgada de tu aplicación.

Un contratista en solitario también tiene un límite de capacidad estricto. El diagnóstico, la reparación del código, el análisis de amenazas, el diseño de migraciones, la escritura de pruebas, el despliegue y la documentación compiten por las mismas horas. Eso no convierte al contratista en descuidado. Significa que cada revisión adicional quita tiempo de implementación salvo que el encargo incluya a otro revisor. Cuando la misma persona escribe una solución y la aprueba, algunas suposiciones sutiles pueden sobrevivir porque nadie aborda el código desde otro ángulo.

Comprueba cuatro aspectos antes de elegir esta vía:

• El contratista puede decir qué partes quedan fuera de su experiencia y quién las revisará.
• Su calendario incluye diagnóstico, implementación, pruebas, despliegue y observación posterior al lanzamiento.
• El repositorio, las cuentas de nube y las cuentas de proveedores permanecen bajo tu control.
• El acuerdo contempla el traspaso si una enfermedad, una sobrecarga o un cliente mayor interrumpen el trabajo.

La pregunta incómoda es si la persona puede desaparecer. Cualquier individuo puede hacerlo. Reduce ese riesgo con hitos pequeños, envíos diarios al repositorio, decisiones escritas y accesos que tú controles. No pagues por semanas de trabajo local invisible. Un buen contratista no se opondrá a un progreso recuperable porque protege a ambas partes cuando cambian las prioridades.

No descartes a un contratista solo porque no tenga respaldo empresarial. Un ingeniero excelente con experiencia relevante puede superar a un grupo que asigna el trabajo a quien esté libre. Entrevista a la persona que hará los commits, no solo a quien vende. Si esa persona no puede explicar una ruta de fallo probable en tu arquitectura, el número de empleados de la empresa no salva la propuesta.

Una empresa de remediación debe asumir las conexiones

Una empresa de remediación se gana su margen al hacerse cargo de las conexiones entre especialidades. El equipo debe relacionar el diagnóstico del código con los hallazgos de seguridad, los cambios en la base de datos con el plan de reversión y el comportamiento reparado con el despliegue en producción. Si se limita a asignar un generalista y añade gestión de proyectos, el fundador paga más sin recibir una revisión más amplia.

Pregunta quién hace cada tipo de trabajo y quién tiene la autoridad técnica final. Te interesan roles con nombre aunque una persona cubra dos: ingeniero de aplicaciones, revisor de seguridad, responsable de despliegue y responsable de entrega. También necesitas saber si el revisor puede rechazar la solución del implementador. «Nuestro equipo lo revisa todo» no explica el control real.

Las empresas encajan en códigos con varias incógnitas que interactúan. Imagina una aplicación de suscripciones generada donde el navegador decide si un usuario es administrador, la API acepta un identificador de cliente desde el cuerpo de la solicitud, las políticas de la base de datos cubren las lecturas pero no las actualizaciones y el webhook de pago puede procesar dos veces el mismo evento. Arreglar la pantalla visible de administración deja expuesta la API. Endurecer la API puede romper tareas legítimas de soporte. Añadir una regla de base de datos puede bloquear el webhook. La recuperación necesita un único modelo de identidad y autoridad para las cuatro rutas.

Una empresa fiable debe hacer explícito ese modelo. Debe decirte dónde ocurre la autenticación, dónde se toman las decisiones de autorización, qué servicio puede modificar cada registro y cómo demuestran su identidad los trabajos en segundo plano. Es difícil deducir esa profundidad de revisión de una propuesta cuidada, así que pide ejemplos de entregables sin datos del cliente. Busca pruebas y registros de decisiones, no capturas de un escáner.

El modelo de empresa tiene sus propios fallos. El equipo comercial puede aparentar demasiada certeza sobre el alcance antes de que los ingenieros revisen el repositorio. El trabajo puede pasar entre personas que entienden cada una una parte, mientras nadie comprende la ruta completa de una solicitud. Un proyecto cerrado puede animar al equipo a clasificar los descubrimientos como «fuera de alcance». Reduce estos riesgos con un inicio técnico dirigido por el ingeniero, una persona responsable del modelo del sistema y una regla escrita para los nuevos bloqueos.

No compres un equipo grande por defecto. Compra cobertura para los riesgos que revela tu mapa de alcance. Si la aplicación necesita trabajo profundo en un solo framework y poco más, un contratista sénior puede ofrecer mejor criterio por cada euro. Si el código cruza límites de identidad, datos, seguridad y despliegue, una revisión independiente y la responsabilidad en paralelo pueden acortar la parte peligrosa de la recuperación.

La profundidad de revisión debe seguir los límites de confianza

La profundidad de revisión es el número de suposiciones importantes que pone a prueba un proveedor, no la cantidad de archivos que escanea. Una revisión útil sigue los límites de confianza: del navegador a la API, de la API a la base de datos, de la aplicación al proveedor de pagos, del worker a la cola y del sistema de despliegue al almacén de secretos. El código generado con IA suele parecer coherente dentro de un archivo mientras rompe el contrato entre dos sistemas.

El Application Security Verification Standard de OWASP da a los compradores un vocabulario práctico para este trabajo. Trata la arquitectura, la autenticación, la gestión de sesiones, el control de acceso, el manejo de entradas, la protección de datos, las API, la configuración y la lógica de negocio como áreas de verificación separadas. Yo no exigiría todos los requisitos de ASVS para cualquier SaaS pequeño. Exigiría al proveedor que nombre las áreas aplicables, elija comprobaciones según los datos y la exposición de la aplicación y devuelva pruebas de cada resultado. Eso sirve más que pedir una «auditoría de seguridad» sin definir.

El Secure Software Development Framework de NIST plantea una idea relacionada: las prácticas seguras deben integrarse en el proceso de desarrollo porque los ciclos de desarrollo corrientes a menudo no cubren la seguridad con suficiente detalle. En un traspaso, eso significa que la revisión de seguridad no puede ser un escaneo posterior a las reparaciones funcionales. El proveedor debe incluir requisitos de seguridad en el plan, probar la implementación, registrar los riesgos sin resolver y preparar la configuración que se publicará.

El control de acceso muestra por qué importa la profundidad. Una revisión superficial comprueba si las páginas protegidas redirigen a visitantes anónimos. Una revisión seria llama a los endpoints con la sesión de un usuario normal, cambia identificadores de objetos, intenta escrituras prohibidas, prueba sesiones caducadas y verifica la aplicación de las políticas en la base de datos cuando la arquitectura depende de ella. Ocultar un botón es comportamiento de interfaz. Rechazar una operación no autorizada es control de acceso. Los equipos confunden ambas cosas con frecuencia y publican la equivocada.

Solicita una matriz de cobertura en la propuesta:

Las herramientas automáticas ayudan a encontrar dependencias, patrones sospechosos y problemas conocidos en paquetes. No pueden decidir si un agente de soporte debe reembolsar una factura después de una cancelación o si el propietario de un espacio puede transferir datos. Son reglas de producto expresadas mediante código. El revisor debe reconstruirlas con el fundador y convertirlas en pruebas.

El plazo de entrega empieza por la ruta crítica

Una recuperación rápida nace de reducir la ruta crítica del lanzamiento, no de teclear más deprisa. Un proveedor debe identificar qué fallos bloquean todo lo demás, qué tareas pueden ejecutarse en paralelo y qué mejoras pueden esperar. Sin esa secuencia, varios ingenieros pueden crear conflictos de fusión mientras la aplicación sigue sin poder desplegarse.

En un SaaS roto, la ruta crítica suele empezar por el acceso y la reproducibilidad. El proveedor necesita el repositorio actual, archivos de bloqueo de dependencias, nombres de variables de entorno, esquema de base de datos e historial de migraciones, configuración de despliegue y acceso seguro a las cuentas de servicio relevantes. Los secretos de producción que falten no deben copiarse en un chat. El proveedor debe crear una vía de acceso controlada y sustituir las credenciales expuestas antes de confiar en cualquier prueba.

Puedes comprobar si el traspaso está listo con una secuencia concreta. Ejecútala en un checkout limpio y un entorno desechable:

git clone REPOSITORY_URL app
cd app
cp .env.example .env
npm ci
npm run build
npm test

La forma del resultado importa más que lograr que todos los comandos pasen el primer día. Un fallo útil identifica una variable ausente, una migración o una prueba concreta. Un proceso que depende de paquetes globales no registrados, archivos locales privados o clics de consola recordados por un ingeniero no es reproducible. Registra cada fallo, el comando que lo produjo y el cambio que lo elimina.

Después de reproducir, ordena el trabajo según su radio de impacto. La identidad y el aislamiento de datos van antes que el pulido visual. Las migraciones de datos van antes que funciones que presuponen el nuevo esquema. La reparación de compilación y despliegue va antes de prometer una fecha. El proveedor puede trabajar en defectos independientes de la interfaz en paralelo, pero solo si esos cambios no ocultan ni complican las rutas arriesgadas.

Los fundadores preguntan a veces si una empresa siempre trabaja más rápido. No. Una empresa puede paralelizar el diagnóstico y la revisión, pero la coordinación lleva tiempo. Un contratista que conoce la pila puede resolver antes un problema acotado que un equipo recién reunido. La ventaja de la empresa aparece cuando la ruta crítica exige habilidades distintas o cuando la revisión independiente puede avanzar mientras continúa la implementación.

Trata una promesa de plazo como un plan, no como un número. Pregunta qué accesos deben existir al comenzar, qué espera saber el proveedor después del primer día, qué hito produce una compilación desplegable, cuándo entran los hallazgos de seguridad en la cola y qué podría cambiar la fecha. Una estimación breve sin dependencias es texto comercial.

La responsabilidad vive en los documentos y los accesos

La responsabilidad significa que el fundador puede ver qué cambió, por qué cambió, quién lo aprobó y cómo operarlo después del traspaso. Un contacto amable resulta útil, pero no basta. El repositorio y el registro de lanzamiento deben contestar esas preguntas cuando las personas no estén disponibles.

Incluye estos entregables en cualquiera de los dos contratos:

• Un diagnóstico priorizado con rutas afectadas, impacto para el usuario y tratamiento propuesto.
• Un plan de reparación que asigne cada problema aceptado a un responsable y una prueba de aceptación.
• Pull requests o conjuntos de cambios equivalentes con historial de revisión.
• Instrucciones de despliegue, inventario de configuración y procedimientos de migración y reversión.
• Un registro final de riesgos corregidos, aplazados y aceptados.

La propiedad de las cuentas merece la misma atención. La organización del fundador debe ser propietaria del repositorio, dominio, proyecto de nube, base de datos, cuenta de pagos, servicio de correo, analítica y almacén de secretos. Da al proveedor cuentas nominativas con el acceso mínimo necesario. Compartir contraseñas del fundador impide atribuir acciones y dificulta la salida. Al terminar, elimina el acceso del proveedor y rota cualquier credencial que se pudiera haber copiado.

Define la aceptación antes de implementar. «Autenticación arreglada» no se puede probar con suficiente precisión. Un texto mejor dice que un usuario sin sesión no puede llamar a endpoints protegidos, que un usuario no puede leer ni actualizar objetos de otra cuenta, que la caducidad de sesión obliga a autenticarse de nuevo, que la recuperación de contraseña invalida tokens anteriores y que los resultados aparecen en pruebas automáticas. Estas frases sacan a la luz desacuerdos mientras los cambios aún cuestan poco.

La responsabilidad también cubre la decisión de no arreglar algo. Una dependencia antigua puede exigir una actualización mayor de la que tolera el lanzamiento inmediato. El proveedor debe registrar el riesgo, por qué se aplazó, cualquier control temporal y la condición que activa el trabajo posterior. Un aplazamiento silencioso se convierte en la próxima emergencia.

Una empresa suele ofrecer continuidad organizativa y una sola entidad responsable del proyecto. Lee aun así las cláusulas de subsanación. Un contrato con un profesional puede crear una responsabilidad igual de clara si explicita los hitos, entregables, accesos y periodos de soporte. El lenguaje legal no sustituye a las pruebas técnicas, pero las pruebas sin una parte responsable dejan al fundador coordinando disputas.

Pregunta quién aprueba el lanzamiento a producción. El proveedor debe recomendar si se publica o no según las pruebas. El fundador conserva la decisión empresarial, incluida la aceptación de un riesgo conocido. Esa separación evita que el proveedor publique en silencio para cumplir una fecha y que el fundador trate la advertencia prudente de un ingeniero como un retraso sin explicar.

La tarifa por hora y el precio de proyecto trasladan riesgos distintos

El precio por hora deja el riesgo del diagnóstico al comprador. El precio por proyecto deja el riesgo de una entrega definida al proveedor. Ningún modelo sale siempre más barato. El precio depende de cuánta incertidumbre haya, quién pueda controlarla y qué ocurra cuando fallen las suposiciones iniciales.

Un contratista sénior por horas encaja cuando las prioridades pueden cambiar, el fundador quiere controlar de cerca la cola o la primera tarea es diagnosticar. El comprador paga el tiempo real y puede parar en cualquier hito. El peligro es un contador abierto unido a un resultado poco claro. Una tarifa baja sale cara cuando el ingeniero pasa días reconstruyendo contexto, repite soluciones o espera a otro especialista.

Una tarifa de proyecto resulta útil cuando el proveedor puede definir el estado final y las pruebas de aceptación. La empresa incluye un margen para la incertidumbre, por lo que la cifra inicial puede parecer mayor. A cambio, el comprador conoce el presupuesto para el alcance escrito. Esa certeza desaparece si el acuerdo excluye todos los problemas descubiertos después del inicio.

Haz comparables las ofertas normalizándolas en la misma tabla:

No compares la estimación de programación de un contratista con la propuesta de diagnóstico, reparación, revisión y despliegue de una empresa. Quita los servicios adicionales de la oferta de la empresa o añádelos al plan del contratista. Después compara el coste esperado, el coste en el peor caso, el tiempo de coordinación del fundador y el coste de un lanzamiento retrasado o inseguro.

No me gustan las ofertas cerradas basadas solo en una breve llamada comercial. El modelo es popular porque los fundadores quieren una cifra, pero el proveedor solo tiene dos formas de protegerse: añadir un gran margen de incertidumbre o escribir exclusiones estrechas. Un diagnóstico pagado seguido de un alcance de reparación cerrado suele ser más honesto. Una fase de diagnóstico con tope también funciona si el proveedor se compromete a parar e informar antes de superarlo.

El calendario de pagos puede reducir el riesgo para ambas partes. Vincula los pagos a pruebas como un diagnóstico completo, un conjunto de reparaciones aceptado, un lanzamiento en staging y el traspaso de producción. No los vincules solo a fechas o porcentajes vagos de avance. Las pruebas hacen concretos los desacuerdos.

La propuesta debe demostrar cómo funcionará el trabajo

La mejor propuesta funciona como un pequeño ensayo del encargo. Identifica incógnitas, declara suposiciones, nombra responsables, describe pruebas y explica cómo cambian el alcance los nuevos hallazgos. Un proveedor incapaz de estructurar la propuesta no se volverá más disciplinado dentro de un repositorio dañado.

Entrega a cada candidato el mismo paquete breve: resumen del repositorio, pila, estado actual del despliegue, fallos conocidos, roles de usuario, tipos de datos sensibles, objetivo de lanzamiento y restricciones de acceso. No envíes credenciales activas ni datos de clientes. Pide a los candidatos que describan sus primeros cinco días laborables, pero no premies la ficción más detallada. Premia el plan que separa los hechos confirmados de las preguntas.

Puntúa las respuestas con pesos que reflejen tu riesgo. Un SaaS típico en problemas puede ponderar el método de alcance, la cobertura de revisión, las pruebas de aceptación, el plan de entrega, la experiencia relevante y el precio. Los pesos exactos importan menos que aplicar los mismos a todas las ofertas. Una propuesta barata debe perder si omite pruebas de autorización o supone que el fundador coordinará el despliegue.

Durante la entrevista técnica, usa un fallo de tu propia aplicación. Pide al candidato que lo siga por el navegador, la API, la base de datos y el entorno de despliegue. Los buenos candidatos piden registros y código antes de declarar una causa. Pueden nombrar hipótesis probables, pero las separan de los hallazgos. Observa cómo responden cuando revelas una regla de producto que contradice su idea. El trabajo de recuperación está lleno de esas correcciones.

Pide que asista la persona que hará el trabajo. En el caso de un contratista es evidente. En el de una empresa, insiste en el responsable técnico en vez de depender del gestor de cuenta. Habla de la frecuencia de comunicación, pero dedica más tiempo a la escalada: ¿quién decide cuándo un parche local es inseguro, cuándo resulta más barato reescribir o cuándo debe pararse un lanzamiento?

Las referencias deben centrarse en el comportamiento durante un traspaso. Pregunta si el proveedor encontró problemas importantes fuera del síntoma inicial, comunicó los cambios de coste antes de trabajar, dejó la aplicación desplegable y transfirió el conocimiento. Los elogios generales cuentan poco.

FixMyMess ofrece una auditoría gratuita del código antes de comprometerse y combina el diagnóstico asistido por IA con la verificación de expertos humanos, lo que da a los fundadores no técnicos una vía para definir el alcance antes de elegir una reparación. Tanto si usas esa opción como otro proveedor, no autorices una reconstrucción hasta que el diagnóstico explique por qué la reparación no puede cumplir los criterios de aceptación.

Elige el modelo de responsabilidad que exige tu fallo

Elige a un contratista sénior cuando el fallo esté acotado, la pila coincida con su experiencia, el fundador pueda gestionar las prioridades y el encargo tolere la capacidad de una sola persona. Elige una empresa de remediación cuando el código contenga incógnitas relacionadas, la seguridad y el despliegue necesiten atención separada, el trabajo deba avanzar en paralelo o el fundador necesite que una parte asuma la recuperación completa.

No conviertas esta orientación en una regla según la cual las empresas son seguras y los contratistas arriesgados. Un ingeniero sénior identificado y con un proceso disciplinado supera siempre a un equipo difuso. La propuesta debe mostrar quién inspecciona los límites de confianza, quién implementa, quién revisa, quién despliega y quién responde cuando falla la aceptación.

Antes de firmar, exige cinco decisiones por escrito:

1. El límite del diagnóstico y los documentos que producirá.
2. Las pruebas de aceptación para el lanzamiento, incluidas las pruebas negativas de seguridad.
3. Las personas responsables de implementación, revisión independiente y despliegue.
4. El método para presupuestar descubrimientos y aprobar cambios de alcance.
5. Los accesos, el historial del repositorio y la documentación operativa que conservas al terminar.

Si los candidatos se resisten a esas decisiones, el problema no es su tipo de empresa. Te piden que financies la ambigüedad. Una aplicación generada y rota ya contiene suficiente ambigüedad; el contrato de traspaso debe eliminarla.

El primer hito pagado debe producir un mapa de alcance que puedas llevar a otro proveedor. Eso mantiene al proveedor honesto, da una salida al fundador y convierte una pila inquietante de síntomas en una recuperación comprobable. Con ese documento, elegir entre empresa y contratista resulta mucho menos emocional: puedes ver si una persona puede asumir la ruta crítica o si el trabajo necesita varios revisores responsables.