La pregunta equivocada llega primero
"¿Deberíamos construir un sitio web o una app?" Esa es la pregunta que recibimos en casi cada primera llamada. Es la pregunta equivocada. Se salta un paso.
La pregunta correcta es: ¿qué necesita hacer este producto, y para quién? Un sitio de marketing, una web app personalizada y una Progressive Web App (PWA) resuelven problemas distintos. Elegir la opción equivocada no solo desperdicia presupuesto: te encierra en una arquitectura costosa de deshacer seis meses después, normalmente justo tras la primera ronda de feedback real de usuarios.
Este es el marco que usamos con los clientes antes de escribir una sola línea de código, junto con rangos honestos de lo que cuesta cada opción y cuánto tiempo toma en 2026.
Tres trabajos distintos, no tres niveles del mismo trabajo
Los equipos suelen tratarlos como una escalera: el sitio de marketing abajo, la PWA arriba, la app en el medio. Eso no es correcto. No son versiones más o menos sofisticadas unas de otras. Responden a preguntas diferentes.
Sitio de marketing. Su trabajo: convertir a un visitante en un lead o una venta. Basado en contenido, mayormente público, sin cuentas de usuario (o con una versión mínima añadida para contenido restringido). El éxito se mide en tasa de conversión, velocidad de carga y posicionamiento en buscadores. Se construye sobre un CMS o un framework de sitio estático, con poca lógica de backend personalizada más allá de formularios y analítica.
Web app personalizada. Su trabajo: permitir que un usuario autenticado haga trabajo real: gestionar inventario, revisar reclamaciones, agendar citas, generar reportes. Aquí es donde vive la lógica de negocio: permisos, flujos de trabajo, validación de datos, integraciones con tu CRM o ERP. El éxito se mide en tiempo de finalización de tareas y tasa de errores, no en páginas vistas.
PWA. Su trabajo: darle a una web app la sensación de una app nativa (ícono instalable, acceso sin conexión a las pantallas clave, notificaciones push) sin el ciclo de revisión de la App Store ni dos bases de código separadas. No es tanto una cuarta categoría como un modo de entrega que se superpone a una web app. No construyes "una PWA" en lugar de una web app; construyes una web app y decides cuánto de la capa PWA (service workers, caché offline, prompts de instalación) vale la pena añadir.
Cómo elegir en la práctica
Haz estas cuatro preguntas, en orden:
- ¿Un usuario inicia sesión y hace trabajo repetible, o un visitante lee y se va? Trabajo repetible → web app. Leer y salir → sitio de marketing.
- ¿El producto necesita funcionar con una conexión inestable, en un teléfono, lejos de un escritorio? Técnicos de campo, personal de almacén, repartidores: sí. Trabajadores de oficina con conexión estable: normalmente no, y la capa PWA es un costo adicional que todavía no necesitas.
- ¿La visibilidad en buscadores es parte de cómo te encuentran? Si es así, ese contenido debe vivir en un sitio de marketing rápido y rastreable, no enterrado detrás del muro de inicio de sesión de tu app, y necesita tener los fundamentos técnicos (los básicos de SEO: contenido renderizado en servidor, URLs limpias, schema funcionando) integrados desde el primer commit, no añadidos después del lanzamiento.
- ¿Necesitas ambos? La mayoría de las empresas B2B sí: un sitio de marketing para generar el lead, y una web app tras el login donde realmente vive el cliente que paga. Eso son dos desarrollos, no uno, y tratarlos como un solo proyecto es una razón común por la que los proyectos web se disparan por encima de su presupuesto original.
Si estás construyendo el segundo tipo — la app que tus clientes realmente usan — ahí es donde nuestro equipo de desarrollo web dedica la mayor parte de su tiempo, porque ahí es donde realmente se concentran el costo y el riesgo.
Qué determina realmente el costo
El costo no depende principalmente de la cantidad de páginas ni de "cuántas funciones". Depende de cuatro factores:
Complejidad del modelo de datos. Una app CRUD con un puñado de tipos de entidad simples es un desarrollo distinto al de una con permisos basados en roles a través de muchos tipos de entidad y con registros de auditoría. Cada relación añadida multiplica la superficie de pruebas, no solo el esquema.
Integraciones. Cada sistema de terceros al que te conectas — Stripe, Salesforce, la API de una empresa de transporte, una base de datos interna heredada — suma tiempo real dependiendo de qué tan bien documentada y estable sea la API de ese sistema. Los sistemas internos sin documentar son una de las mayores fuentes de retraso que vemos, porque los casos límite no aparecen hasta que ya estás integrando.
Requisitos en tiempo real y sin conexión. Un dashboard que se actualiza al cargar la página es económico. Un dashboard con actualizaciones en vivo vía websockets, o una vista móvil que necesita funcionar sin conexión y sincronizar después, suma tiempo de ingeniería real sobre el desarrollo base de las pantallas afectadas.
Madurez del diseño. Si partes de un archivo de Figma con cada estado (vacío, cargando, error, caso límite) ya diseñado, el desarrollo avanza rápido. Si el diseño ocurre en paralelo con el desarrollo, espera retrabajo: las pantallas se construyen sobre una especificación que cambia debajo de ellas.
La experiencia del equipo y su ubicación afectan la tarifa por hora, pero rara vez explican las mayores variaciones en el costo total del proyecto. Los cuatro factores anteriores sí lo hacen.
Plazos realistas para 2026
Estos son rangos aproximados para un solo desarrollo bien definido — no para el portafolio completo que podría necesitar una gran empresa — basados en proyectos que hemos dimensionado recientemente:
- Sitio de marketing (un puñado de páginas, basado en CMS, sin backend personalizado): unas pocas semanas.
- Web app personalizada, complejidad estándar (autenticación, algunos tipos de entidad centrales, una o dos integraciones): aproximadamente un trimestre.
- Web app personalizada, alta complejidad (permisos multi-rol, varias integraciones, funciones en tiempo real): un par de trimestres o más.
- Añadir la capa PWA a una web app existente (caché offline para pantallas clave, prompt de instalación, push): unas pocas semanas, dependiendo de cuánto de la app necesita funcionar sin conexión frente a solo ser instalable.
Cualquiera que te dé una cifra fija sin preguntar por tu modelo de datos, tus integraciones y el estado de tu diseño está adivinando.
El patrón que más vemos
El error más común no es elegir el formato equivocado — es elegir un formato y pedirle que haga ambos trabajos. Una empresa construye un sitio de marketing pulido, y luego intenta acoplarle un dashboard de clientes en la misma base de código porque "ya está construido". Meses después, el dashboard está peleando con el CMS por el control del enrutamiento, y cada actualización de contenido arriesga romper una función que requiere inicio de sesión.
La solución casi siempre es separarlos desde el inicio: un sitio de marketing ligero optimizado para velocidad y búsqueda, y una web app aparte optimizada para la experiencia con inicio de sesión, compartiendo un sistema de diseño pero no una base de código. Cuesta un poco más al principio. Ahorra una reconstrucción después.
En resumen
No empieces por "sitio web o app". Empieza por lo que el usuario está haciendo y cuánto de eso necesita sobrevivir a una mala conexión. Define el sitio de marketing y el producto con inicio de sesión como dos decisiones separadas, incluso si un solo equipo construye ambos. Y al cotizar un desarrollo personalizado, pregunta por el modelo de datos y las integraciones antes de preguntar por la cantidad de páginas — ahí es donde sale la cifra real.
Si estás en el punto de definir uno de estos desarrollos y quieres una respuesta directa sobre costo y plazos para tu caso específico, habla con nosotros antes de escribir el RFP.
