¿Cuánto cuesta una web a medida?

Una propuesta útil convierte una necesidad en trabajo comprobable. «Necesito gestionar reservas» es un punto de partida; para valorarlo hay que saber qué se reserva, quién puede hacerlo, qué disponibilidad se consulta y qué ocurre ante una cancelación.

1. Entender el objetivo y los requisitos. Qué debe poder hacer cada usuario y qué resultado necesita el negocio. También qué herramientas o datos existen ya.
2. Dividir el alcance en entregables. Pantallas, funciones, reglas, datos e integraciones que permitan revisar qué se construirá y comprobar cuándo funciona.
3. Revisar dependencias y diseñar la solución. Accesos, documentación de proveedores, calidad de los datos y limitaciones del sistema actual pueden cambiar el trabajo necesario.
4. Valorar construcción, pruebas y puesta en marcha. La implementación es una parte. También hay que validar permisos, errores y recorridos relevantes, preparar la publicación y comprobar el entorno de destino.
5. Explicitar lo que falta por resolver. Supuestos, exclusiones y decisiones pendientes deben quedar visibles. Cuando una conexión no está documentada, puede necesitar una revisión previa antes de comprometer su desarrollo.
6. Acordar cómo continuará el proyecto. Diferenciar la entrega inicial del mantenimiento, el soporte y las ampliaciones evita interpretar que cualquier cambio futuro está incluido.

El precio puede organizarse por un alcance definido o por fases acordadas. La estructura concreta, las condiciones y cualquier trabajo posterior deben figurar en la propuesta, no deducirse de una explicación general. Las fases del desarrollo y sus entregables ayudan a entender qué trabajo hay que definir y validar antes de comprometer la entrega.

Escenario hipotético, sin importes ni horas asignados. Una empresa quiere que sus clientes soliciten un servicio desde la web. El ejemplo muestra cómo aparecen tareas nuevas al ampliar ese encargo; no describe un presupuesto real de dev2bit.

1. Recibir una solicitud

   Formulario, validación de los datos, almacenamiento o envío y confirmación. Hay que definir los campos, los errores posibles, el destino de la información y qué respuesta recibe el usuario.

2. Permitir el seguimiento

   Añadir usuarios registrados, consulta de solicitudes, estados y notificaciones exige identificar a cada persona, limitar lo que puede consultar y definir qué cambios disparan cada aviso. Ya no basta con enviar un formulario.

3. Organizar la prestación del servicio

   Disponibilidad, asignación de recursos, integraciones y un panel de administración añaden reglas sobre capacidad y coincidencias, permisos de gestión, intercambio de datos y pruebas de las excepciones.

La primera versión termina cuando la solicitud llega correctamente. La segunda debe conservar y mostrar su evolución. La tercera coordina lo que ocurre dentro de la empresa. Aunque compartan una pantalla inicial parecida, no contienen el mismo trabajo.

El presupuesto cambia al incorporar esos requisitos, comprobar sus dependencias y validar nuevos recorridos. No se obtiene sumando una cantidad fija por pantalla o aplicando un multiplicador universal.

Estos ejemplos están publicados y anonimizados en nuestra página de presupuestos. Son propuestas de 2024 y 2025, vinculadas al alcance de cada documento: no son tarifas vigentes, precios mínimos ni un rango para tu proyecto.

Otro presupuesto de 2025 para conectar WordPress y ERP valoraba una solución de importación y exportación tras revisar las alternativas del proveedor; su coste quedaba fuera del trabajo de dev2bit. La lección es estudiar qué conexión basta antes de presupuestar una más compleja. Puedes leer esa propuesta anonimizada de 2025 (PDF).

Una primera versión útil resuelve un recorrido completo: por ejemplo, solicitar una reserva y poder gestionarla. Puede dejar para después funciones secundarias, pero debe permitir que ese recorrido funcione de principio a fin.

• Prioriza una necesidad. Distingue lo imprescindible para empezar de lo que puede esperar a una segunda fase.
• Aprovecha herramientas existentes. Si un CMS o un servicio externo resuelve bien una parte, valora conectarlo en lugar de reconstruirlo.
• Prepara contenido y datos. Aclarar quién los entrega y en qué estado reduce incertidumbres y tareas de preparación.
• Limita variantes al inicio. Menos perfiles, idiomas o recorridos pueden acotar el trabajo si el negocio puede operar así.
• Revisa antes de ampliar una base antigua. Mantenerla puede reducir la inversión inmediata, pero también condicionar la evolución; el ejemplo del ecommerce muestra esa decisión.

Recortar funciones no significa prescindir de las comprobaciones, la seguridad o la integridad de los datos necesarias para que lo que sí se entrega funcione correctamente.

No automatices todavía lo que no sabes cómo debe funcionar. Si un proceso de negocio sigue cambiando, puede ser más útil aclararlo o validarlo con una primera versión antes de programar todas sus excepciones. Las integraciones también pueden planificarse por etapas, siempre que cada fase permita trabajar de forma coherente.

Dividir el proyecto en fases no garantiza que el coste total sea menor. Su ventaja puede estar en distribuir la inversión, validar decisiones y evitar funciones innecesarias. Cada fase necesita coordinarse con las siguientes y puede requerir nuevas comprobaciones.

Antes de decidir que una propuesta es más cara, pide que ambas respondan a las mismas preguntas:

• ¿Qué puede hacer cada usuario? Compara funciones y reglas concretas, no etiquetas como «zona privada» o «integración».
• ¿Qué trabajo de diseño y contenido se contempla? Distingue pantallas, adaptación móvil, textos, imágenes e idiomas.
• ¿Qué datos y conexiones se incluyen? Comprueba migración, preparación de información y obligaciones de terceros.
• ¿Cómo se comprueba la entrega? Identifica las validaciones previstas y qué se considera terminado.
• ¿Qué queda fuera y qué se paga aparte? Revisa licencias, infraestructura, formación, soporte y nuevas funciones.
• ¿Qué recibes y qué control conservas? Aclara código específico, cuentas, accesos y condiciones de continuidad.

Si una propuesta cubre desarrollo y otra añade migración, pruebas y puesta en marcha, sus totales no representan el mismo producto. Tampoco conviene asumir que una exclusión desaparecerá por no mencionarla durante la contratación.

Revisa también las condiciones de cambio de alcance: cómo se analiza una necesidad nueva y cómo se acuerdan sus efectos antes de ejecutarla. Comprueba la puesta en marcha, las responsabilidades sobre servicios externos y qué documentación, titularidad y acceso al código se entregan según el contrato.