Vas a contratar el desarrollo de tu sitio web. Recibes dos cotizaciones: una dice "Landing page $249, entrega 7 días" y otra dice "Trabajo por hora a RD$1,500/h, estimado 30-50 horas". A primera vista la segunda parece más flexible. En la práctica es donde la mayoría de los proyectos terminan costando el doble.
Este artículo explica honestamente — desde la perspectiva del cliente — por qué ese modelo de "trabajo por hora" funciona mejor para el desarrollador que para ti, cuándo SÍ tiene sentido pagar por hora, y cómo evaluar cualquier presupuesto de desarrollo web sin caer en sorpresas.
Los dos modelos en simple
Precio fijo (Fixed bid): el desarrollador te cobra un monto cerrado por entregarte un alcance definido. Tú pagas $X, recibes Y. Si al desarrollador le toma más tiempo del estimado, es su problema. Si lo termina antes, tampoco te descuentan.
Por hora (Time & Materials): el desarrollador te cobra por las horas que dedica al proyecto. Te da una estimación de cuántas horas serán, pero al final pagas lo real. Si surgen "imprevistos" o cambios, sigues pagando.
El cálculo del riesgo: quién lo asume
La clave para entender estos modelos es entender quién asume el riesgo de los imprevistos:
| Escenario | Precio fijo | Por hora |
|---|---|---|
| Bug que toma 8h en lugar de 2 | Lo asume el desarrollador | Lo asume el cliente |
| Cambio de diseño a mitad de camino | Se cotiza aparte | Sumas horas extra |
| Tecnología nueva que el dev no conoce | Aprende en su tiempo | Pagas el aprendizaje |
| Integración compleja que no se anticipó | Negociación abierta | Pagas todas las horas |
| Cliente cambia de opinión | Se cotiza el cambio | Pagas horas extra (justo) |
El sistema "por hora" desplaza casi todos los riesgos al cliente. Y como el cliente no sabe técnicamente cuánto debería tomar cada cosa, no puede negociar si los estimados se inflan.
Cuándo el "por hora" es honesto y cuándo es una bandera roja
El cobro por hora SÍ es legítimo en ciertos contextos:
- check_circleConsultoría técnica: "Ven a revisar nuestra arquitectura y dame recomendaciones". El alcance es exploratorio.
- check_circleMantenimiento post-lanzamiento: cambios incrementales, ajustes pequeños, donde fijar precio por cada uno sería burocrático.
- check_circleI+D / desarrollo de producto: proyectos donde realmente nadie sabe el alcance final hasta que iteras.
- check_circleBug urgente que debe resolverse hoy: "Mi sitio está caído, ven y arregla lo que puedas". No hay tiempo de cotizar.
Pero el "por hora" se vuelve bandera roja cuando:
- flagTe lo proponen para un proyecto con alcance claro (landing page, sitio empresarial, ecommerce de N productos).
- flagEl "estimado" tiene un rango amplio: "entre 20 y 60 horas" — eso es decirte "puede costar el triple".
- flagEl desarrollador se rehúsa a darte un precio fijo "porque no sabe cuánto tomará". Si él no sabe, ¿tú cómo vas a saber cuánto vas a pagar?
- flagNo te dan herramienta para verificar las horas trabajadas (timesheet, capturas, reporte semanal).
Comparativa real: el mismo proyecto en ambos modelos
Caso real: PYME en Santo Domingo necesita sitio empresarial con 5 secciones, blog y formulario de contacto. Veamos cómo se ve en cada modelo:
| Item | Precio fijo | Por hora ($25/h) |
|---|---|---|
| Cotización inicial | $499 USD | ~20h estimado = $500 |
| Realidad: bug inesperado +5h | $499 | +$125 = $625 |
| Cliente pide cambio de color a mitad | $0 (rondas de revisión incluidas) | +1h = +$25 |
| Integración con Google Calendar | Cotizado aparte: $100 | +4h = +$100 |
| Aprende tecnología nueva +3h | $0 | +$75 |
| Reuniones de revisión (3) | Incluidas | 3h × $25 = +$75 |
| Total final | $599 USD | $1,025 USD |
El mismo proyecto, dos modelos de cobro. La diferencia es que en precio fijo SABÍAS desde el inicio que pagarías $499 (+$100 del addon de Calendar = $599). En por hora pagaste el doble. Y no porque te estafaron — simplemente porque "todo tomó más tiempo del esperado", que es lo normal en software.
Cómo evaluar un presupuesto de precio fijo correctamente
Para que un precio fijo sea legítimo y honesto, el contrato debe especificar:
- checklistAlcance escrito en detalle: cuántas páginas, qué secciones, qué funcionalidades concretas. "Sitio web" no es alcance.
- checklistQué NO incluye: explícitamente listado. Ej: "no incluye edición de imágenes, no incluye copywriting, no incluye SEO técnico avanzado".
- checklistCuántas rondas de revisión: típicamente 1-3. Cambios mayores fuera de las rondas se cotizan aparte.
- checklistPlazo de entrega: en días hábiles, con fecha estimada de finalización. Y qué pasa si el desarrollador se atrasa por causa propia.
- checklistForma de pago: 50% inicio + 50% entrega es estándar. Evita cualquiera que pida 100% adelantado.
- checklistQuién es dueño del código: tú. Punto. Tu debe quedar dueño de los archivos, repo, y credenciales al final.
- checklistSoporte post-entrega: cuánto tiempo (típicamente 30 días) para arreglar bugs sin cargo adicional.
Modelo híbrido: lo mejor de los dos mundos
Algunos proyectos se manejan mejor con un híbrido:
- handshakeFase 1 (descubrimiento) por hora: 2-4 horas pagadas para que el equipo entienda el proyecto, levante requisitos y haga el diseño funcional.
- handshakeFase 2 (construcción) precio fijo: con todo lo aprendido en fase 1, el desarrollador puede dar un precio cerrado con confianza.
- handshakeFase 3 (mantenimiento) plan mensual: después del lanzamiento, mantenimiento continuo con plan fijo mensual (ej: $35/mes con cambios pequeños incluidos).
Este modelo respeta la realidad: en el descubrimiento nadie sabe nada, en la construcción todos sabemos mucho, en el mantenimiento hay cambios constantes pero menores.
¿Buscas desarrollo web con precio fijo?
Landing page $249, sitio empresarial $499, ecommerce desde $1,500. Precio cerrado escrito antes de empezar. Entrega garantizada en plazo.
Ver tarifas y proceso arrow_forwardConclusión: pide precio fijo (con excepciones puntuales)
Como cliente, la regla simple es: para cualquier proyecto con alcance definido, exige precio fijo. Si el desarrollador no puede dártelo, es porque (a) no sabe estimar lo que va a hacer, o (b) no quiere asumir el riesgo de imprevistos.
Para mantenimiento, consultoría exploratoria o casos genuinamente impredecibles, el cobro por hora tiene sentido — pero pide siempre el detalle del tiempo trabajado y establece un límite mensual.
En IPM TechOps trabajamos exclusivamente con precio fijo escrito antes de empezar para todos nuestros paquetes de desarrollo. La razón es simple: nosotros sabemos lo que estamos haciendo, así que asumimos el riesgo del estimado. Tú tienes certeza de cuánto cuesta tu proyecto antes de firmar.