Contratar desarrollador de plugins WordPress: filtro, tarifas y contrato

Cuando contratas a un desarrollador de plugins WordPress, no compras código. Compras los próximos años de un sistema del que dependerá tu negocio. La mayoría de los malos resultados no vienen de una función que falta. Vienen de código que nadie puede mantener, de un contrato que nunca asignó la propiedad o de un desarrollador que desaparece después del lanzamiento.

Esta guía empieza donde termina nuestro artículo sobre desarrollo de plugins WordPress a medida: cuándo, coste y proceso. Ya decidiste que un plugin a medida es el camino. Ahora toca elegir quién lo construye, a qué precio y bajo qué condiciones.

A continuación: cómo distinguir a un especialista de alguien que ensambla temas, qué preguntas y qué pequeña prueba pagada revelan la diferencia, cómo se comparan freelance, agencia e in-house, y qué cláusulas del contrato te protegen tras el lanzamiento.

Señales de que necesitas un plugin a medida#

Un plugin a medida justifica su coste cuando el requisito es específico de cómo opera tu negocio y ningún producto mantenido lo cubre. Contratar es el siguiente paso solo si eso es cierto.

Cuando un plugin comercial deja de encajar#

Estas son las señales habituales:

• Apilas tres o cuatro plugins y snippets para aproximar un solo flujo de trabajo, y cada actualización arriesga romper la combinación.
• Necesitas conectar con tu ERP, tu CRM o una API interna que ningún plugin soporta, o que soporta solo con un mapeo de campos rígido.
• Pagas por sitio, por usuario o por registro por una pequeña parte de lo que hace un plugin.
• Un plugin carga scripts y consultas en cada página para una función que se usa en una sola.
• Tus reglas de cumplimiento o de residencia de datos descartan enviar información a un servicio de terceros.

Las dos últimas son costes silenciosos. Explicamos cómo la acumulación de plugins crea potencia y complejidad en el problema de los plugins.

Cuando un plugin a medida es la respuesta equivocada#

No toda carencia necesita código. Si un plugin mantenido cubre la mayor parte del requisito y lo que falta es cosmético, configúralo. Si el requisito cambia cada semana, valídalo primero con un proceso manual. Si nadie de tu lado será responsable del plugin tras el lanzamiento, compras un pasivo, no un activo.

El razonamiento de construir o comprar y el desglose de costes están en el artículo anterior, así que no los repetimos aquí.

Qué entrega un buen desarrollador de plugins#

No necesitas leer PHP para juzgar la calidad. Necesitas saber qué pedir y dónde vive el estándar público. El WordPress Plugin Handbook es la referencia de cómo debe estructurarse un plugin, y un desarrollador competente puede señalarlo para cualquier decisión que cuestiones.

Estándares de código y arquitectura#

Pregunta qué estándar de código sigue el equipo. La respuesta debe ser los WordPress Coding Standards, aplicados automáticamente con PHP_CodeSniffer en el repositorio, no por buenas intenciones.

Busca un único archivo de arranque, una estructura de carpetas clara y nombres de funciones y clases con prefijo, para que el plugin nunca colisione con otros. El comportamiento debe colgar de los hooks de WordPress (actions y filters), nunca de ediciones al core o a archivos del tema. Los custom post types, las rutas REST y los bloques de Gutenberg deben usar las API documentadas.

Seguridad desde el diseño#

La seguridad es donde un desarrollador sin experiencia sale más caro. Las guías de seguridad para plugins describen la base: validar y sanear la entrada, escapar la salida, verificar nonces en las peticiones que cambian estado, comprobar las capacidades del usuario antes de actuar y usar consultas preparadas en la base de datos.

Pide al candidato que muestre dónde ocurre cada punto en un plugin que haya entregado. Para el modelo de amenazas más amplio, nuestra guía sobre ciberseguridad de aplicaciones web y prioridades OWASP aporta el contexto.

Estrategia de actualización y compatibilidad#

Un plugin no está terminado en el lanzamiento. WordPress, PHP y cada dependencia siguen avanzando. Pregunta qué versiones de WordPress y PHP soporta el plugin, cómo prueba el desarrollador contra las próximas versiones de WordPress y cómo se versionan las releases.

Si el plugin guarda datos propios, pregunta cómo se migran los cambios en la base de datos. Sin una rutina de migración versionada, la siguiente actualización puede corromper lo que creó la anterior.

Pruebas automáticas y manuales#

No todos los plugins necesitan cobertura total de tests. Las rutas críticas sí: pagos, sincronización de datos, permisos y todo lo que escriba en otro sistema. Pregunta qué se ejecuta automáticamente en cada commit, por ejemplo PHPUnit para la lógica y tests de integración contra la suite de pruebas de WordPress.

Después pregunta por las pruebas manuales: un sitio de staging con datos parecidos a producción y una revisión en la versión de PHP soportada más antigua y en la más nueva.

• El código pasa el linting de WordPress Coding Standards de forma automática en el repositorio
• Cada formulario, handler AJAX y REST comprueba un nonce o un permission callback y una capacidad
• La entrada se sanea y la salida se escapa, sin excepciones para las pantallas de administración
• Todos los nombres llevan prefijo o namespace para evitar colisiones
• La rutina de desinstalación elimina opciones, tablas propias y eventos programados
• Los tests cubren las rutas críticas y se ejecutan en cada commit
• Las releases usan versionado semántico con changelog y readme

Contratar desarrollador de plugins WordPress: freelance, agencia o in-house#

El modelo que elijas condiciona el coste, la continuidad y el riesgo más que la tarifa por hora. Una tarifa barata ligada a una sola persona sin documentación puede ser la opción más cara a tres años.

Rangos de tarifas orientativos por modelo#

Las tarifas varían con la seniority, la especialización, el alcance y la negociación. Los rangos siguientes son orientativos, no un estudio de mercado. Úsalos para contrastar propuestas, no para fijar un presupuesto.

Compara el coste total, no la tarifa. La fórmula es horas por tarifa, más el mantenimiento del primer año, más el coste del riesgo. Un ejemplo con números ilustrativos: un plugin de 120 horas y 40 horas de mantenimiento el primer año.

• Freelance a 60 USD por hora: 7.200 por la construcción más 2.400 de mantenimiento, 9.600 en total.
• Agencia a 100 USD por hora: 12.000 por la construcción más 4.000 de mantenimiento, 16.000 en total.
• Suma el riesgo: si el freelance se va sin documentación y un nuevo desarrollador necesita 80 horas para entender y reescribir partes a la misma tarifa, eso añade 4.800 y la diferencia casi se cierra.

Es aritmética, no una afirmación sobre ningún mercado. Tus números serán distintos, pero el método sirve.

Dónde falla cada modelo#

Todo modelo tiene un fallo característico. Conócelo antes de firmar.

La elección es condicional. Un freelance puede ser la decisión correcta para un plugin pequeño y de bajo riesgo, con una especificación clara y un buen repositorio. Nos inclinamos por una agencia o un equipo con retainer cuando el plugin toca ingresos, pedidos o datos de clientes y no tienes ingeniero interno.

Cómo elegir según la criticidad#

Haz una sola pregunta: ¿qué le pasa al negocio si este plugin deja de funcionar tres días? Si la respuesta es una molestia, basta un freelance verificado con un repositorio en tu cuenta. Si la respuesta son pedidos perdidos o un proceso de ventas detenido, necesitas continuidad, un SLA de soporte y más de una persona que conozca el código.

El modelo in-house tiene sentido cuando el trabajo en plugins es continuo, no ocasional. Un único plugin con pocas releases al año rara vez justifica un salario completo.

Cómo evaluar a un desarrollador de plugins WordPress#

Evaluar es una secuencia: primero evidencia, después conversación y al final una pequeña tarea pagada. Cada etapa descarta candidatos a bajo coste antes de que gastes dinero real.

Evidencia que pedir antes de la llamada#

Pide cosas que puedas inspeccionar, no una presentación:

• Un repositorio o muestra de código con historial real de commits, no una única subida.
• Uno o dos plugins en producción, con readme y changelog.
• Una referencia a la que puedas llamar sobre un proyecto en marcha desde hace al menos un año.
• Una descripción escrita de su proceso de seguridad y de pruebas.

Un candidato que no puede compartir nada de código, ni siquiera de un proyecto personal o de código abierto, te está diciendo algo.

Preguntas de entrevista que revelan profundidad#

Estas preguntas funcionan porque las respuestas superficiales se notan enseguida:

• ¿Qué plugin que entregaste sigue en producción y qué fue lo último que cambiaste en él? Una buena respuesta es específica y reciente.
• Explícame cómo aseguras un endpoint REST que modifica datos. Debes oír nonces o un permission callback, una comprobación de capacidades, entrada saneada y salida escapada.
• ¿Qué pasa con los datos cuando se desinstala el plugin? Quieres una respuesta deliberada, no un encogimiento de hombros.
• ¿Cómo gestionas una actualización de WordPress o PHP que rompe el plugin en un sitio en vivo? Quieres staging, rollback y releases versionadas.
• ¿Qué parte de este alcance te preocupa más? Los buenos desarrolladores nombran riesgos. Los débiles lo prometen todo.

Una pequeña prueba técnica pagada#

Una prueba pagada de unas pocas horas reemplaza las suposiciones por un diff que puedes leer. Págala, quédate con el resultado y no pidas trabajo gratis. Un desarrollador senior aceptará una prueba pagada justa y uno débil se resistirá.

1. Acota una tarea

   Elige una pieza real pero pequeña, como una página de ajustes con un endpoint REST que sincronice un registro con tu CRM.

2. Págala

   Acuerda una tarifa fija y un plazo de unos días. La misma tarea y la misma tarifa para cada candidato.

3. Revisa el diff contra los estándares

   Comprueba nombres, estructura y linting con los WordPress Coding Standards. Lee también los mensajes de commit.

4. Ejecuta pruebas de seguridad y casos límite

   Envía entradas incorrectas, llama al endpoint sin permiso, desactiva y desinstala el plugin, y mira qué se rompe.

5. Discute las decisiones en directo

   Pregunta por qué tomó tres decisiones concretas. El razonamiento importa más que el código exacto.

Un aprobado se ve así: linting limpio, salida escapada, comprobaciones de capacidades, un diff legible y notas honestas sobre lo que quedó fuera. Un suspenso se ve así: nonces ausentes, consultas construidas por concatenación de cadenas o código que solo funciona en el camino feliz.

Señales de alerta en las propuestas#

• Un precio cerrado sin alcance ni supuestos por escrito.
• Negarse a dar acceso al repositorio hasta el pago final.
• Entrega en un archivo zip por correo, sin control de versiones.
• Ninguna pregunta sobre tus usuarios, tus datos o los sistemas que toca el plugin.
• Afirmar que el plugin no necesitará mantenimiento.
• Sugerir plugins premium pirateados (nulled) como piezas de construcción, un vector de malware muy conocido.

Cláusulas del contrato que te protegen#

Un buen contrato es corto, específico y aburrido. Decide quién es dueño del trabajo, quién puede tocarlo y qué pasa cuando termina la relación. Esta sección es una orientación para compradores, no asesoría legal: haz que un abogado revise el contrato final en tu jurisdicción.

Propiedad intelectual y acceso al repositorio#

Insiste en una cesión escrita de la propiedad intelectual del trabajo a medida a tu empresa, efectiva con el pago, o como mínimo en una licencia exclusiva y perpetua. Excluye el código preexistente y las librerías de código abierto, que conservan sus propias licencias. WordPress es GPL, así que pide al desarrollador que liste cada componente de terceros y su licencia.

El repositorio debe vivir desde el primer día en tu propia organización de GitHub o GitLab, con el desarrollador como colaborador. Lo mismo vale para los scripts de despliegue, las cuentas de API y las credenciales: van a tu nombre, no al suyo.

Garantía, mantenimiento y SLA de soporte#

Separa tres cosas que a menudo se confunden:

• Garantía: un periodo fijo tras el lanzamiento, por ejemplo 60 días, en el que el desarrollador corrige defectos respecto al alcance acordado sin coste.
• Mantenimiento: trabajo continuo como actualizaciones de compatibilidad, actualización de dependencias y pequeñas mejoras, con una bolsa mensual de horas definida.
• SLA de soporte: tiempos de respuesta y resolución por severidad, horario de cobertura y un contacto de escalado.

Una tabla de severidades ayuda. Un checkout roto exige respuesta en horas. Un problema cosmético puede esperar a la siguiente release. Escribe tanto el tiempo de respuesta como el objetivo de resolución, porque una respuesta rápida sin solución no es soporte.

Estructura de pagos y cláusulas de salida#

Vincula los pagos a entregables aceptados en un sitio de staging, no a fechas del calendario. Retén una parte final hasta que el paquete de entrega esté completo. Añade la rescisión por conveniencia con preaviso y la obligación de entregar código fuente, documentación y credenciales en un número fijo de días.

Si el plugin procesa datos personales, añade términos de confidencialidad y una cláusula de tratamiento de datos. Esto importa para clientes españoles y europeos bajo el RGPD. Exige también que se declare cualquier subcontratista que vaya a tocar el código.

Documentación de entrega y mantenimiento a largo plazo#

La prueba real de un desarrollador llega después del lanzamiento, cuando otra persona tiene que entender el trabajo. La entrega no es una cortesía. Es un entregable que pagas y aceptas.

Qué debe incluir el paquete de entrega#

• El repositorio completo con su historial, en tu organización.
• Un readme con la instalación, los pasos de build y las variables de entorno.
• Notas de arquitectura: hooks usados, modelo de datos, tablas propias, eventos programados e integraciones externas.
• El procedimiento de despliegue y de rollback.
• Instrucciones para ejecutar los tests, además del changelog.
• Una lista de dependencias con versiones y licencias.
• Un inventario de cuentas y credenciales, y el backlog de problemas conocidos.
• Un recorrido grabado del código para el siguiente desarrollador.

La prueba práctica es simple: ¿podría un desconocido competente publicar una corrección usando solo este paquete? Si no, la entrega está incompleta.

Mantenimiento después del lanzamiento#

Los plugins se deterioran en silencio. WordPress publica versiones, las versiones de PHP llegan al fin de su vida y las librerías publican correcciones de seguridad. Un ritmo vence a las heroicidades. Esta cadencia es una sugerencia, no una estadística.

1. Semana de entrega

   Aceptar el paquete

   Verifica el repositorio, ejecuta los tests y haz que un segundo desarrollador o tu agencia lea la documentación.

2. Tras cada versión mayor de WordPress

   Ciclo de compatibilidad

   Prueba en staging contra el release candidate, corrige las deprecaciones y publica una actualización versionada.

3. Cada trimestre

   Revisión de dependencias y PHP

   Actualiza librerías, revisa el soporte de versiones de PHP y examina los logs en busca de errores silenciosos.

4. Cada año

   Revisión de arquitectura

   Confirma que el plugin sigue ajustándose al proceso de negocio y retira el código que nadie usa.

Este ritmo es la razón por la que ofrecemos un Retainer mensual y un plan Care junto a los proyectos puntuales. Puedes ver cómo funcionan en nuestra página de modalidades de trabajo. Contrates a quien contrates, pon la cadencia en el contrato para que no dependa de la buena voluntad.

Por dónde empezar#

Puedes completar la primera pasada en una semana:

1. Escribe una especificación de una página: el problema, los usuarios, los sistemas que toca y cómo sabrás que funciona.
2. Preselecciona tres candidatos de al menos dos modelos, por ejemplo un freelance y una agencia.
3. Pide la evidencia y haz las preguntas de entrevista anteriores.
4. Encarga la prueba pagada a tus dos mejores.
5. Envía el borrador del contrato, con las cláusulas de propiedad intelectual y de entrega, a tu abogado antes de que nadie empiece.

Construimos y mantenemos plugins para empresas B2B y tiendas, y nos quedamos después del lanzamiento. Mira nuestros servicios de WordPress para ver qué cubrimos, o escríbenos para dimensionar un plugin y tener una idea clara de horas, riesgos y plan de mantenimiento.

Preguntas frecuentes#