Cómo comparar presupuestos de desarrollo de aplicaciones

Un proveedor llama al trabajo 'desarrollo completo'. Otro lo presupuesta por separado: descubrimiento, diseño, QA y despliegue. Coloca esos totales uno al lado del otro y aún no sabrás cuál propuesta cuesta más. Primero asegúrate de que cada proveedor esté presupuestando el mismo resultado.

Normaliza el alcance antes de comparar precios

Verifica si cada propuesta incluye:

• solo una aplicación web, o también aplicaciones nativas de iOS y Android
• las pantallas acordadas, flujos de usuario y características de administración
• archivos de origen de diseño, diseños responsivos y trabajo de accesibilidad
• migración de datos legados e integraciones con terceros
• pruebas, revisión de seguridad y alcance de corrección de errores
• despliegue del servidor y soporte para revisión de la tienda de aplicaciones
• correcciones de garantía y mantenimiento pagado después de la entrega

Una partida faltante puede convertirse más adelante en una ampliación de alcance. También puede ocurrir lo inverso: un presupuesto puede incluir plataformas o soporte continuo que no necesitas. Construye una tabla de comparación con tres columnas—incluido, excluido y asumido—en lugar de comparar solo los nombres de los proveedores y los totales.

Trata el prototipo como una herramienta de conversación, no como una especificación

Un prototipo construido con Claude Code, Codex, Cursor o Lovable puede mostrar el flujo deseado de manera más clara que una breve descripción escrita. Una pantalla funcional no es automáticamente una especificación completa, y su código tampoco está automáticamente listo para producción.

En particular, Lovable construye aplicaciones web. Una PWA o un contenedor independiente pueden ofrecer una experiencia móvil instalable, pero un prototipo web no debe considerarse como progreso hacia una aplicación nativa de iOS o Android sin una evaluación adicional.

Separa lo que el prototipo demuestra de lo que aún se desconoce.

Ya demostrado

• el flujo de pantallas y los textos principales
• las acciones principales que los usuarios deben tomar
• la dirección visual preferida

Aún por evaluar

• si el código es reutilizable
• el comportamiento en dispositivos móviles y navegadores, incluida la accesibilidad
• la seguridad de la autenticación, autorización y pagos
• arquitectura de pruebas, despliegue y monitoreo
• licencias para bibliotecas y activos

Esto mantiene útil al prototipo sin sobrevalorar su utilidad, y te evita tener que explicar decisiones de producto resueltas una y otra vez.

Compra una breve evaluación técnica antes del desarrollo completo

Nadie puede afirmar responsablemente que 'el 80% del código actual es reutilizable' o que 'todo debe reconstruirse' sin examinar el repositorio. Acuerda primero una evaluación remunerada y sus entregables.

Al menos, pide al revisor que revise:

1. si el proyecto se instala y ejecuta en un entorno limpio siguiendo el README
2. si las pantallas clave y flujos aún funcionan
3. si aparecen secretos en el código o los registros, y si la autenticación o la autorización por usuario tienen claras lagunas
4. qué está cubierto por pruebas automatizadas y qué aún requiere verificaciones manuales
5. de de qué dependencias, servicios de alojamiento, cuentas externas y licencias depende la aplicación

Pide tres caminos: terminar sobre la base actual, refactorizar áreas seleccionadas y reconstruir. Cada opción debe indicar su alcance, sus riesgos y sus plazos. Un prototipo no garantiza un descuento, pero el código existente tampoco carece de valor. La evaluación te dice qué realmente puede reutilizarse.

El paquete de entrega es más que el repositorio

Un nuevo desarrollador debería poder comenzar el día que reciba acceso. Prepara:

• un README con comandos de instalación, ejecución y compilación
• los nombres de las variables de entorno requeridas y dónde obtenerlas; envía valores reales a través de un canal seguro separado
• una lista de pantallas y características, más defectos conocidos
• cuentas de prueba y pasos de prueba
• una lista de cuentas de hosting, dominio, pagos, analítica y tiendas de aplicaciones
• el repositorio Git y el historial de commits que registren decisiones importantes

No borres de inmediato archivos generados por IA duplicados o aparentemente no utilizados antes de la entrega. Preserva primero el estado conocido de funcionamiento en una etiqueta o rama, luego confirma las eliminaciones durante la evaluación.

Nunca hagas commit de un archivo .env que contenga valores reales o claves de API. Mantén un archivo .env.example que liste solo los nombres de variables requeridas. Si una clave ya se incluyó en un commit, revoca o rota primero, luego considera limpiar el historial de Git.

Coloca el control operativo en el contrato

Los equipos quedan atados a un proveedor cuando la titularidad de las cuentas y los entregables nunca se hicieron explícitos. Obtén respuestas escritas a estas preguntas antes de firmar:

• ¿Qué repositorio recibe el código fuente y el historial completo de Git?
• ¿Quién es el dueño legal de la cuenta, el dominio, el alojamiento, las tiendas de aplicaciones y el proveedor de pago?
• ¿Los archivos de diseño editables, fuentes, imágenes y licencias pagas están incluidos en la transferencia?
• ¿Qué características forman cada hito de aceptación, y qué se considera aprobación?
• ¿Quién aprueba cambios de alcance, cómo se registran y cómo se presupuestan?
• ¿Qué se considera una corrección de garantía y qué se convierte en mantenimiento pagado?

Crea cuentas principales en nombre del cliente siempre que sea posible, luego otorga al proveedor solo el acceso que necesita. Si un repositorio de GitHub existente debe cambiar de dueño, incluye el proceso de transferencia de GitHub y una revisión de permisos posterior a la transferencia en el plan de transferencia.

Una breve solicitud de presupuesto es suficiente

Tenemos un prototipo web funcional y un repositorio Git.
Objetivo: aplicación web adaptable con un área de administración
Alcance que debe presupuestarse: evaluación del código, revisión de autenticación y pagos, despliegue y documentación de entrega
Excluido: aplicaciones nativas para iOS y Android
Entregables: código fuente e historial de Git, configuración de despliegue, README y resultados de pruebas
Empiecen con una evaluación remunerada y presupuesten por separado las opciones de terminar sobre la base actual, refactorizar áreas concretas y reconstruir.

Envía el mismo documento a cada proveedor y guarda sus preguntas y respuestas. La propuesta más fácil de comparar no necesariamente es la más barata; es la que hace explícitos sus omisiones y términos de transferencia. Antes de elegir un proveedor, considera pedir a un especialista en contratos que revise el cronograma, términos de pago, lenguaje de propiedad intelectual y cláusulas de licencias.