WordPress o código a medida: cuál le conviene a tu negocio

Esta sección es la que casi ningún estudio que vende desarrollo a medida escribe, y es la más útil del artículo.

El patrón es casi siempre el mismo: el sitio deja de ser un folleto y empieza a formar parte de la operación.

Mientras publiques páginas y artículos, todo va bien. El problema aparece cuando necesitas que el sitio haga algo que tu negocio hace de una forma particular: un flujo de reserva con reglas propias, un panel donde tu equipo vea el estado de cada pedido, una integración con el sistema que ya usas.

En ese punto la respuesta habitual es instalar un plugin que hace el 80% de lo que necesitas, y luego otro que parchea el 20% restante. Cada uno añade código que no controlas, y todos tienen que seguir siendo compatibles entre sí en cada actualización. La complejidad deja de estar en tu sitio y pasa a estar en las costuras entre piezas de terceros.

La segunda señal es el rendimiento. Un tema comprado trae funciones para todos sus compradores, no solo para ti, y el visitante descarga todas.

Se dice que WordPress es lento y que el código a medida es rápido. Es una simplificación.

Un WordPress bien montado — un tema ligero, pocos plugins, caché e imágenes optimizadas — puede ser perfectamente rápido, y hay sitios que lo demuestran. Un desarrollo a medida hecho sin cuidado puede ser lento, cargando librerías innecesarias y bloqueando la primera pintura.

La diferencia real es el punto de partida y el techo. Con código propio empiezas en cero y añades solo lo que hace falta; con un tema empiezas con lo que el tema trae y trabajas para quitarlo. Se puede llegar rápido por los dos caminos, pero uno rema a favor.

Y lo importante: exige que te lo midan. Que te enseñen PageSpeed Insights de un sitio real que hayan entregado, no una promesa en la propuesta.

WordPress recibe muchos ataques porque es popular: automatizar un ataque contra una plataforma que usan millones de sitios sale muy rentable. La mayoría de las intrusiones no explotan WordPress en sí, sino un plugin desactualizado.

Eso hace el riesgo predecible y manejable: actualizar a tiempo, usar pocos plugins y elegirlos con criterio resuelve casi todo. Lo que pasa es que «actualizar a tiempo» requiere que alguien lo haga, y en muchos negocios ese alguien no existe.

En código a medida no hay plugins que actualizar, así que esa superficie desaparece. A cambio, los errores que existan son tuyos y solo quien escribió el código puede encontrarlos: no hay una comunidad publicando parches para tu sistema.

Ninguno de los dos es seguro por sí solo. Los dos dependen de que alguien se ocupe.

Para que la comparación sea útil hay que decir también esta parte.

Pierdes ecosistema: no hay un plugin que resuelva en diez minutos lo que se te ocurra un martes; si lo quieres, se programa y se paga. Pierdes precio de entrada: el primer proyecto cuesta más. Y asumes un riesgo de continuidad, porque la cantidad de gente capaz de retomar tu sistema es menor.

Ese último riesgo se mitiga con dos cosas concretas, y conviene exigirlas: que el código quede en un repositorio a tu nombre y que el sistema esté documentado. Si un proveedor de desarrollo a medida se resiste a cualquiera de las dos, ese es el problema, no la tecnología.

Para la mayoría de los negocios pequeños que apenas empiezan, WordPress o incluso un constructor es suficiente, y quien les venda un desarrollo a medida de dos mil dólares les está vendiendo algo que todavía no necesitan.

Para un negocio con operación, equipo y clientes que ya facturan, donde el sitio tiene que hacer algo particular y el rendimiento se traduce en dinero, el desarrollo a medida se paga.

El error caro no es elegir mal la tecnología. Es elegirla sin haber definido antes qué tiene que hacer el sitio.