Encargar una web o una tienda WordPress no es comprar un producto en la estantería, sino entrar en una relación de la que es difícil salir a mitad de camino. La decisión más importante no tiene que ver con el precio ni con el portafolio de quien parece más bonito, sino con lo que queda en tus manos cuando el proyecto termina: el acceso, el código y los derechos. Esta guía reúne las preguntas que realmente separan a un buen proveedor de los problemas, y un área en la que casi nadie piensa hasta que es demasiado tarde: el derecho.
Agencia, freelance o equipo interno
Es una elección de continuidad, no de calidad. Un freelance aislado puede ser la mejor opción técnica y el más rápido al decidir, pero también es un único punto de fallo. Hemos visto una tienda detenerse durante una semana porque la única persona que conocía su código se había ido a la montaña sin cobertura, y el conocimiento sobre el proyecto no estaba registrado en ningún sitio. Un equipo interno resuelve el problema de la continuidad, pero solo compensa con una carga de trabajo constante y elevada; con tareas irregulares, un puesto fijo está parado y cuesta igual.
Una agencia es el término medio: pagas un sobreprecio por el equipo y el proceso y, a cambio, obtienes personas sustituibles y documentación, de modo que el proyecto no se detiene cuando una persona se va. El modelo intermedio razonable para la mayoría de las empresas B2B y las tiendas es un ingeniero fijo y nombrado por parte del proveedor, pero con un equipo y conocimiento registrado detrás. La pregunta de control es sencilla: qué pasa con mi proyecto cuando esa persona concreta enferma o se va.
| Criterio | Freelance | Agencia | Equipo interno |
|---|---|---|---|
| Continuidad | Único punto de fallo | Personas sustituibles y documentación | Resuelta, pero solo con carga estable |
| Modelo de costes | Tarifa más baja, disponibilidad irregular | Sobreprecio por el equipo y el proceso | Salario, queda parado con trabajo irregular |
| Velocidad de decisión | La más rápida | Rápida, a través de un ingeniero nombrado | Rápida, pero solo interna |
| Conocimiento documentado | A menudo ninguno | Registrado y listo para la entrega | Depende del equipo |
| Mejor encaje | Tareas pequeñas y bien definidas | La mayoría de webs y tiendas B2B | Carga estable y elevada |
En qué fijarte en lugar de en un portafolio bonito
Un portafolio muestra cómo se ve algo en una captura de pantalla, no cómo funciona bajo carga. Tres cosas dicen más que una galería de trabajos anteriores.
La primera es el rendimiento medido, no declarado. Pide un resultado de Core Web Vitals a partir de datos de campo, o de una prueba en un móvil medio con una conexión más lenta, no en un portátil con fibra. La metodología y los umbrales los describe el equipo de Google en la documentación de Web Vitals. Un buen proveedor muestra cifras antes y después, explica cómo maneja los page builders pesados y cuántas consultas a la base de datos genera una página de producto.
La segunda es la forma de trabajar con el código. Pregunta directamente si el código está versionado en un repositorio o se sube por FTP directamente al servidor. El versionado no es un capricho: es la posibilidad de revertir un error, auditar cambios y permitir que cualquier otra persona retome el proyecto. La falta de repositorio significa que quedas atado a un único proveedor, porque nadie más entra en ese código sin arqueología.
La tercera es la seguridad tras el lanzamiento. Una web no es un cuadro que se cuelga y se olvida; los plugins hay que actualizarlos, y la cadena de suministro de los plugins puede ser un vector de ataque. Pregunta quién responde por las actualizaciones tras el arranque y cómo es la respuesta ante un incidente. La falta de respuesta significa que respondes tú, solo que aún no lo sabes.
Nueve preguntas antes de firmar
Estas preguntas cuestan diez minutos en la primera reunión y ahorran meses de conflicto. Llévalas escritas y apunta las respuestas: lo que el proveedor no quiera responder por escrito tampoco lo cumplirá de palabra.
- ¿De quién serán los derechos patrimoniales de autor sobre el código y el diseño cuando termine el proyecto, y en qué modalidades de explotación?
- ¿A nombre de quién quedan las licencias de los plugins y temas premium, y qué pasa con ellas si dejamos de trabajar juntos?
- ¿Obtendré acceso administrativo completo al alojamiento, al dominio, al repositorio y a las cuentas externas, o trabajamos en vuestra cuenta cerrada?
- ¿El código está versionado y los despliegues son reproducibles, o los cambios llegan al servidor a mano?
- ¿Quién responde por las actualizaciones, las copias de seguridad y la seguridad tras el lanzamiento, y qué abarca el mantenimiento?
- ¿Qué ocurre exactamente al terminar el contrato: en qué plazo y en qué formato recibo el código, la base de datos, los contenidos y la documentación?
- ¿Cuáles son los tiempos de respuesta ante una incidencia, y qué se considera incidencia crítica frente a una petición normal?
- ¿Subcontratáis parte del trabajo? Si es así, ¿quién responde ante mí por la calidad y la confidencialidad, y lo recoge el contrato?
- ¿Cómo es la política de copias de seguridad y de reversión: cada cuánto se hacen, dónde se guardan (fuera del propio servidor, idealmente) y cuánto tarda una restauración completa?
Si cualquiera de estas preguntas recibe una respuesta evasiva, no es una cuestión de conocimiento, sino de un modelo de negocio que ata al cliente al proveedor por la fuerza y no por la calidad. Las preguntas 2, 6 y 9 son las que más rara vez se hacen y las que más caro cuesta no haber hecho.
Derecho y propiedad: el área en la que nadie piensa lo bastante pronto
Aquí empieza la parte más fácil de pasar por alto y más difícil de corregir después. Según la ley polaca, el mero pago de un proyecto no transfiere automáticamente los derechos patrimoniales de autor sobre el código, las imágenes o los textos; se necesita una cláusula expresa en el contrato que indique las modalidades de explotación. Sin ella, los derechos se quedan con el proveedor y tú solo tienes una licencia para usar aquello por lo que pagaste. El abogado polaco Tomasz Palak lo resume sin rodeos: como escribe en su guía sobre derechos de autor para creadores, “al publicar no se pierden los derechos”, lo que funciona en ambos sentidos, también por parte del proveedor, mientras este no ceda los derechos de forma consciente.
La misma cautela se aplica a los materiales que se suben a la web. Que una foto esté disponible en internet, o que la haya generado un modelo de IA, no significa que puedas usarla comercialmente; hay que comprobar la licencia, porque, como recuerda Palak, no toda “imagen gratuita” es realmente gratuita, y una licencia CC BY no es lo mismo que CC0. Por tu parte, conviene asegurar tres cosas en el contrato:
- La cesión de los derechos patrimoniales de autor sobre el código, el diseño y los contenidos, y no solo una licencia.
- Una declaración del proveedor de que posee los derechos sobre todos los materiales usados, fotos, tipografías y plugins premium, así como sus licencias.
- El cumplimiento del RGPD si la web recoge datos, es decir, quién es el responsable del tratamiento y quién el encargado, y qué pasa con los datos cuando termina la colaboración.
Si usas herramientas de IA para contenidos o imágenes, recuerda una regla que Palak repite: la herramienta no te quita la responsabilidad por lo que publicas. Comprueba los términos de la herramienta y no introduzcas datos que no puedes divulgar. Lo mismo vale para la agencia que contratas: conviene preguntar si usa IA y cómo, y quién responde por los derechos sobre los resultados.
Modelos de contrato y facturación
Cómo se factura condiciona cómo se trabaja, y conviene entender qué incentiva cada modelo antes de discutir cifras. El importe concreto siempre es individual y depende del alcance; lo que sí se puede comparar de antemano es el mecanismo.
El proyecto cerrado (precio fijo por un alcance definido) da previsibilidad de presupuesto, pero incentiva al proveedor a interpretar el alcance de forma restrictiva: cada cambio de opinión se convierte en una ampliación facturable, y las conversaciones sobre “esto entraba o no entraba” desgastan más que el propio desarrollo. Funciona bien cuando el alcance está de verdad cerrado, con contenidos y diseños listos antes de empezar, algo que en la práctica ocurre pocas veces.
La facturación por horas invierte el incentivo: el proveedor no tiene motivo para regatear el alcance, pero el riesgo de presupuesto pasa al cliente. Solo es sana con dos condiciones: reportes de tiempo detallados y verificables, y un techo mensual acordado que no se supera sin aviso previo. Sin esas dos cosas, por horas significa cheque en blanco.
El retainer o bono mensual (una bolsa fija de horas o un servicio continuo de mantenimiento) es el modelo natural para la fase posterior al lanzamiento: actualizaciones, seguridad, pequeñas mejoras. Incentiva la prevención, porque al proveedor le sale más rentable que la web no se rompa que facturar arreglos de urgencia. Si quieres ver qué debe cubrir un servicio así, lo desglosamos en la guía de mantenimiento profesional de WordPress.
En la práctica, la combinación más sana para una web o tienda de empresa es proyecto cerrado para la construcción inicial, con un procedimiento claro de cambios, y retainer para la vida posterior. Desconfía del proveedor que solo ofrece un modelo y lo presenta como el único posible: suele significar que optimiza su facturación, no tu resultado.
Banderas rojas
Algunas señales ante las que es mejor dar las gracias antes de firmar. Un proveedor que no quiere entregar el acceso al alojamiento, al dominio y al código. La ausencia de repositorio y despliegues exclusivamente manuales. Un precio indicado al margen del alcance, sin análisis de los requisitos reales. Promesas de posiciones en Google o de “visibilidad en la IA” dadas de palabra, sin explicar en qué deben consistir. Por último, el silencio sobre los derechos de autor, porque eso suele significar que los derechos se quedan con el proveedor y solo te enterarás cuando intentes cambiar de proveedor.
Hay otras señales menos evidentes que en la práctica hacen el mismo daño:
- Sin entorno de staging. Si cada cambio se prueba directamente en la web publicada, tus clientes son el entorno de pruebas. Preguntar “¿dónde probáis los cambios antes de subirlos?” desmonta esta bandera en diez segundos.
- Sin política escrita de actualizaciones. “Actualizamos cuando hace falta” no es una política. Una respuesta seria incluye frecuencia, pruebas tras actualizar y qué pasa si una actualización rompe algo.
- Licencias de page builders y plugins a nombre de la agencia. Si la web está construida sobre Elementor Pro o Divi con la licencia de la agencia, el día que os separáis te quedas sin actualizaciones de la pieza central de tu web. O la licencia se contrata a tu nombre desde el principio, o el contrato obliga a transferirla al terminar.
- Repositorio sin acceso para el cliente. “El código está versionado” no basta si el repositorio vive en una cuenta a la que no puedes entrar. Versionado sin acceso es lock-in con mejor aspecto.
- “Revisiones ilimitadas”. Suena generoso y es lo contrario: un alcance sin límites no se puede planificar, así que en la práctica el proveedor las limita por agotamiento, alargando los plazos hasta que dejas de pedir cambios. Un número razonable de rondas de revisión bien definidas protege a las dos partes.
- Silencio sobre accesibilidad. Desde junio de 2025, la Ley 11/2023 (la transposición española del Acta Europea de Accesibilidad) exige accesibilidad al comercio electrónico y a varios servicios digitales. Una agencia que en 2026 no sabe qué le aplica a tu tienda no está al día del marco en el que trabaja.
Cómo es una buena entrega del proyecto
La entrega es donde se comprueba si todo lo anterior era verdad. Una entrega profesional no es un correo con un enlace a la web publicada, sino un paquete concreto que puedes verificar punto por punto antes de dar por cerrado el proyecto.
Primero, el repositorio. El código debe acabar en un repositorio al que tengas acceso de propietario, idealmente en una organización de GitHub o GitLab de tu empresa, no en la cuenta personal de un desarrollador. Si el proveedor sigue dando mantenimiento, se le mantiene como colaborador; si mañana cambias de equipo, el nuevo desarrollador WordPress clona el repositorio y sigue trabajando sin pedir permiso a nadie.
Segundo, la documentación. Como mínimo: cómo se despliega un cambio, qué plugins hay instalados y para qué sirve cada uno, qué licencias premium existen y cuándo caducan, y qué personalizaciones se apartan del comportamiento estándar de WordPress. No hace falta un manual de cien páginas; hace falta que una persona técnica nueva entienda el proyecto en una tarde.
Tercero, las credenciales. La transferencia se hace mediante un gestor de contraseñas o un intercambio cifrado, nunca en un Excel adjunto a un correo. Y no solo el wp-admin: alojamiento, dominio, CDN, cuentas de correo transaccional, pasarelas de pago y analítica. Cada cuenta que sigue a nombre del proveedor es una correa que te ata a él.
Cuarto, la titularidad de la infraestructura. El dominio debe estar registrado a nombre de tu empresa, con el contacto de titular en tu correo, y el alojamiento contratado en una cuenta tuya, sea Webempresa, Raiola Networks, dinahosting o cualquier proveedor serio del mercado español. Es un patrón que se repite en las mesas de ayuda de las WordCamps españolas: gente que descubre en plena disputa que su dominio pertenece, registralmente, a la agencia con la que está discutiendo. Recuperarlo entonces es un proceso largo; evitarlo al principio es una casilla en el formulario de registro.
Quinto, una sesión de formación. Una hora o dos en las que tu equipo aprende a editar contenidos, crear entradas y entender qué no debe tocar. Grábala: la rotación de personal hace que esa grabación valga más que la sesión misma.
Qué sigue
Elegir bien a un proveedor WordPress se reduce a un principio: asegura lo que quedará en tus manos cuando el proyecto termine, antes de que empiece. El acceso, el código versionado y los derechos cedidos por escrito importan más que la diapositiva más bonita de la propuesta. Si estás planeando una web o una tienda y quieres repasar esta lista en un caso concreto, describe lo que el proyecto debe lograr y revisamos juntos a qué prestar atención en tu situación.
Los aspectos jurídicos de este texto tienen carácter general y no constituyen asesoramiento jurídico; ante un contrato concreto, conviene consultar a un abogado especializado en derechos de autor y nuevas tecnologías.
Última actualización: 11 de junio de 2026.
