01El síntoma
WordPress resuelve bien el contenido y el ecommerce estándar. Se queda corto cuando hay reglas de negocio complejas, permisos por registro, varios consumidores de los mismos datos, procesos en segundo plano o una interfaz de producto que no es una página. Forzar ese trabajo con entradas, campos y plugins añade deuda y vuelve más frágil el mantenimiento. La alternativa es una aplicación propia, y no siempre es la respuesta correcta.
Si nadie puede explicar hoy qué pasa con un registro, quién lo aprueba y qué ocurre cuando falla, construir primero solo traslada la confusión al código. El diagnóstico tiene que dejar eso claro antes de escribir la primera línea.
02Qué cubre y qué no
Incluye
- Diagnóstico de usuarios, reglas de negocio, datos e integraciones
- Modelo de dominio: entidades, estados, permisos y transacciones
- Decisión de stack entre WordPress, Laravel, Node.js y React según el caso
- API con contrato estable para los consumidores que la necesiten
- Panel de administración adaptado a quien va a usarlo
- Integraciones con los sistemas que ya existen
- Pruebas de los flujos críticos
- Despliegue en el entorno acordado
- Entrega con repositorio y documentación
No incluye
- Una plantilla o un tema comprado con el logo cambiado
- Un plugin que se instala y se configura sin desarrollo
- Una landing barata presentada como aplicación
- Un equipo que no existe: no se promete trabajo de personas que no están
- Un precio cerrado antes de entender el alcance
- Un plazo prometido sin haberlo acordado por escrito
03Cómo lo hacemos
-
01
Diagnóstico
Se revisan usuarios, reglas, datos, integraciones y qué hace hoy el sistema. Sin eso, cualquier decisión de tecnología es una apuesta.
-
02
Decisión WordPress o aplicación
Se compara lo que WordPress ya resuelve con lo que exigiría forzarlo. Si basta WordPress, se dice; si no, se justifica la aplicación y qué piezas necesita.
-
03
Alcance y precio
Se concreta qué se construye, qué queda fuera y cuánto cuesta. El precio se cierra con el alcance delante, no antes.
-
04
Construcción
Se implementan el modelo de dominio, la API, el panel y las integraciones en incrementos revisables.
-
05
QA
Se prueban los flujos críticos, los permisos y los errores previsibles antes de desplegar.
-
06
Entrega y soporte acordado
Se entregan el repositorio, la documentación y el acceso al entorno. El mantenimiento posterior se acuerda aparte, con su alcance y su coste.
04Precio y alcance
A presupuesto; diagnóstico previo
Qué determina el costeAlcance del dominio: entidades, estados, reglas y transacciones que hay que modelar. · Número de roles y permisos: cuántos perfiles hay y si el acceso depende del registro. · Integraciones: cuántos sistemas hay que conectar y si exponen una API estable. · Migración de datos: volumen, calidad y formato de lo que ya existe. · Panel de administración: qué debe poder hacer cada perfil sin tocar el código. · Pruebas y despliegue: flujos críticos, entorno separado y puesta en marcha.
- Alcance del dominio: entidades, estados, reglas y transacciones que hay que modelar.
- Número de roles y permisos: cuántos perfiles hay y si el acceso depende del registro.
- Integraciones: cuántos sistemas hay que conectar y si exponen una API estable.
- Migración de datos: volumen, calidad y formato de lo que ya existe.
- Panel de administración: qué debe poder hacer cada perfil sin tocar el código.
- Pruebas y despliegue: flujos críticos, entorno separado y puesta en marcha.
05Plazos y respuesta
Se fija tras el diagnóstico; depende del alcance, las integraciones y los accesos. No se compromete una fecha antes de revisar el dominio, los datos y los sistemas implicados.
Política de respuesta: L–V, horario laboral de Colombia y España. Primera respuesta en 1 día laborable.
06Compatibilidad y accesos
Para empezar hacen falta la persona que conoce el proceso de punta a punta, los datos actuales con una muestra real, acceso a los sistemas o APIs que haya que integrar, un entorno de pruebas separado y quien decide el alcance. Si algún acceso no existe todavía, se anota como dependencia y se resuelve antes de construir.
07Qué evidencia entregamos
Capacidad declarada. No hay casos publicables, métricas ni certificaciones verificadas con Laravel, Node.js o React, y la evidencia por tecnología sigue pendiente. Esta página explica qué se construye y cuándo encaja, no experiencia acreditada.
08Qué recibes
| Entregable | Cuándo |
|---|---|
| Documento de alcance | Al cierre del diagnóstico |
| Arquitectura y decisiones técnicas | Antes de construir |
| Repositorio del código | En cada entrega |
| Entorno de pruebas | Antes de la primera prueba |
| Pruebas de flujos críticos | En cada entrega |
| Documentación | Al cierre |
| Entrega | Al cierre |
09Qué pasa después
Al cerrar se entrega el repositorio, la documentación y el acceso al entorno. Después quedan el mantenimiento acordado, las actualizaciones de dependencias, la revisión de errores y la monitorización que se haya contratado. No hay soporte implícito ni disponibilidad permanente: lo que se incluya se escribe en la propuesta.
Ver soporte y mantenimiento10Preguntas frecuentes
¿Cuándo deja de bastar WordPress?
Cuando el problema son reglas de negocio con estados y transacciones, permisos por registro, varios consumidores de los mismos datos, procesos en segundo plano o una interfaz de producto. Si el caso se cubre con contenido y ecommerce estándar, WordPress sigue siendo la opción por defecto: más simple y con un coste operativo más previsible.
¿Hay que usar Laravel, Node y React a la vez?
No. Se elige solo lo que el problema pide: Laravel para una aplicación PHP con panel, colas y reglas propias; Node.js para una API o un servicio de integración; React para una interfaz de aplicación que lo justifique. Añadir las tres sin necesidad duplica despliegue y mantenimiento.
¿Se puede mantener?
Sí, si el mantenimiento está previsto desde el principio: dependencias actualizadas, pruebas, migraciones reversibles, backup y un responsable de operarlo. El coste de mantener una aplicación propia es mayor que el de una web de contenido, y conviene saberlo antes de empezar.
¿Trabajas con agencias?
Sí. Se puede trabajar como capacidad externa para una agencia, con el alcance y la confidencialidad acordados y sin contactar con su cliente final salvo que lo pida. La relación comercial sigue siendo suya.
¿Cómo se fija el precio?
Después del diagnóstico, con el alcance escrito: qué se construye, qué queda fuera, qué se entrega y qué mantenimiento necesita. No se publica una cifra antes porque variaría según usuarios, integraciones y permisos, y una cifra inventada no ayuda a decidir.
¿Qué pasa con los datos actuales?
Se revisan en el diagnóstico: dónde están, en qué formato, quién los usa y qué integridad tienen. La migración se planifica con copia previa y comprobación, y solo se tocan datos reales con autorización y un plan de vuelta atrás.