Qué hacer si un freelancer entrega código defectuoso

Qué hacer cuando un freelancer entrega código defectuoso

Si te preguntas qué hacer si un freelancer entrega código defectuoso, lo primero es distinguir entre un fallo común y una entrega que realmente impide usar el trabajo. El código defectuoso no es lo mismo que un error normal. Un fallo común aparece en una función que, en general, sí funciona; en cambio, un código defectuoso puede frenar un lanzamiento, bloquear un inicio de sesión o volver inutilizable un archivo desde el primer día. Esa diferencia importa porque tu siguiente paso debe responder al daño real, no a tu estado de ánimo.

Empieza con una sola pregunta: ¿alguien puede usarlo con seguridad? Si la respuesta es no, trátalo como un problema de entrega, no como una tarea de pulido. Si la respuesta es sí, pero falla una parte concreta, probablemente estés ante un defecto que aún necesita corrección. Simple, pero útil.

¿Qué cuenta como “código defectuoso” frente a un error normal?

El código defectuoso suele aparecer de 3 formas: trabajo incompleto, trabajo inestable o trabajo que no puede ejecutarse en el entorno acordado. Un botón de formulario que lanza un error al enviar es un fallo. Un flujo de compra que nunca llega al pago porque el freelancer omitió la validación, el archivo de rutas o el gancho de API requerido es código defectuoso.

Observa primero el alcance. Si el freelancer prometió un creador de páginas y entregó solo la cabecera, eso no es un defecto menor. Si entregó un script que depende de un archivo que no se mencionó en ningún sitio, eso tampoco es un detalle menor. El código puede existir, pero la entrega sigue estando defectuosa.

Una prueba práctica ayuda: ¿se puede evaluar el código frente al resultado acordado en menos de 5 minutos? Si necesitas conocimientos ocultos, pasos secretos de configuración o una explicación privada para que funcione, el problema es más grande que una errata. Este es el punto en el que muchos clientes deberían revisar sus notas y, si hace falta, comparar el problema con cómo contratar un freelancer con seguridad para el siguiente proyecto.

¿Qué deberías comprobar primero antes de contactar al freelancer?

Reproduce el problema una vez antes de escribir. Dos veces es mejor. Usa el mismo navegador, el mismo dispositivo y, si es posible, la misma cuenta. Anota exactamente qué pulsaste, qué ocurrió y dónde apareció el fallo. “No funciona” es demasiado vago para ayudar a nadie.

Luego registra el entorno. Apunta el nombre y la versión del navegador, el sistema operativo, la URL del servidor y si usaste staging o producción. Un flujo de código que funciona en Chrome en un portátil puede fallar en Safari en un móvil, y esa diferencia puede ahorrarte muchos intercambios después.

Recopila las pruebas mientras aún están frescas: capturas de pantalla, mensajes de consola, registros del servidor, IDs de error y la marca de tiempo del fallo. Si el error aparece después de un despliegue, anota el archivo exacto o la versión que recibiste. Estos detalles convierten una queja vaga en un informe útil.

No cambies tres cosas a la vez. Si editas la configuración, sustituyes el conjunto de datos y reinicias el servicio, nadie podrá saber qué cambio causó el fallo. Mantén fijo un solo camino de prueba.

¿Cómo deberías informar el código defectuoso sin convertirlo en una discusión?

Si buscas cómo reportar código defectuoso a un freelancer, mantén el primer mensaje corto, objetivo y fechado. Una buena estructura es: 1) qué falló, 2) dónde falló, 3) qué esperabas, 4) qué necesitas a continuación. Eso basta para abrir una conversación de corrección sin sonar acusatorio.

Ejemplo: “En el sitio de staging, el formulario de contacto devuelve un error 500 después de enviarlo. Esperaba que el formulario enviara el mensaje y mostrara una confirmación. Adjunté la captura y el registro de consola. Por favor, confirma la causa y envía una solución o una versión corregida.”

Ese texto no deja espacio para el drama. Además, evita culpar al freelancer por una intención que no puedes demostrar. Mantén concreta la frase sobre el impacto: “los clientes no pueden enviar pedidos”, “el panel de administración se bloquea” o “el archivo exportado está vacío”. Esos detalles importan más que las emociones.

Si el proyecto afectó a un trabajo visible para el público, el mensaje debe mencionar claramente la consecuencia. Una landing page rota puede desperdiciar un presupuesto de marketing en horas; un proceso de pago roto puede costar ventas de inmediato. Nadie necesita un párrafo dramático para entender eso.

¿Qué pruebas deberías compartir para que el freelancer lo arregle más rápido?

Envía los pasos para reproducir el problema en orden, no como una historia. Paso 1: inicia sesión. Paso 2: abre el panel. Paso 3: haz clic en Exportar. Paso 4: falla la descarga. Ese tipo de lista permite al freelancer repetir exactamente tu recorrido.

Incluye los datos de prueba que provocaron el problema, como una cuenta demo, un registro de ejemplo o un nombre de archivo concreto. Si el código depende de un idioma, una extensión del navegador o una variable de entorno específica, menciónalo. Un solo detalle que falte puede costar una tarde entera.

Comparte la información de versión del entregable. Si recibiste “v3”, dilo. Si el freelancer envió un parche después de tu última revisión, indica cuál. Si hay un repositorio privado, incluye el nombre de la rama y el hash del commit.

Las capturas ayudan, pero solo las adecuadas. Una imagen de una pantalla en blanco es útil. Una grabación de pantalla de 4 minutos puede ser aún mejor si muestra los clics y el fallo de una sola vez. Aquí es donde la frase opiniones del freelancer a veces cobra relevancia, porque un patrón de entregas poco claras suele aparecer ahí antes que en el código.

¿Cuándo deberías pedir una corrección, una reversión o un reembolso?

Elige la solución según la gravedad, no según la frustración. Si el fallo es menor y el código, por lo demás, sigue siendo utilizable, pide una corrección. Si el código defectuoso bloquea un lanzamiento o corrompe datos, una reversión puede ser la opción más segura y rápida. Si el entregable es inutilizable o no se puede reparar de forma segura, un reembolso empieza a ser razonable.

Haz una pregunta directa: ¿esto se puede arreglar sin dañar otras partes del proyecto? Si la respuesta es incierta y el freelancer está adivinando, volver atrás puede protegerte mejor que esperar. Un parche malo puede convertir un módulo roto en tres módulos rotos.

Los reembolsos no deberían ser la primera amenaza del mensaje 1. Corresponden después de revisar con claridad las pruebas y los términos de entrega. Aun así, si el trabajo no se puede reparar en el propio lugar, o el freelancer admite que la arquitectura es incorrecta, ya no deberías tratar el archivo como si estuviera a un solo paso de estar terminado.

Hay un matiz práctico aquí. Si una versión está bloqueando ingresos, cada hora de retraso tiene un coste, aunque no lo calcules al céntimo. Si el proyecto es privado y de bajo riesgo, la corrección puede esperar más tiempo. El contexto importa.

¿Qué pasa si el freelancer dice que el código funciona de su lado?

No tomes esa respuesta como una pelea. Tómala como una pista. En muchos casos, el problema es un desajuste de entorno: una máquina tiene dependencias en caché, otra usa una versión distinta de Node, o un servidor oculta un archivo que falta detrás de un paso de configuración local.

Pide la configuración exacta que usó el freelancer. Solicita los números de versión, los pasos de instalación y cualquier paso manual que siguió después de clonar o subir el proyecto. Si dice “en local funcionaba”, necesitas la receta local, no tranquilidad. Ese es el punto.

A veces el código depende de una suposición silenciosa. El freelancer quizá asumió que existía una cuenta de administrador, o que ya estaba presente un archivo de configuración, o que la base de datos contenía un registro semilla. Esas suposiciones deberían haberse documentado, pero ahora la tarea inmediata es sacarlas a la luz una por una.

Mantén un tono calmado, aunque la respuesta parezca evasiva. Una frase como “Por favor, envíame los pasos exactos de configuración que usaste para poder compararlos con mi entorno” basta. Si el freelancer coopera, la brecha suele cerrarse rápido. Si no, al menos sabrás que el problema ya no es solo técnico.

¿Cuándo el código defectuoso se convierte en un problema de entrega o de propiedad?

El código defectuoso se convierte en un problema de entrega cuando los archivos llegan sin los pasos necesarios para ejecutarlos. Eso incluye notas de instalación que faltan, datos de acceso que faltan, archivos de entorno que faltan e instrucciones de despliegue que faltan. El código puede estar presente; la propiedad, no.

Esto ocurre a menudo en proyectos que dependen de un equipo, no de una sola persona. Un desarrollador envía un repositorio, pero las credenciales del servidor están en un mensaje privado. Un diseñador entrega un tema del sitio, pero la herramienta de compilación nunca se menciona. Un script de backend solo funciona en la máquina del freelancer porque el resto de la configuración nunca quedó por escrito.

Llegado ese punto, el problema no es solo “arregla este fallo”. Es “¿puede mi equipo adoptar este trabajo siquiera?”. Si la respuesta es no, la entrega está incompleta, aunque cada archivo parezca ordenado. Aquí es donde las reglas de las reglas del sitio 24freelance.pro. freelance pueden servir como referencia útil sobre cómo deben gestionarse el trabajo, los archivos y la comunicación.

Algunos equipos también necesitan una lista de transferencia antes de aceptar el proyecto. Una línea para accesos. Una línea para hosting. Una línea para credenciales de administrador. Una línea para la estructura de carpetas. Sin eso, la entrega puede fallar incluso cuando el código en sí está bien.

¿Cómo evitas el mismo problema de entrega la próxima vez?

Escribe criterios de aceptación antes de empezar el trabajo. No un párrafo. Una lista. “El inicio de sesión funciona con credenciales válidas.” “La exportación genera un CSV con 3 columnas.” “El formulario envía el correo y muestra un mensaje de éxito.” Esas líneas hacen que el código defectuoso sea más fácil de detectar porque el objetivo queda visible.

Pide casos de prueba por adelantado, sobre todo en funciones con 2 o más ramas. Si el freelancer sabe cómo vas a probar, tendrá más probabilidades de construir para la comprobación real y no para una imaginaria. La revisión en staging también ayuda, porque detecta el código defectuoso antes de que nadie lo dé por terminado.

Define “terminado” con una sola frase que incluya archivos, accesos y pruebas. Por ejemplo: “Terminado significa que el código se ejecuta en nuestro servidor de staging, el README enumera los pasos de configuración y la cuenta de prueba verifica el flujo principal.” Esa definición no solucionará un mal trabajo, pero hará que el mal trabajo sea visible antes.

Para tareas complejas, pide una breve nota de entrega. Incluso 5 puntos pueden ahorrarte problemas después: entorno, dependencias, límites conocidos, datos de prueba y quién asume el siguiente paso. Una pequeña petición, una gran ganancia.

Un último hábito práctico: guarda el chat del proyecto y la lista final de archivos en el mismo lugar. Si el freelancer envía una corrección por correo, pero la nota de despliegue está en el chat y la contraseña del servidor está en una hoja de cálculo, la entrega es frágil. Y las entregas frágiles fallan bajo presión.