Cuando vamos a crear una página web suele aparecer una decisión bastante pronto:
¿Utilizo WordPress o desarrollo una solución completamente a medida?
La pregunta parece sencilla, pero en realidad depende muchísimo del proyecto.
Para una web corporativa pequeña, construir desde cero un sistema completo puede ser totalmente innecesario.
Para una plataforma con procesos muy específicos, intentar hacer encajar todo dentro de un CMS también puede terminar generando más problemas que soluciones.
Por eso no creo que exista un ganador universal.
Lo importante es saber qué estamos construyendo, cuánto queremos invertir, qué funcionalidades necesitamos y cómo esperamos que evolucione el proyecto.
¿Qué significa desarrollo web a medida?
Un desarrollo web a medida es una solución creada específicamente para cubrir las necesidades de un proyecto.
En lugar de partir principalmente de un CMS preparado para resolver problemas comunes, diseñamos nuestra propia aplicación o arquitectura alrededor de lo que necesitamos.
Eso puede incluir:
- Backend propio.
- Base de datos personalizada.
- Panel de administración.
- APIs.
- Sistema de usuarios.
- Integraciones.
- Automatizaciones.
- Procesos internos.
- Frontend específico.
No significa necesariamente programar absolutamente todo desde cero.
Un desarrollo a medida puede utilizar frameworks, librerías y servicios externos.
Lo que cambia es que la aplicación se diseña principalmente alrededor del proyecto y no alrededor de las limitaciones de un CMS determinado.
En DSForo tenemos una sección específica de desarrollo a medida para este tipo de proyectos.
¿Qué significa utilizar WordPress?
WordPress proporciona una base ya preparada para gestionar una web.
Tenemos de serie un sistema de administración, usuarios, publicaciones, páginas, medios, permisos y muchas otras funcionalidades.
Después podemos ampliar el sistema utilizando:
- Plugins.
- Themes.
- WooCommerce.
- Código personalizado.
- APIs externas.
Esto permite lanzar muchos tipos de proyectos sin tener que desarrollar toda la infraestructura desde cero.
Y esa es una ventaja enorme.
El error de pensar que WordPress solamente sirve para blogs
WordPress nació muy relacionado con publicación de contenidos, pero actualmente puede utilizarse para muchos tipos de proyectos.
Por ejemplo:
- Webs corporativas.
- Blogs.
- Revistas.
- Tiendas.
- Portales de contenido.
- Directorios.
- Memberships.
- Landing pages.
- Pequeños marketplaces.
Con plugins y desarrollo personalizado se puede ampliar muchísimo.
La pregunta no es:
¿WordPress puede hacerlo?
Muchas veces puede.
La pregunta más interesante es:
¿WordPress es una buena arquitectura para hacerlo?
Un ejemplo sencillo
Supongamos que queremos crear la web de una asesoría.
Necesitamos:
- Inicio.
- Servicios.
- Sobre nosotros.
- Blog.
- Formulario.
- Página de contacto.
Construir desde cero un CMS, editor, gestión de imágenes y sistema de usuarios probablemente no aportaría demasiado valor.
WordPress puede resolver este caso rápidamente.
Ahora imaginemos otra aplicación.
Queremos crear una plataforma donde cientos de empresas gestionen procesos internos personalizados, estados, documentos, permisos y flujos de aprobación.
Ahí la situación cambia bastante.
Desarrollo a medida no significa automáticamente mejor
Existe cierta tendencia a pensar:
Si está hecho a medida, es mejor.
No necesariamente.
Podemos construir una aplicación a medida mal diseñada.
También podemos crear una excelente solución utilizando WordPress.
La tecnología no garantiza la calidad.
Un desarrollo propio puede tener:
- Bugs.
- Mala arquitectura.
- Problemas de seguridad.
- Código difícil de mantener.
- Rendimiento deficiente.
Por eso elegir “a medida” solamente porque parece más profesional no tiene demasiado sentido.
WordPress tampoco es automáticamente más barato
WordPress es gratuito como software, pero el proyecto no necesariamente lo será.
Podemos terminar pagando por:
- Diseño.
- Plugins.
- Desarrollo personalizado.
- Hosting.
- Mantenimiento.
- Integraciones.
- Optimización.
- Seguridad.
Una instalación sencilla puede ser económica.
Un WooCommerce muy personalizado puede convertirse en un proyecto bastante grande.
La primera pregunta: ¿qué problema estamos resolviendo?
Antes de elegir tecnología escribiría claramente qué necesita hacer el proyecto.
Por ejemplo:
Necesitamos que los clientes puedan registrarse.
Cada cliente tendrá diferentes permisos.
Podrá generar presupuestos.
Los presupuestos pasan por varios estados.
Hay que sincronizarlos con un ERP.
Necesitamos informes personalizados.
Ahora podemos evaluar si un CMS existente encaja bien o si estamos intentando forzarlo.
No elegiría tecnología antes de definir funcionalidades
Un error bastante habitual es decidir:
Lo vamos a hacer con WordPress.
antes de saber qué vamos a construir.
O lo contrario:
Quiero que sea a medida.
sin tener todavía requisitos.
Primero definiría el producto.
Después elegiría la tecnología.
No al revés.
Cuándo WordPress suele tener ventaja
WordPress puede ser especialmente interesante cuando el proyecto gira principalmente alrededor de contenido.
Por ejemplo:
- Artículos.
- Páginas.
- Categorías.
- Productos.
- Imágenes.
- Formularios.
También tiene sentido cuando necesitamos lanzar rápidamente y existen soluciones maduras para la mayoría de nuestras necesidades.
El ecosistema de WordPress ahorra mucho trabajo
Esta es una de sus mayores ventajas.
Supongamos que necesitamos:
- SEO.
- Formularios.
- Caché.
- Sitemap.
- Gestión de usuarios.
- Ecommerce.
- Backups.
Existen soluciones ya desarrolladas para multitud de casos.
En un proyecto a medida tendríamos que desarrollar, integrar o contratar muchas de esas funcionalidades.
Eso cuesta tiempo.
Y el tiempo cuesta dinero.
Pero demasiados plugins también pueden convertirse en un problema
La facilidad para instalar funcionalidades puede generar otro extremo.
Necesitamos una característica.
Instalamos un plugin.
Después otra.
Otro plugin.
Terminamos con una web que depende de decenas de extensiones de diferentes desarrolladores.
Esto puede introducir:
- Conflictos.
- Actualizaciones.
- Dependencias.
- Problemas de rendimiento.
- Riesgos de seguridad.
No existe un número mágico de plugins malo.
Importa qué hacen y cómo están desarrollados.
Si ese ecosistema empieza a afectar al rendimiento, puede ser útil revisar esta guía sobre WordPress lento y cómo encontrar el cuello de botella.
¿Cuándo empieza a tener sentido un desarrollo a medida?
Lo consideraría cuando las necesidades centrales del proyecto son muy específicas.
Por ejemplo:
- Lógica de negocio compleja.
- Flujos internos personalizados.
- Permisos especiales.
- Procesamiento de datos.
- Integraciones profundas.
- Aplicaciones SaaS.
- Herramientas internas.
- Plataformas con modelos de datos poco convencionales.
Aquí controlar la arquitectura desde el principio puede ser una ventaja importante.
Una web y una aplicación web no siempre plantean el mismo problema
Esta distinción ayuda bastante.
Una web corporativa puede estar principalmente orientada a mostrar información.
Una aplicación web puede estar orientada a realizar procesos.
Por ejemplo:
- Gestionar proyectos.
- Crear facturas.
- Editar documentos.
- Procesar pedidos.
- Analizar datos.
- Coordinar usuarios.
Cuanto más pesa la lógica de negocio, más interesante puede resultar estudiar una arquitectura personalizada.
¿Qué es la lógica de negocio?
Es el conjunto de reglas que hacen funcionar nuestro servicio.
Por ejemplo, en una plataforma de reservas:
No se puede reservar una habitación ocupada.
Una reserva cancelada libera disponibilidad.
Determinados usuarios tienen tarifas especiales.
El pago debe confirmarse antes de cierto paso.
Estas reglas forman parte del negocio.
En aplicaciones complejas pueden terminar siendo mucho más importantes que las páginas visibles.
WordPress puede tener lógica personalizada
Esto también es importante.
No tenemos que elegir necesariamente entre:
WordPress puro
y:
todo programado desde cero.
Podemos desarrollar plugins propios que implementen lógica específica.
Esto permite utilizar WordPress como base y añadir únicamente la funcionalidad que necesitamos.
Para muchos proyectos ese enfoque híbrido puede funcionar muy bien.
¿Hasta dónde personalizar WordPress?
Aquí es donde conviene analizar el coste a largo plazo.
Si para convertir WordPress en nuestra aplicación necesitamos:
- Modificar constantemente su comportamiento.
- Mantener muchos plugins propios.
- Alterar modelos de datos.
- Crear multitud de excepciones.
- Evitar funcionalidades centrales.
puede llegar un momento donde estamos luchando contra la plataforma.
Entonces merece la pena preguntarse si una arquitectura propia sería más sencilla.
No intentaría convertir WordPress en cualquier cosa
Técnicamente podemos conseguir resultados sorprendentes.
Pero que algo sea posible no significa que sea la mejor solución.
Si tenemos que instalar doce plugins y desarrollar otros seis para imitar el comportamiento de una aplicación completamente diferente, quizá estemos partiendo de la base equivocada.
Tiempo de lanzamiento
WordPress suele tener una ventaja clara cuando necesitamos lanzar rápidamente un proyecto relativamente estándar.
Podemos montar una base funcional en poco tiempo.
En un desarrollo a medida tenemos que tomar muchas decisiones.
Por ejemplo:
- Arquitectura.
- Autenticación.
- Panel.
- Base de datos.
- Seguridad.
- Routing.
- Permisos.
Eso aumenta el tiempo inicial.
Pero velocidad inicial no es lo mismo que velocidad futura
WordPress puede permitirnos lanzar en una semana algo que a medida tarda meses.
Fantástico.
Pero si después cada nueva funcionalidad necesita varios parches porque la arquitectura no encaja, ese ahorro inicial puede desaparecer.
También ocurre al revés.
Podemos gastar seis meses desarrollando a medida una plataforma que WordPress habría resuelto suficientemente bien desde el primer día.
Por eso hay que mirar el ciclo completo.
Coste inicial
En general, un proyecto a medida suele necesitar una inversión inicial mayor.
Estamos pagando muchas horas de:
- Análisis.
- Diseño.
- Programación.
- Pruebas.
- Arquitectura.
WordPress puede reducir bastante esa inversión reutilizando componentes existentes.
Especialmente en proyectos estándar.
Coste de mantenimiento
Aquí la situación es menos evidente.
WordPress necesita mantenimiento:
- Core.
- Plugins.
- Theme.
- Compatibilidad.
- Seguridad.
Un desarrollo a medida también necesita mantenimiento:
- Dependencias.
- Framework.
- Servidor.
- Bugs.
- Nuevas versiones.
- Seguridad.
No existe software que podamos publicar y olvidar para siempre.
La diferencia está en quién mantiene cada pieza
En WordPress dependemos parcialmente del ecosistema.
Un plugin puede actualizarse.
También puede desaparecer.
En desarrollo propio tenemos más control.
Pero también somos responsables del código.
Si nuestro desarrollador desaparece y nadie entiende el proyecto, tenemos otro tipo de dependencia.
Dependencia de proveedores
Esto debería evaluarse desde el principio.
Podemos depender de:
- Plugins.
- SaaS.
- APIs.
- Frameworks.
- Agencias.
- Desarrolladores.
Nunca eliminaremos todas las dependencias.
El objetivo debería ser comprender cuáles son críticas.
Código propietario
Si contratamos un desarrollo a medida, aclararía contractualmente aspectos como:
- Propiedad del código.
- Acceso al repositorio.
- Documentación.
- Infraestructura.
- Credenciales.
- Dependencias.
No me gustaría descubrir años después que la empresa ha pagado por una aplicación pero no tiene acceso real a su propio código.
Documentación
Una solución a medida necesita documentación especialmente si varias personas van a mantenerla.
Como mínimo querría conocer:
- Cómo instalarla.
- Cómo desplegarla.
- Qué servicios utiliza.
- Variables de entorno.
- Estructura principal.
- Dependencias.
- Backups.
El código por sí solo no siempre explica suficientemente cómo funciona un sistema.
¿Qué ocurre cuando cambia el desarrollador?
Es una prueba muy interesante.
¿Puede otra persona entrar en el proyecto y entenderlo?
Si solamente quien lo creó sabe cómo funciona, tenemos un problema de mantenimiento.
Buenas prácticas, documentación y control de versiones reducen esa dependencia.
Rendimiento
Un desarrollo a medida puede ser muy eficiente porque implementamos únicamente lo necesario.
Pero no está garantizado.
WordPress puede rendir muy bien con una arquitectura adecuada.
Y una aplicación propia puede realizar consultas terribles.
No compararía rendimiento basándome únicamente en el nombre de la tecnología.
Mediría.
Código innecesario
Una ventaja potencial del desarrollo propio es evitar cargar funcionalidades que nunca utilizamos.
Construimos exactamente lo necesario.
Sin embargo, esto también significa que debemos desarrollar todo lo que sí necesitamos.
A veces un CMS contiene funcionalidades que no usamos.
Pero ese coste puede ser aceptable frente al tiempo de recrearlas.
Escalabilidad
Otra palabra que suele utilizarse demasiado pronto.
Una aplicación a medida puede diseñarse pensando en crecimiento.
Pero primero necesitamos saber qué significa crecer.
¿Más usuarios?
¿Más datos?
¿Más tráfico?
¿Más operaciones?
¿Más países?
¿Más equipos internos?
Cada tipo de crecimiento genera problemas diferentes.
No optimizaría para millones de usuarios antes de tener cien
Es fácil diseñar una arquitectura extremadamente compleja pensando en un futuro hipotético.
Microservicios.
Colas.
Clusters.
Decenas de servicios.
Y todavía no tenemos clientes.
Cada componente introduce mantenimiento.
Construiría una solución que permita evolucionar, pero sin añadir complejidad innecesaria.
Una buena arquitectura puede empezar sencilla
Desarrollo a medida no significa que debamos crear diez servicios independientes.
Una aplicación monolítica bien estructurada puede ser perfectamente válida para muchos proyectos.
Si algún día determinadas partes necesitan separarse, ya evaluaremos esa necesidad.
La simplicidad tiene muchísimo valor.
Seguridad
Aquí tampoco existe un ganador automático.
WordPress es un objetivo muy conocido porque tiene una enorme base instalada.
Eso significa que existen ataques automatizados dirigidos a plugins, themes y configuraciones vulnerables.
Pero también existe un ecosistema enorme de actualizaciones y conocimiento.
Un sistema propio no es invisible
A veces escuchamos:
Como nuestro CMS es propio, los hackers no saben cómo atacarlo.
Eso genera una falsa sensación de seguridad.
Si nuestra aplicación tiene:
- SQL injection.
- XSS.
- Mala autenticación.
- Permisos incorrectos.
puede ser vulnerable independientemente de que nadie conozca su nombre.
La seguridad depende del código y la arquitectura.
Autenticación
Implementar correctamente sistemas de usuarios es más difícil de lo que parece.
No basta con crear:
email + contraseña.
Tenemos que pensar en:
- Hash de contraseñas.
- Recuperación.
- Sesiones.
- Permisos.
- Rate limits.
- MFA cuando corresponda.
- Expiración.
En un desarrollo propio aprovecharía frameworks y componentes maduros en lugar de inventar sistemas criptográficos.
Base de datos
WordPress ya tiene un modelo de datos y convenciones determinadas.
Para contenidos estándar funciona muy bien.
En un desarrollo a medida podemos diseñar el modelo específicamente para nuestro negocio.
Esto puede proporcionar mucha flexibilidad.
Especialmente cuando tenemos entidades complejas.
Ejemplo de modelo propio
Supongamos una plataforma para talleres.
Podemos tener entidades como:
- Taller.
- Mecánico.
- Cliente.
- Vehículo.
- Reparación.
- Presupuesto.
- Pieza.
Y relaciones específicas entre ellas.
Diseñar directamente una base de datos alrededor de esos conceptos puede resultar más natural que intentar representarlo todo mediante publicaciones y metadatos genéricos.
Pero una base de datos propia también necesita diseño
No basta con crear tablas.
Tenemos que pensar en:
- Relaciones.
- Índices.
- Integridad.
- Consultas.
- Migraciones.
- Backups.
Un mal modelo puede perseguirnos durante años.
Integraciones
Aquí el desarrollo a medida puede resultar especialmente interesante.
Si nuestra aplicación necesita hablar con:
- ERP.
- CRM.
- Pagos.
- Logística.
- IA.
- Facturación.
- Aplicaciones móviles.
podemos diseñar directamente esas integraciones.
Las APIs desempeñan un papel central en muchos de estos proyectos.
Si alguien empieza desde cero con este concepto, tenemos una guía sobre qué es una API y cómo funciona.
WordPress también puede integrarse mediante APIs
Por supuesto.
Podemos utilizar APIs propias de WordPress, plugins e integraciones personalizadas.
No estamos limitados a instalar plugins disponibles públicamente.
Un desarrollador puede crear una integración específica.
La cuestión vuelve a ser cuánto estamos personalizando la plataforma.
Panel de administración
WordPress nos proporciona un panel completo desde el comienzo.
Eso ahorra una cantidad enorme de desarrollo.
En una aplicación propia tendremos que decidir:
¿Quién administra qué?
Quizá necesitemos crear:
- Gestión de usuarios.
- Listados.
- Formularios.
- Filtros.
- Permisos.
- Estadísticas.
Todo eso requiere trabajo.
Pero podemos crear un panel exactamente como necesita el negocio
Esa es la ventaja.
No tenemos que adaptar el flujo interno de la empresa al panel de un CMS.
Podemos diseñarlo alrededor de las tareas reales.
Por ejemplo:
Pedidos pendientes de revisión
en lugar de:
Entradas → tipo personalizado → filtros → metacampos.
Para usuarios internos, una interfaz adaptada puede ahorrar muchísimo tiempo.
Experiencia del usuario interno
Esta parte se olvida bastante.
No solamente debemos pensar en los visitantes.
Si veinte empleados utilizan el sistema ocho horas al día, pequeños problemas de interfaz pueden convertirse en miles de horas perdidas.
En aplicaciones empresariales, optimizar esos flujos puede justificar un desarrollo personalizado.
SEO
Para una web donde el SEO tiene un papel central, WordPress ofrece muchas ventajas prácticas.
Gestión de contenidos.
URLs.
Plugins SEO.
Sitemaps.
Metadatos.
Edición.
Todo está bastante resuelto.
Pero un desarrollo a medida puede ser igualmente bueno para SEO si se implementa correctamente.
El problema es olvidarse del SEO durante el desarrollo
He visto proyectos donde primero se construye la aplicación y después alguien pregunta:
¿Cómo añadimos ahora títulos SEO, canonical y sitemap?
Estas decisiones deberían contemplarse antes.
Especialmente si el tráfico orgánico es importante para el negocio.
Necesidades SEO básicas
En una web a medida pensaría desde el inicio en cuestiones como:
- Titles.
- Descripciones.
- Canonical.
- Robots.
- Sitemap.
- Status HTTP.
- Redirecciones.
- Datos estructurados cuando proceda.
- Rendimiento.
- Arquitectura interna.
No asumiría que el framework se encargará automáticamente de todo.
Contenido editable
Otra pregunta importante:
¿Quién va a modificar el contenido?
Si cada cambio de texto necesita que intervenga un programador, posiblemente tendremos un problema.
Podemos construir un panel propio.
O utilizar un CMS desacoplado.
O integrar determinadas partes con WordPress.
No todo tiene que ser completamente rígido.
Headless CMS
Existe otra posibilidad intermedia.
Podemos utilizar un CMS para gestionar contenido y una aplicación diferente para mostrarlo.
En una arquitectura headless, el contenido se consume normalmente mediante APIs.
Esto puede proporcionar flexibilidad.
Pero también añade complejidad.
No lo elegiría solamente porque sea una arquitectura moderna.
WordPress headless
Incluso WordPress puede utilizarse como backend de contenido mientras otra tecnología genera el frontend.
Esto puede tener sentido en determinados proyectos.
Pero perdemos parte de la simplicidad tradicional de WordPress.
Ahora tenemos que mantener:
WordPress + frontend separado + integración entre ambos.
Tiene que existir una razón.
Aplicación móvil
Si sabemos desde el comienzo que tendremos:
- Web.
- App Android.
- App iOS.
puede resultar interesante diseñar un backend central mediante API.
Todos los clientes consumen los mismos servicios.
Esto puede ser más natural dentro de una arquitectura de aplicación personalizada.
Ecommerce
WooCommerce resuelve rápidamente muchísimos problemas de una tienda.
Productos.
Carrito.
Checkout.
Pedidos.
Impuestos.
Extensiones.
Para un ecommerce estándar puede ser una opción muy eficiente.
Desarrollar todo eso desde cero sería un proyecto considerable.
¿Cuándo una tienda a medida?
Lo estudiaría cuando el ecommerce tiene reglas muy particulares.
Por ejemplo:
- Configuradores complejos.
- Procesos B2B.
- Precios personalizados.
- Catálogos enormes.
- Integración profunda con sistemas internos.
- Flujos logísticos especiales.
Incluso ahí podríamos integrar una plataforma ecommerce existente.
No tenemos que reinventar pagos, pedidos y todo el ecosistema si no aporta valor.
No desarrollaría un carrito desde cero por orgullo técnico
Este principio lo aplicaría a muchas áreas.
Si existe una solución madura que resuelve exactamente nuestro problema, reutilizarla puede ser una excelente decisión.
El valor de nuestro negocio probablemente no está en escribir nuestro propio sistema para calcular un subtotal.
Está en la funcionalidad que nos diferencia.
Construir lo que nos diferencia
Este es uno de mis criterios favoritos.
Utilizaría herramientas existentes para problemas genéricos.
Y desarrollaría a medida aquello que realmente hace especial al proyecto.
Por ejemplo:
login genérico → componente existente.
proceso único del negocio → desarrollo propio.
Eso permite concentrar recursos.
API propia
En aplicaciones a medida puede ser útil diseñar una API para separar responsabilidades.
Por ejemplo:
frontend → API → backend → base de datos
Esto también permite que en el futuro otros clientes consuman esa misma lógica.
Pero una API añade cuestiones como autenticación, versionado y seguridad.
No la construiría sin necesidad.
Desarrollo a medida y automatización
Una ventaja importante aparece cuando queremos automatizar procesos internos.
Por ejemplo:
entra pedido
↓
validamos condiciones
↓
consultamos proveedor
↓
generamos documento
↓
enviamos información al ERP
↓
avisamos al cliente
Cuando toda esta lógica es central para el negocio, una aplicación diseñada alrededor del flujo puede ahorrar mucho trabajo manual.
¿Qué lenguaje utilizar?
Otra pregunta frecuente.
PHP.
JavaScript.
Python.
Java.
C#.
Go.
No existe un lenguaje universalmente mejor.
Elegiría según:
- Equipo.
- Ecosistema.
- Proyecto.
- Infraestructura.
- Mantenimiento.
- Disponibilidad de profesionales.
Una tecnología espectacular que nadie de nuestro equipo sabe mantener puede ser una mala elección.
No elegiría lenguaje por moda
Cada cierto tiempo una tecnología se vuelve extremadamente popular.
Eso no significa que nuestros requisitos hayan cambiado.
Si necesitamos construir una aplicación empresarial que debe mantenerse diez años, valoraría especialmente estabilidad y disponibilidad de desarrolladores.
No solamente tendencias.
Frameworks
Un desarrollo a medida no suele significar escribir todas las herramientas básicas nosotros mismos.
Podemos utilizar frameworks que ya resuelven:
- Routing.
- Seguridad.
- Base de datos.
- Validación.
- Sesiones.
- Plantillas.
Esto permite concentrarnos en nuestra lógica.
La elección del framework también debe contemplar mantenimiento a largo plazo.
Código sin framework tampoco es automáticamente más ligero
Podemos pensar:
Si no uso framework, controlo todo.
Sí.
Pero ahora debemos implementar correctamente muchas cosas que el framework ya resolvía.
En proyectos reales normalmente existe un equilibrio entre control y reutilización.
MVP
Antes de invertir una gran cantidad en desarrollo a medida, intentaría validar el producto.
Un MVP o versión mínima viable puede ayudarnos a comprobar:
¿la gente realmente necesita esto?
Podemos utilizar herramientas existentes para validar una idea antes de construir una plataforma completa.
WordPress puede servir para validar
Incluso si sabemos que la versión definitiva podría necesitar desarrollo propio, WordPress puede permitirnos lanzar una primera versión rápidamente.
Si conseguimos usuarios y validamos el modelo, tendremos mejores datos para diseñar la siguiente etapa.
Es mucho mejor que gastar un año desarrollando algo que nadie quiere.
Pero cuidado con construir un MVP imposible de migrar
Si sabemos que determinadas decisiones son temporales, documentaría claramente las limitaciones.
No intentaría convertir el prototipo en producción eterna simplemente porque:
ya funciona.
A veces llega un momento en que debemos reconstruir partes.
Migrar no significa fracasar
Una arquitectura que funciona para 100 usuarios quizá no sea apropiada para 1 millón.
Eso no significa que fuese una mala decisión inicial.
Podría haber permitido validar el negocio con una inversión mínima.
La arquitectura adecuada depende de la etapa.
Presupuesto
Esta parte es inevitable.
Con 1.000 euros no podemos esperar el mismo desarrollo a medida que con 100.000.
Cuando el presupuesto es limitado, utilizar sistemas existentes permite destinar recursos a:
- Contenido.
- Marketing.
- Diseño.
- Captación.
Construir tecnología es solamente una parte del negocio.
Coste de oportunidad
Cada mes que pasamos desarrollando también tiene un coste.
Quizá podríamos haber estado:
- Vendiendo.
- Consiguiendo usuarios.
- Aprendiendo del mercado.
Por eso no valoraría únicamente el coste de desarrollo.
También cuánto tardamos en poder utilizar el producto.
Equipo interno
Si tenemos desarrolladores internos, un proyecto a medida puede resultar más viable.
Podemos evolucionarlo continuamente.
Si dependemos completamente de una agencia externa para cada modificación, el modelo económico cambia.
Ninguna situación es necesariamente mala.
Pero debemos conocerla antes de empezar.
Qué preguntaría a una agencia de desarrollo
Antes de contratar preguntaría:
- ¿Qué tecnologías utilizarán?
- ¿Por qué?
- ¿Quién será propietario del código?
- ¿Tendremos repositorio?
- ¿Cómo se realizan despliegues?
- ¿Qué documentación entregan?
- ¿Qué mantenimiento necesita?
- ¿Cómo funcionan los backups?
- ¿Qué incluye el soporte?
- ¿Cómo se presupuestan evolutivos?
Cuanto más importante sea el proyecto, más importante es aclararlo.
Desconfío de presupuestos donde solamente aparece “web a medida”
Querría saber qué significa realmente.
A veces “a medida” significa:
WordPress + theme personalizado.
Otras veces significa:
aplicación desarrollada específicamente desde cero sobre un framework.
Ambas opciones pueden ser válidas.
Pero no son el mismo servicio.
También preguntaría por las dependencias
¿Utilizamos servicios externos?
¿Licencias?
¿APIs de pago?
¿Software propietario?
¿Plugins?
¿Quién paga esas renovaciones?
Un proyecto puede tener un coste inicial aceptable y después acumular gastos recurrentes importantes.
Propiedad de los datos
Más importante incluso que el código.
Debemos poder acceder y exportar nuestros datos.
Clientes.
Pedidos.
Contenido.
Documentos.
Una arquitectura que nos encierra completamente en un proveedor puede convertirse en un problema.
Exportación
Pensaría desde el principio:
Si mañana quiero cambiar de sistema, ¿puedo sacar mis datos?
No tiene que ser un botón perfecto para exportar toda la aplicación.
Pero sí debemos conocer cómo acceder a nuestra propia información.
Backups
Tanto WordPress como una aplicación propia necesitan copias.
Para un desarrollo personalizado debemos saber exactamente qué hay que respaldar.
Por ejemplo:
- Base de datos.
- Archivos subidos.
- Configuración.
- Código, aunque debería estar en control de versiones.
- Servicios adicionales.
Y además probar restauraciones.
Entornos separados
En un proyecto serio intentaría mantener al menos alguna separación entre desarrollo y producción.
No querría que cada prueba se hiciese sobre los datos reales.
Un entorno de staging puede ayudar a validar cambios antes de publicarlos.
WordPress también se beneficia muchísimo de esta práctica.
Control de versiones
Para desarrollo a medida utilizaría Git prácticamente desde el principio.
Nos permite conocer:
- Qué cambió.
- Quién lo cambió.
- Cuándo.
- Por qué.
También facilita recuperar versiones y colaborar.
No confiaría en archivos llamados:
final2_bueno_ahorasi.zip
como sistema de versiones.
Pruebas
Cuanto más importante sea una aplicación, más valor tiene automatizar determinadas pruebas.
Por ejemplo:
Un usuario no puede ver datos de otra empresa.
Un pedido pagado no puede volver a cobrarse.
Un cálculo siempre produce el resultado esperado.
Las pruebas reducen la posibilidad de romper funcionalidad existente al añadir cambios.
El mantenimiento nunca termina
Un proyecto digital evoluciona.
Cambian navegadores.
Cambian servicios.
Cambian APIs.
Cambian necesidades del negocio.
Por eso elegir arquitectura significa también elegir cómo queremos mantener el proyecto durante los próximos años.
¿Qué escogería para una web corporativa?
Probablemente WordPress u otro CMS similar si los requisitos son estándar.
No desarrollaría desde cero gestión de páginas y noticias salvo que exista un motivo claro.
¿Qué escogería para un blog?
WordPress encaja muy bien.
El sistema está especialmente preparado para publicación y gestión de contenidos.
Un desarrollo propio solamente tendría sentido si el proyecto necesita funcionalidades muy específicas.
¿Qué escogería para una tienda?
Para un ecommerce estándar empezaría evaluando soluciones ya existentes.
WooCommerce puede ser una.
También existen otras plataformas.
Solamente desarrollaría a medida las partes que realmente lo justifican.
¿Qué escogería para un SaaS?
Aquí estudiaría seriamente desarrollo a medida.
Un SaaS suele tener una lógica propia que constituye el producto.
Usuarios.
Planes.
Permisos.
Datos.
Procesos.
Ahí estamos construyendo una aplicación, no solamente una página informativa.
¿Qué escogería para un directorio?
Depende.
Un directorio sencillo puede resolverse perfectamente sobre un CMS.
Uno con sistemas avanzados de búsqueda, pagos, algoritmos, cuentas profesionales y enormes volúmenes puede requerir una arquitectura más específica.
No decidiría solamente por la palabra “directorio”.
¿Qué escogería para una herramienta SEO?
Probablemente desarrollo a medida si la herramienta realiza análisis propios, procesa datos y necesita integraciones específicas.
Aquí el valor está precisamente en la lógica.
Podríamos utilizar WordPress para una parte pública de contenidos y una aplicación independiente para la herramienta.
No es obligatorio que todo el dominio utilice exactamente la misma tecnología.
Arquitectura híbrida
Esta opción se utiliza bastante y a veces es la más lógica.
Por ejemplo:
WordPress para blog y contenido.
Aplicación propia para zona privada.
Podríamos tener:
www.ejemplo.com
para la web.
Y:
app.ejemplo.com
para la aplicación.
Cada parte utiliza la tecnología que mejor encaja.
No existe obligación de elegir una sola tecnología
Este punto merece repetirse.
Podemos combinar sistemas.
Lo importante es gestionar correctamente:
- Usuarios.
- Datos.
- Diseño.
- Integraciones.
- SEO.
La arquitectura debe servir al producto.
Checklist rápido para decidir
Yo respondería estas preguntas:
1. ¿El proyecto es principalmente contenido o aplicación?
2. ¿Necesitamos funcionalidades poco habituales?
3. ¿Existe una solución madura que ya resuelva el 80 %?
4. ¿Cuánto presupuesto tenemos?
5. ¿Cuánto tiempo tenemos para lanzar?
6. ¿Quién mantendrá el sistema?
7. ¿Necesitamos integraciones complejas?
8. ¿Esperamos cambios frecuentes en la lógica?
9. ¿Necesitamos control total sobre los datos y arquitectura?
10. ¿La tecnología aporta ventaja competitiva?
Las respuestas suelen indicar bastante bien hacia dónde movernos.
Mi regla general
Intentaría no desarrollar desde cero aquello que no diferencia al negocio.
Para problemas comunes utilizaría herramientas maduras.
Para problemas específicos donde está el verdadero valor del proyecto, estudiaría desarrollo propio.
Esto suele permitir equilibrar coste, velocidad y flexibilidad.
Conclusión
Elegir entre WordPress y desarrollo web a medida no debería convertirse en una discusión sobre cuál tecnología es “mejor”.
WordPress puede ser excelente para proyectos donde necesitamos lanzar rápidamente y gestionar contenido utilizando un ecosistema muy maduro.
El desarrollo a medida puede ser una mejor opción cuando tenemos lógica de negocio propia, procesos específicos o necesitamos un nivel de control que un CMS empieza a dificultar.
Y muchas veces la mejor solución puede estar en el medio:
utilizar plataformas existentes para las partes estándar y desarrollar solamente aquello que realmente necesita ser personalizado.
Antes de elegir preguntaría:
¿Qué problema concreto resolverá esta tecnología mejor que las alternativas?
Si no tenemos una respuesta clara, probablemente estamos eligiendo por preferencias técnicas y no por necesidades del proyecto.
¿Qué preferís vosotros para nuevos proyectos: WordPress, desarrollo completamente a medida o una solución híbrida? ¿En qué momento creéis que WordPress empieza a quedarse corto?
