Cómo presupuestamos proyectos de software: modelo de precios transparente

Pedir un presupuesto de desarrollo de software puede resultar frustrante. Llega una cifra sin que quede claro qué incluye, cuándo empieza el trabajo ni qué pasa si algo cambia. En Pazl trabajamos de otra manera: precio fijo acordado antes de empezar, alcance escrito en el contrato y garantía de seis meses sobre lo entregado. Esta página explica exactamente cómo llegamos a cada número.

---

Por qué el presupuesto «a consultar» no funciona

La mayoría de los estudios de desarrollo evitan publicar precios porque quieren conocer el presupuesto del cliente antes de nombrar el suyo. El resultado es que el cliente recibe una cifra inflada o, al contrario, una oferta baja que luego crece con extras.

Nosotros partimos del principio contrario: el precio y el plazo se fijan en el contrato después de aprobar el alcance técnico. Si el alcance no cambia, el precio no cambia. Si el cliente pide algo fuera del alcance, se firma un addendum y se presupuesta por separado.

Esto no es un slogan; es la mecánica real de cada proyecto que firmamos.

---

Qué determina el coste de un proyecto

Antes de hablar de cifras, conviene entender las variables que mueven el precio. No es el número de páginas ni el tipo de empresa: es la complejidad técnica del trabajo.

Integraciones con sistemas externos

Conectar una aplicación a una caja registradora, a un ERP, a una pasarela de pagos o a una API de terceros multiplica el tiempo de desarrollo. Cada integración tiene su propia documentación, sus propios entornos de prueba y sus propios comportamientos inesperados. En proyectos de comercio electrónico o logística, las integraciones pueden suponer entre el 30 % y el 50 % del presupuesto total.

Número de roles y perfiles de usuario

Una plataforma con un solo tipo de usuario es mucho más sencilla que una con tres roles distintos —por ejemplo, cliente, operador y administrador— porque cada rol necesita su propia lógica de permisos, su propio panel y sus propios flujos.

Lógica de negocio específica

Los programas de fidelización con reglas complejas, los motores de cálculo de precios dinámicos o los flujos de aprobación multinivel requieren más tiempo de análisis y más pruebas que una aplicación de catálogo estándar.

Plataformas de publicación

Una aplicación web es un entorno. Una aplicación móvil para iOS y Android son dos entornos con sus propios ciclos de revisión en App Store y Google Play. Publicar en tiendas adicionales —Huawei AppGallery, por ejemplo— añade tiempo de adaptación y gestión de cuentas de desarrollador.

Diseño desde cero o sobre base existente

Si el cliente ya tiene identidad visual, guía de estilos y componentes en Figma, el diseño es más rápido. Si partimos de cero, hay que sumar el tiempo de conceptualización.

---

Tabla de precios orientativos por tipo de proyecto

Los rangos siguientes son referencias de mercado para proyectos en España y Europa occidental. No son precios cerrados: el precio definitivo se fija siempre después de revisar el alcance técnico. Cada fila indica qué está incluido en el rango y qué queda fuera.

Nota sobre el IVA: los precios anteriores son sin IVA. En España, el tipo general del IVA es el 21 %. Pazl LLC es una entidad estadounidense (Wyoming); la aplicación del IVA en operaciones B2B con empresas españolas se rige por las reglas de inversión del sujeto pasivo del artículo 69 de la Ley 37/1992 del IVA. Consulte con su asesor fiscal la situación concreta de su empresa.

Nota sobre hosting y licencias: los costes de servidores, dominios, certificados SSL y licencias de software de terceros corren siempre a cargo del cliente. No están incluidos en ninguno de los rangos anteriores.

---

Cómo es el proceso desde el primer contacto hasta la entrega

El proceso tiene seis pasos. No hay pasos ocultos ni sorpresas entre uno y otro.

1. Primera llamada (sin coste)

Hablamos entre 30 y 60 minutos para entender qué necesita construir, qué sistemas tiene ya y cuál es el objetivo de negocio. No le pedimos que rellene un formulario de veinte preguntas antes de hablar.

2. Propuesta y alcance técnico

Preparamos una propuesta escrita con el alcance detallado: qué pantallas, qué integraciones, qué roles de usuario, qué plataformas. El alcance es el documento que evita malentendidos posteriores.

3. Contrato con precio y plazo fijos

Una vez aprobado el alcance, firmamos el contrato. En él constan el precio total, el calendario de pagos y la fecha de entrega. Nada de esto cambia salvo que el alcance cambie.

4. Desarrollo con demos semanales

Cada semana recibe una demo del trabajo avanzado. No tiene que esperar dos meses para ver algo: ve el progreso real y puede dar su opinión antes de que sea tarde para incorporarlo.

5. Entrega y traspaso

Entregamos el código fuente, los accesos y la documentación. Los derechos sobre el resultado pasan al cliente tras el pago completo.

6. Garantía de seis meses

Durante seis meses después de la entrega, corregimos cualquier error que sea responsabilidad nuestra sin coste adicional. Las correcciones dentro del alcance original no generan factura extra.

---

Cómo se estructura el pago

No pedimos el 100 % por adelantado. El esquema habitual es:

• 30-50 % al firmar el contrato (anticipo que cubre el inicio del trabajo)
• El resto en uno o dos pagos intermedios, vinculados a hitos de entrega verificables

El calendario exacto depende del tamaño del proyecto. En proyectos cortos —menos de cuatro semanas— puede ser 50/50. En proyectos largos solemos dividir en tres tramos.

---

Qué pasa cuando el alcance cambia

Cambia el alcance en casi todos los proyectos. El cliente descubre algo que no había pensado, o el mercado cambia, o aparece una integración nueva. No es un problema; es normal.

Cuando ocurre, abrimos un addendum al contrato: describimos el trabajo adicional, acordamos el precio y el plazo extra, y firmamos antes de empezar. Nada se hace «de palabra» y nada se cobra por sorpresa.

---

Cómo lo hacemos nosotros: el proceso en la práctica

Esta sección es la más importante si está valorando trabajar con nosotros. No describimos cómo debería funcionar el mercado; describimos cómo funcionamos nosotros, con ejemplos reales de proyectos que hemos entregado.

El alcance técnico antes que el precio

En todos nuestros proyectos, el precio se fija después de revisar el alcance, no antes. Cuando un cliente llega con una idea vaga —«quiero una app de fidelización»— lo primero que hacemos es desgranar las preguntas que determinan el coste real: ¿cuántos puntos de venta hay?, ¿existe ya un sistema de caja con el que integrar?, ¿qué datos de clientes hay que migrar?, ¿se publica solo en App Store o también en Google Play?

Hemos aprendido que saltarse este paso es el origen de la mayoría de los conflictos en proyectos de software.

Un ejemplo de proyecto de aplicación móvil con programa de fidelización

Hemos desarrollado aplicaciones móviles con programas de fidelización para cadenas de retail. En uno de esos proyectos, el alcance incluía:

• Aplicación para iOS y Android (un único código base en Flutter)
• Programa de puntos con reglas de acumulación y canje
• Integración con el sistema de caja existente del cliente para que los puntos se acumulen en tiempo real en el momento de la compra
• Panel de administración para gestionar promociones, segmentos de clientes y envío de notificaciones push
• Migración de la base de clientes existente, con sus puntos acumulados, desde el sistema anterior

Cada uno de esos cinco bloques tiene un peso diferente en el presupuesto. La integración con el sistema de caja, por ejemplo, fue el bloque más complejo: requirió entender la API del proveedor de software de caja, montar un entorno de pruebas, y gestionar los casos en los que la conexión se interrumpe en medio de una transacción. El diseño de pantallas, en cambio, fue más rápido porque el cliente ya tenía su guía de estilos.

El resultado fue una aplicación publicada en App Store y Google Play con la base de clientes migrada íntegramente, incluyendo los puntos acumulados de cada usuario.

Un ejemplo de plataforma web con múltiples roles

También hemos construido plataformas web donde conviven varios tipos de usuario con permisos distintos. En uno de esos proyectos —una plataforma de sector específico— había tres roles: usuarios finales que se registraban y subían contenido, revisores que moderaban ese contenido, y administradores que gestionaban el sistema completo. Además, la plataforma incluía un modelo de suscripción de pago.

El alcance técnico de ese proyecto incluyó:

• Sistema de registro y autenticación con lógica de roles
• Panel diferenciado para cada tipo de usuario
• Integración con una pasarela de pagos para gestionar suscripciones recurrentes
• Generación automática de documentos (certificados en PDF) tras completar determinadas acciones
• Blog con CMS para publicar contenido editorial

La complejidad no estaba en el número de páginas, sino en la lógica de permisos y en la generación automática de documentos. Eso es lo que determinó el presupuesto.

Un ejemplo de agente de IA

Hemos desarrollado agentes de inteligencia artificial para automatizar la comunicación con clientes. En uno de esos proyectos, el agente gestionaba las conversaciones entrantes de una empresa de servicios: respondía preguntas frecuentes, recogía datos del cliente, creaba tareas en el sistema de gestión del equipo y escalaba al equipo humano cuando la conversación lo requería.

El agente entendía texto, voz, imágenes y vídeo, y mantenía el contexto de cada conversación. El resultado fue que el equipo dejó de gestionar la comunicación rutinaria y se concentró en las conversaciones que requerían decisión humana.

En este tipo de proyecto, el coste depende principalmente de dos factores: la complejidad de los flujos de conversación y las integraciones con sistemas externos (CRM, herramientas de gestión de tareas, bases de datos internas). Las licencias de los modelos de IA de terceros van siempre a cargo del cliente.

Nuestro calendario de pagos en la práctica

En proyectos de entre cuatro y doce semanas, el esquema habitual que aplicamos es:

• Primer pago al firmar el contrato (entre el 30 % y el 50 % del total)
• Segundo pago en un hito intermedio verificable —por ejemplo, tras la entrega del diseño aprobado o tras la primera demo funcional
• Pago final tras la entrega completa y la firma del acta de aceptación

En proyectos más cortos —menos de cuatro semanas— trabajamos con 50/50: mitad al firmar, mitad a la entrega.

---

Preguntas que nos hacen con frecuencia

¿Puedo pedir un presupuesto sin tener el proyecto definido?

Sí. La primera llamada sirve precisamente para eso: entender qué necesita y ayudarle a definir el alcance. No hace falta que llegue con un documento técnico.

¿Qué pasa si el proyecto tarda más de lo previsto?

Si el retraso es por nuestra parte, el plazo se extiende sin coste adicional para el cliente. Si el retraso es por cambios en el alcance solicitados por el cliente, se firma un addendum con el nuevo plazo y el coste correspondiente.

¿Quién se queda con el código fuente?

El cliente. Los derechos sobre el código y sobre el resultado del proyecto pasan al cliente tras el pago completo. Nosotros podemos mencionar el proyecto en nuestro portfolio, pero sin revelar el código ni información confidencial.

¿Ofrecen mantenimiento después de la entrega?

Sí. Además de la garantía de seis meses, ofrecemos contratos de soporte mensual con horas dedicadas. El coste de soporte se presupuesta por separado del proyecto y depende del volumen de horas que el cliente necesite.

¿Trabajan con empresas en España sujetas al RGPD?

Sí. En proyectos que implican tratamiento de datos personales de usuarios europeos, el diseño técnico tiene en cuenta los requisitos del RGPD y la LOPDGDD. Si el proyecto requiere una evaluación de impacto (EIPD) o la figura de un DPO, se lo indicamos durante el análisis del alcance. La supervisión del cumplimiento normativo corresponde a la AEPD; nosotros aportamos la arquitectura técnica adecuada, pero la responsabilidad legal como responsable del tratamiento es del cliente.

---

Resumen: lo que fijamos antes de empezar

Antes de escribir una sola línea de código, acordamos por escrito:

• El alcance técnico detallado (qué se construye, qué no)
• El precio total (sin sorpresas posteriores)
• El calendario de pagos (vinculado a hitos verificables)
• El plazo de entrega
• La garantía aplicable (seis meses sobre lo entregado)

Si algo de esto no está claro antes de firmar, no firmamos. Esa es la única forma de que el proyecto funcione para los dos lados.

Si tiene un proyecto en mente y quiere saber qué costaría construirlo, escríbanos a hello@pazl.ai o visite pazl.ai. La primera conversación no tiene coste ni compromiso.