Cómo contratar un desarrollador freelance para un proyecto web

Contratar a un desarrollador freelance no consiste en comprar una web. Es una decisión sobre cómo vas a definir, construir y mantener una parte de tu negocio.

La diferencia importa porque una web puede parecer terminada y seguir sin resolver nada. Puede cargar bien, tener un diseño limpio y usar una tecnología reciente, pero no explicar un servicio, no facilitar una solicitud o dejar al equipo sin acceso a las cuentas cuando el proyecto acaba.

Por eso no empezaría pidiendo precio para “una web parecida a esta”. Empezaría por una pregunta más útil: ¿qué debería conseguir este proyecto para que dentro de seis meses consideremos que ha merecido la pena?

Mi recomendación por defecto para una pyme o un negocio que lanza una iniciativa nueva es acotar primero una versión pequeña y útil. Una web que explique bien la oferta, permita el contacto o cubra un proceso concreto suele aportar más que una lista larga de páginas, animaciones e integraciones que nadie ha validado todavía. Después puedes ampliar con datos y con calma.

La tecnología importa, claro. La propiedad de las cuentas, los criterios de aceptación, el contenido y el mantenimiento importan al menos tanto. Un buen profesional te ayuda a tomar esas decisiones antes de convertirlas en código.

Cuándo encaja un freelance y cuándo no

Un desarrollador freelance encaja especialmente bien cuando hay una persona que puede tomar decisiones, el proyecto tiene un objetivo comprensible y la comunicación puede ser directa. Por ejemplo: una web de servicios, un rediseño, una landing para validar una oferta, una aplicación interna acotada o una integración entre herramientas.

También puede encajar en proyectos más complejos si el alcance se divide en fases y alguien del negocio puede priorizar. La clave no es que el proyecto sea pequeño. Es que las decisiones importantes no dependan de una cadena de aprobaciones imposible.

No suele ser la mejor opción cuando necesitas un equipo grande disponible a la vez, una cobertura continua con acuerdos de servicio exigentes o muchas especialidades independientes desde el primer día. En ese caso quizá necesitas una agencia, un equipo interno o una combinación de perfiles.

Antes de buscar, revisaría estas preguntas:

Pregunta	Si la respuesta es “no”
¿Sabemos qué problema queremos resolver?	La primera fase debería ser descubrimiento, no desarrollo cerrado.
¿Hay una persona que pueda decidir prioridades?	El proyecto puede quedar bloqueado entre revisiones.
¿Podemos aportar contenido, acceso a sistemas y respuestas a tiempo?	El calendario de desarrollo no será el único que se retrase.
¿Sabemos qué debe ocurrir para considerar la entrega aceptada?	Las discusiones aparecerán al final, cuando cambiar cuesta más.
¿Las cuentas importantes estarán a nombre del negocio?	Dependerás de otra persona para operar o salir del proyecto.
¿Tenemos una idea de cómo se mantendrá después?	Una entrega puntual puede convertirse en una deuda inmediata.

No necesitas llegar con todas las respuestas. Pero conviene saber qué dudas son de negocio y cuáles esperas resolver con el profesional que contrates.

Empieza por el problema, no por la tecnología

“Necesito una web en WordPress”, “quiero una app en React” o “busco a alguien que sepa IA” son puntos de partida débiles. Describen una solución antes de explicar por qué hace falta.

Una primera conversación útil debería incluir:

• quién usará el resultado;
• qué necesita entender, hacer o dejar de hacer;
• qué ocurre ahora y dónde se pierde tiempo, dinero o clientes;
• qué contenido, sistemas o materiales ya existen;
• qué restricciones son reales: fecha, presupuesto, legal, marca, accesibilidad o integración;
• qué quedará fuera de la primera entrega.

Por ejemplo, “necesitamos una web más moderna” es demasiado amplio. “Los potenciales clientes no entienden qué servicio contratar, el formulario actual genera consultas poco cualificadas y el equipo tarda dos días en responder” permite hablar de estructura, contenido, formulario y seguimiento. Ya hay algo que construir y algo que medir.

La tecnología debería aparecer después de entender el contexto. En algunos casos WordPress es una elección razonable. En otros, una web estática es más fácil de mantener. Para una herramienta con permisos y datos internos, el problema puede pedir una aplicación a medida. Elegir el nombre de la tecnología antes de definir el trabajo suele convertir la propuesta en una lista de componentes, no en un plan.

Qué debería incluir una primera propuesta

Una propuesta útil no promete que todo será fácil. Hace visibles las decisiones y los límites.

Como mínimo, debería explicar:

• el objetivo del proyecto y para quién se construye;
• el alcance de la primera entrega: páginas, flujos, integraciones y contenido;
• qué necesita aportar el cliente y en qué momentos;
• qué decisiones siguen abiertas y cómo se resolverán;
• qué queda explícitamente fuera del precio;
• una secuencia de trabajo con puntos de revisión;
• cómo se probará y aceptará cada parte;
• qué se entrega al cierre: acceso, código, documentación y cuentas;
• qué soporte o mantenimiento existe después de publicar.

No esperaría una especificación de cien páginas para empezar. De hecho, en un proyecto con incertidumbre eso puede dar una falsa sensación de seguridad. Pero sí exigiría que las suposiciones estén escritas. Si el presupuesto asume que el cliente aporta textos, fotografías o acceso al CRM, debe decirlo. Si la integración depende de que un proveedor tenga API, también.

Una buena propuesta separa lo necesario para publicar de lo que puede esperar. Eso protege tanto al cliente como al freelance. Permite llegar a una primera versión que funciona sin fingir que todas las ideas de los próximos dos años tienen que decidirse esta semana.

Cómo comparar presupuestos sin quedarse solo con el precio

Dos presupuestos con la misma cifra pueden describir proyectos distintos. Uno puede incluir diseño, contenido, pruebas y despliegue. Otro puede entregar solo una plantilla instalada. Comparar el total sin comparar el alcance es una forma rápida de contratar expectativas incompatibles.

Yo compararía estas dimensiones:

Dimensión	Qué conviene comprobar
Problema y objetivo	¿Ha entendido el caso o reutiliza una propuesta genérica?
Alcance	¿Nombra páginas, flujos, integraciones y exclusiones?
Proceso	¿Hay revisiones antes de que todo esté construido?
Contenido y diseño	¿Quién aporta textos, imágenes, marca y aprobaciones?
Calidad	¿Incluye pruebas funcionales, responsive, accesibilidad básica y rendimiento?
Entrega	¿Incluye despliegue, configuración y una forma de comprobar que funciona?
Propiedad	¿Quién controla dominio, hosting, repositorio, analítica y cuentas externas?
Mantenimiento	¿Qué ocurre si hay una incidencia o hay que actualizar algo?

El presupuesto más barato puede ser correcto si el alcance es realmente pequeño y el riesgo es bajo. También puede omitir justo lo que hará falta después: contenido, migración, formularios, analítica, pruebas, soporte o acceso a las cuentas.

Preguntaría qué suposición tiene más probabilidades de cambiar el precio o el calendario. Es una pregunta sencilla y suele revelar si quien propone el trabajo ha pensado en los riesgos reales.

Propiedad y cuentas: el punto que se olvida hasta que duele

Dominio, hosting, repositorio de código, analítica, correo transaccional, cuentas de formularios, pagos y proveedores externos no deberían vivir solo en la cuenta personal del freelance.

El negocio debe poder acceder a lo que necesita para operar. Eso no implica administrar cada detalle técnico ni cambiar contraseñas cada semana. Implica que, si la relación termina o necesitas otro proveedor, puedes recuperar el dominio, los datos, el código y las configuraciones sin empezar de cero.

Antes de comenzar, dejaría claro:

• quién es propietario del dominio y quién tiene acceso de administrador;
• dónde se aloja la web y a nombre de quién está la cuenta;
• dónde queda el código y quién puede descargarlo;
• qué datos se recogen y quién controla las cuentas que los procesan;
• qué licencias, plantillas, servicios de pago o APIs tienen coste recurrente;
• qué documentación se entrega al finalizar.

No es desconfianza. Es una condición normal para que un proyecto pueda sobrevivir a cambios de proveedor, personas y prioridades.

Comunicación, revisiones y aceptación

La comunicación directa es una ventaja de trabajar con un freelance. No elimina la necesidad de registrar decisiones.

Define desde el inicio quién puede aprobar cambios, cuándo se revisa el trabajo y qué significa que una fase está aceptada. Para una web, quizá la primera revisión es estructura y contenido, la segunda diseño en las pantallas principales y la tercera versión funcional en un entorno de pruebas. Para una herramienta interna, las revisiones pueden seguir los casos de uso más importantes.

Conviene que cada revisión responda a una pregunta distinta. Si se discute tipografía, arquitectura de información, reglas de negocio y presupuesto en la misma llamada, las decisiones se mezclan y se olvida lo acordado.

También define cómo se gestionan cambios. Los cambios son normales. El problema aparece cuando una petición nueva se interpreta como si siempre hubiera estado incluida. Un proceso simple de “esto cambia alcance, coste o fecha; confirmémoslo antes” evita malentendidos de ambos lados.

Calidad antes de publicar

Una entrega no debería evaluarse solo con una captura de pantalla. Hay que comprobar qué ocurre cuando una persona real usa el resultado.

Para una web de negocio, yo incluiría al menos:

• revisión en móvil y escritorio;
• formularios y mensajes de confirmación funcionando;
• enlaces, redirecciones y páginas de error comprobados;
• contenido revisado por quien conoce el negocio;
• medidas básicas de accesibilidad: navegación por teclado, textos alternativos cuando proceda y contraste suficiente;
• tiempos de carga razonables para el contenido que se publica;
• analítica, privacidad y consentimiento configurados según lo que use la web;
• acceso y recuperación de las cuentas importantes verificados.

Para una aplicación o integración, añade pruebas de permisos, errores esperables, datos duplicados, reintentos y recuperación. Los detalles dependen del proyecto, pero hay una idea común: el criterio de aceptación debe cubrir el uso normal y los fallos previsibles.

Mantenimiento y la vida después del lanzamiento

Publicar no termina el trabajo. Cambian textos, aparecen actualizaciones de seguridad, caducan dominios, un formulario deja de enviar mensajes o un proveedor modifica su API.

Pregunta qué necesita revisión periódica, qué herramientas tienen cuota, qué alertas existen y cómo se notifica una incidencia. A veces basta con una guía de actualización y algunas horas de soporte al mes. Otras veces, una aplicación con datos sensibles necesita un acuerdo de mantenimiento más claro.

La respuesta correcta no es la misma para todos los proyectos. Lo importante es que no llegue como sorpresa después de publicar.

Señales de alerta al contratar

Hay propuestas que conviene mirar con más cuidado:

• un precio cerrado sin preguntas sobre contenido, usuarios o integraciones;
• promesas de posicionamiento garantizado o resultados comerciales sin explicar el trabajo;
• tecnología elegida antes de entender el problema;
• muchas prestaciones incluidas, pero sin orden ni criterios de aceptación;
• ninguna mención a propiedad de dominio, hosting o cuentas;
• ausencia de revisiones hasta el final;
• presupuesto que habla de diseño y desarrollo, pero no de pruebas ni despliegue;
• respuestas vagas sobre mantenimiento, seguridad o recuperación de accesos;
• presión para pagar o publicar antes de que puedas revisar lo acordado.

También tendría cuidado con el extremo contrario: un documento enorme que intenta prever cada pantalla antes de hablar con usuarios o probar el contenido. La planificación sirve para reducir incertidumbre, no para fingir que ya no existe.

Una ruta de proyecto que suele funcionar

La ruta que más confianza me da es: entender, acotar, construir, probar y ampliar después.

1. Define el resultado buscado y el problema actual.
2. Reúne contenido, referencias, accesos y restricciones conocidas.
3. Acordad una primera entrega con exclusiones visibles.
4. Revisa estructura y prioridades antes de entrar en detalles visuales.
5. Construye una versión funcional y pruébala en un entorno adecuado.
6. Corrige los problemas que aparecen con uso real.
7. Publica con las cuentas, accesos y documentación entregados.
8. Decide las siguientes mejoras a partir de datos y feedback, no de una lista de deseos antigua.

Esta secuencia no hace que un proyecto sea automático ni elimina las decisiones difíciles. Hace que sean más baratas de tomar. Si una idea resulta menos útil de lo esperado, puedes cambiarla antes de que arrastre seis semanas de trabajo relacionado.

Recomendación final

Para la mayoría de proyectos web de una pyme, buscaría un freelance que haga buenas preguntas, convierta el problema en un alcance manejable y deje las cuentas bajo control del negocio. Empezaría con una primera versión útil y evitaría comprometer presupuesto en funciones que todavía no responden a una necesidad clara.

La persona adecuada no es la que enumera más tecnologías. Es la que puede explicar qué va a construir, qué no va a construir todavía, cómo comprobaréis que funciona y qué necesitarás para mantenerlo después.

En mi página de diseño web en Granada explico cómo planteo webs de servicios, landings y rediseños para negocios que necesitan captar contactos.

Preguntas frecuentes

¿Necesito un documento completo antes de contactar?

No. Un objetivo, el contexto actual, referencias y límites conocidos bastan para una primera conversación. La persona que contrates debería ayudarte a convertir esa información en un alcance más preciso.

¿Cómo sé si un presupuesto es demasiado barato?

No se puede saber sin comparar alcance. Revisa qué incluye sobre contenido, diseño, pruebas, despliegue, cuentas, soporte y cambios. Un precio bajo puede ser correcto para una entrega pequeña; es preocupante si oculta trabajo imprescindible.

¿Debo contratar por horas o por proyecto?

Un alcance estable puede encajar con un precio por proyecto. Si todavía hay incertidumbre, una fase inicial por horas o con un presupuesto limitado puede ser más honesta. Lo importante es que se registre qué se decide y qué cambia.

¿Quién debería tener las cuentas del dominio y hosting?

El negocio debe tener acceso administrativo o ser titular de las cuentas importantes. El freelance puede gestionarlas técnicamente, pero no debería ser la única persona capaz de recuperar el proyecto.

¿Qué ocurre si quiero cambiar de proveedor?

Deberías poder obtener acceso al dominio, hosting, repositorio, datos, configuraciones y documentación. Acláralo antes de empezar, no cuando aparece la necesidad.

¿Hace falta mantenimiento después de publicar?

Depende de la tecnología y de las integraciones, pero toda web necesita al menos revisar accesos, renovaciones, formularios y contenido. Una aplicación o una web con servicios externos suele necesitar un plan más continuo.