Wordpress
Una de las dudas más habituales de los clientes: ¿hourly o bloque fijo? Sobre todo cuando el proyecto está en el rango de 80–140 horas: ya no es «un trabajo de fin de semana», pero tampoco un gran portal corporativo.
En este artículo explico cuándo conviene más el hourly, cuándo el bloque/precio fijo, cómo trabajo con el rango de 80–140 horas y cómo mantengo la transparencia con el cliente (informes, riesgos y comunicación sobre sobrecostes o ahorros).
Cuándo conviene más el hourly
El hourly (pago por horas) no es «incertidumbre»: es una herramienta para proyectos con muchas incógnitas.
El hourly tiene sentido cuando:
El alcance no está claro. Por ejemplo: «Queremos un rediseño + un catálogo nuevo, pero aún no sabemos cuántos filtros habrá, qué bloques ni qué lógica».
Hay mucha investigación y experimentación. Nuevas integraciones, lógica no estándar, calculadoras complejas, embudos personalizados.
Es muy probable que cambien los requisitos. El cliente todavía no tiene del todo claro qué quiere, o los procesos de negocio pueden cambiar durante el proyecto.
Ventajas del hourly:
Pagas por el trabajo real, no por un alcance «adivinado».
Es más fácil cambiar prioridades: si algo deja de ser relevante en el proceso, simplemente no hacemos esas tareas.
Menos riesgo de que el desarrollador «meta todos los riesgos posibles en el precio» y el proyecto salga más caro de lo necesario.
Desventajas del hourly:
Al cliente le cuesta más planificar el presupuesto: no hay una cifra final clara al inicio.
Hace falta confianza e informes transparentes: cuántas horas se han usado, en qué y cuántas quedan.
Cuándo conviene más el bloque / precio fijo
Un bloque (precio fijo por un paquete de trabajo) significa que acordamos un alcance claro y fijamos el precio.
El bloque tiene sentido cuando:
El alcance está bien descrito. Por ejemplo: «Landing + 5 páginas internas», «Sitio corporativo: inicio, servicios, sobre nosotros, blog, contacto», «Catálogo WooCommerce + checkout».
Las tareas son repetibles. Mejoras empaquetadas, una serie de páginas similares, una integración típica que ya se ha hecho antes.
Al cliente le importan la previsibilidad y la fecha límite. Cuando el presupuesto ya está aprobado dentro de la empresa y no se puede superar.
Ventajas del bloque:
Una cifra clara al inicio: más fácil planificar el presupuesto.
Menos necesidad de entrar en cada detalle: hay un listado de trabajos y un resultado definido.
Cómodo para la aprobación interna: «Tenemos presupuesto X, el proyecto cuesta Y».
Desventajas del bloque:
El desarrollador incluye riesgos en el precio: si algo sale mal, necesita estar seguro de no trabajar a pérdidas.
Los cambios de requisitos suelen implicar acuerdos o pagos extra: «Esto ya no entra en el bloque».
Si el alcance real resulta menor, el cliente igual paga el fijo.
Cómo trabajo con el rango de 80–140 horas
El rango de 80–140 horas es un proyecto típico: un sitio corporativo pequeño, un catálogo de servicios, WooCommerce al inicio o el rediseño de un sitio existente.
Cómo estimo el alcance:
Auditoría / briefing. Reviso los diseños (si los hay), la descripción funcional y ejemplos de referencia.
Desglose por etapas. Por ejemplo:
Auditoría y estructura: 8–12 h
Maquetación de plantillas clave: 20–30 h
Integración en WordPress: 20–30 h
WooCommerce / catálogo: 20–40 h
Testing, correcciones, lanzamiento: 12–20 h
Total: aproximadamente 80–132 h.
Registro de riesgos. Indico dónde pueden aparecer horas extra: filtros complejos, integraciones a medida, gran volumen de contenido.
Cómo comunico el rango al cliente:
Doy un rango, no una sola cifra: «Aproximadamente 80–140 horas, según la complejidad de los filtros y el volumen de contenido».
Explico de qué depende el techo: por ejemplo, «si los filtros son simples — más cerca de 80; si son a medida con lógica — más cerca de 140».
Propongo prioridades: qué hacemos primero y qué se puede dejar para una segunda fase si el presupuesto es limitado.
Transparencia para el cliente: informes, riesgos, sobrecostes
Independientemente del modelo (hourly o bloque), para mí es importante que el cliente entienda a dónde van las horas y el presupuesto.
Cómo es el informe de horas
En proyectos hourly entrego:
Un informe corto (semanal o por etapa):
Cuántas horas se han usado.
En qué tareas (por ejemplo: «maquetación de la home», «integración del formulario», «configuración de filtros»).
Cuántas horas quedan dentro del presupuesto.
Si hace falta — un desglose más detallado por etapas.
No es «espionaje»: es una herramienta de confianza. El cliente ve el progreso y puede ajustar prioridades.
Cómo comunico los riesgos
Si durante el trabajo veo que:
La tarea es más compleja de lo que parecía al inicio.
Aparecen requisitos nuevos que no se habían hablado.
El contenido o los diseños requieren más trabajo del previsto.
Escribo de inmediato al cliente/PM:
Qué ha cambiado.
Cómo afecta a las horas (por ejemplo: «+10–15 h sobre la estimación»).
Qué opciones hay: simplificar, pasar a una segunda fase o ampliar presupuesto.
Sobrecostes vs ahorros
Sobrecostes:
Si el alcance resulta mayor, no me callo hasta la fecha límite: aviso con antelación.
Propongo opciones: qué simplificar, qué posponer, dónde ahorrar.
Ahorros:
Si el alcance resulta menor (por ejemplo, 70 horas en vez de 80–100), el cliente paga las horas reales (en hourly) o acordamos cómo aplicar el ahorro a etapas posteriores (en bloque).
Lo principal: ninguna sorpresa «al final», cuando llega la factura.
Ejemplo: sitio corporativo con catálogo de servicios
Datos de partida:
Sitio principal de la empresa, 6–8 páginas clave.
Catálogo de servicios con filtros (servicio, sector, región).
Formularios de solicitud, integración con email/CRM.
Diseños en Figma, pero sin versiones móviles completas.
Estimación inicial: 80–120 horas.
Cómo lo divido por etapas:
Auditoría de diseños, aclaración de requisitos: 8–10 h
Maquetación de plantillas clave (inicio, servicios, catálogo, artículo): 25–35 h
Integración en WordPress (ACF, tipos de contenido personalizados): 20–30 h
Catálogo + filtros: 20–35 h
Formularios + integraciones: 6–10 h
Testing, correcciones, lanzamiento: 10–15 h
Total: 89–135 horas.
Qué puede aumentar el alcance:
Lógica de filtros a medida (por ejemplo, condiciones complejas o filtros dependientes).
Idiomas adicionales (multilingüe, traducciones, estructura de URL).
Gran volumen de contenido que hay que estructurar e importar.
Qué propongo al cliente:
Hacer una versión básica de filtros en la primera fase y dejar la lógica compleja para la segunda.
Lanzar primero un idioma y añadir el resto después.
Priorizar páginas: primero inicio + servicios clave, después las secundarias.
Cómo elegir: ¿hourly o bloque?
Elige hourly si:
Aún no tienes una descripción clara de todos los requisitos.
Hay muchas incógnitas y cambios probables.
Te importan la flexibilidad y poder cambiar prioridades en el proceso.
Elige bloque si:
Sabes exactamente qué quieres (hay diseños, briefing, ejemplos).
Te importa la previsibilidad del presupuesto y de la fecha límite.
Los cambios de requisitos son poco probables o no deseables.
Opción intermedia:
Fijar la primera etapa (auditoría + estructura + plantillas clave) como bloque.
Hacer el resto (catálogo, filtros, integraciones) en hourly, porque ahí hay más incógnitas.
¿Necesitas ayuda para estimar un proyecto?
Si tienes un proyecto de 80–140 horas (o cerca) y dudas entre hourly y bloque — escríbeme. Revisamos tus datos de partida (diseños, funcionalidad, objetivos de negocio) y te doy una valoración honesta de qué modelo te conviene más y por qué.
No te obliga a colaborar — pero ayuda a evitar gastos inesperados y correcciones de sorpresa cuando el desarrollo ya ha empezado.
Preguntas frecuentes
Preguntas habituales sobre trabajo en WordPress y soporte continuo.
¿Puedo cambiar de modelo (hourly ↔ bloque) a mitad del proyecto?
Sí, con condiciones claras. Por ejemplo, podemos empezar en hourly en la fase de auditoría y estructura para entender el alcance real, y luego fijar el resto como bloque. O al revés: empezar con bloque y hacer en hourly las tareas nuevas y complejas que aparezcan después. Lo importante es marcar bien dónde termina un formato y dónde empieza el otro.
¿Qué hago si en el proceso me doy cuenta de que quiero nuevas funciones?
Es una situación normal. En proyectos hourly, las funciones nuevas entran en el backlog y se estiman en horas. En un bloque, miramos si caben en el alcance actual. Si no, doy una estimación de horas extra y propongo opciones: ampliar presupuesto, pasarlas a una segunda fase o simplificar otra cosa dentro del bloque actual.
¿Hourly significa que no hay ningún límite de horas?
No. Incluso en hourly siempre trabajo dentro de un presupuesto o tope de horas acordado. Por ejemplo: «100 horas, con revisión tras 80». Cuando nos acercamos al límite, aviso con antelación y decidimos juntos: parar, ampliar presupuesto o simplificar algo. No hay sorpresas del tipo «uy, ya vamos por 150 horas».
¿Cómo garantizas que no vas a «estirar» las horas artificialmente?
Con transparencia y confianza. Tú ves el informe: horas usadas, en qué tareas y cuánto queda. Si algo genera dudas — lo hablamos. A mí tampoco me conviene «estirar» horas: daña la confianza y reduce las opciones de colaboración a largo plazo y de recomendaciones. Mi objetivo no es «quemar el máximo de horas», sino entregar un proyecto que funcione y te traiga solicitudes.
¿Con qué tipos de sitios WordPress trabajas?
Trabajo con sitios WordPress para negocios, tiendas WooCommerce y proyectos que necesitan crecer paso a paso, sin complejidad innecesaria ni soluciones frágiles. Sirve tanto para lanzamientos nuevos como para sitios existentes que necesitan mejoras, soporte o actualizaciones técnicas cuidadosas.
¿Puedes mejorar un sitio existente sin un rediseño completo?
Sí. La mayoría de tareas implican sitios ya en producción: nuevas secciones, mejoras funcionales, cambios en WooCommerce, optimización del rendimiento o correcciones técnicas. La idea es que el sitio siga siendo estable, manejable y fácil de desarrollar.
¿Qué tipos de tareas asumes con más frecuencia?
Lo más habitual es desarrollo WordPress a medida, implementación de diseño desde Figma, mejoras en WooCommerce, soporte de sitios en producción, corrección de problemas técnicos y mejoras prácticas con el tiempo. En casos seleccionados también ayudo con automatizaciones ligeras con IA para contenido, consultas o flujos internos de administración.
¿Trabajas en la velocidad y el rendimiento de WordPress?
Sí. La optimización de WordPress suele incluir revisar el tema, los plugins, las imágenes, las fuentes, la estructura de las páginas y la pulcritud técnica general del sitio. El objetivo no es un «botón mágico», sino cambios prácticos que hagan el sitio más rápido y más fácil de mantener.
¿Utilizas IA en el trabajo con sitios WordPress?
Sí, pero solo donde realmente ayuda al proceso. La IA funciona mejor para borradores de contenido, asistentes de FAQ o soporte, gestión de consultas y pequeñas automatizaciones en torno a un sitio WordPress existente. El enfoque es simple: la IA debe reducir la rutina, no complicar el sitio.
¿Qué necesito preparar para hablar de una tarea o proyecto?
Por lo general basta con una breve descripción del sitio, la tarea, el resultado deseado y, si los hay, ejemplos o limitaciones técnicas. Si el proyecto ya está en marcha, también ayuda mostrar el sitio actual o un entorno de pruebas; así es más fácil entender el alcance del trabajo.
¿Puedo contactarte no para un sitio nuevo, sino para soporte o mejoras puntuales?
Sí. Trabajo no solo en nuevas instalaciones, sino también en sitios en producción que necesitan mantenimiento, correcciones y mejoras graduales. Puede tratarse de páginas nuevas, cambios en el panel de administración, mejoras en WooCommerce, pequeños ajustes de UX o mantenimiento técnico.
¿Necesitas ayuda con un proyecto WordPress?
Si necesitas desarrollo WordPress a medida, implementación de diseño o soporte para un sitio existente, revisaré el proyecto con gusto.