En corto
- El precio no depende de cuántas pantallas tenga, sino de cuántas cosas tienen que salir bien a la vez.
- Mandan cinco factores: tipos de usuario, integraciones con lo que ya usas, si mueve dinero o datos personales, si rinde cuentas ante un organismo y cuántos datos hay que migrar.
- Un presupuesto cerrado sin diagnóstico previo no es un precio, es una apuesta. Y la paga alguien.
- Trabajar por fases no es no comprometerse. Es poder parar al final de cada fase sin haberlo perdido todo.
- Antes de firmar: de quién es el código, a nombre de quién van dominio y hosting, qué incluye el mantenimiento y qué pasa si el desarrollador desaparece.
Antes de seguir
No somos asesoría fiscal ni despacho de abogados. Lo que aquí se dice sobre contratos, propiedad del código y obligaciones son criterios técnicos y de sentido común, no asesoramiento jurídico. Un contrato de desarrollo lo revisa un abogado.
Por qué nadie serio te da un precio de software a medida en la primera llamada
Una aplicación para gestionar pedidos puede ser dos semanas o dos años. La frase es la misma; el encargo no. El software a medida no es un producto de catálogo: es una obra, y nadie presupuesta una nave sin ver el terreno. Aquí el terreno son tus procesos, tus datos y los programas que ya usas. El precio no sale del número de pantallas. Sale de cuántas cosas tienen que salir bien a la vez, de cuántas dependen de terceros y de lo caro que resulta equivocarse: un albarán mal impreso se rehace; un cobro duplicado, no.
Cuántos tipos de usuario distintos van a entrar en el programa
Es el factor que más se subestima. Cada rol trae sus pantallas, sus permisos, sus casos raros y sus pruebas. Lo que usa una persona es una aplicación. Lo que usan cliente, comercial, almacén y administración son casi cuatro aplicaciones compartiendo base de datos, más la matriz de quién puede ver y tocar qué. Ese cruce no crece en línea recta, crece por multiplicación. Antes de pedir presupuesto, escribe la lista de roles y, al lado de cada uno, las tres o cuatro cosas que hace en un día normal.
- Quién entra al sistema y desde dónde: oficina, móvil, casa del cliente.
- Qué puede ver cada rol y, sobre todo, qué no debe ver.
- Quién aprueba lo que lleva dinero o descuentos.
- Si algún rol es de fuera: un cliente, un proveedor, la gestoría.
Cada integración con un sistema que ya tienes es un proyecto pequeño dentro del proyecto
Conectar con el ERP, el TPV, la pasarela de pago o la agencia de transporte no es una casilla que se marca. Lo que cuesta no es tu lado, es el que hay enfrente. Si el otro sistema tiene API documentada y entorno de pruebas, el trabajo está acotado. Si no la tiene, se acaba tirando de ficheros o accesos frágiles que se rompen el día que el proveedor cambia algo sin avisar. Ojo también a la dirección del dato: llevarlo en un sentido es asumible; sincronizar en los dos obliga a decidir quién gana cuando el mismo registro se edita en dos sitios.
- Tiene API documentada y entorno de pruebas, o hay que apañarse con exportaciones.
- Quién da las credenciales y cuánto tarda.
- Qué pasa cuando el otro sistema se actualiza o se cae.
- El dato viaja en un sentido o en los dos.
Si el software toca dinero o datos personales, el listón sube desde el primer día
Cobrar no es poner un botón. Es reintentos, pagos duplicados, devoluciones, cuadres y conciliación con el banco. Obliga a registrar quién hizo qué y cuándo, y a que un mismo cobro no se aplique dos veces aunque el navegador se quede colgado. Con datos personales pasa algo parecido: control de acceso real, copias, cifrado, borrado y saber dónde están alojados y quién puede verlos. Nada de eso es una capa que se añade al final si sobra tiempo: condiciona el diseño desde el principio.
Tiene que responder ante Hacienda, una inspección o una auditoría
Cuando el software rinde cuentas ante un tercero, las reglas dejan de ponerlas tu empresa. El formato lo marca el organismo, los plazos también, y cuando la norma cambia el programa cambia con ella. Eso exige trazabilidad, registros que no se puedan reescribir sin dejar rastro, control de envíos y gestión de rechazos. Es software con vida propia después de la entrega: el mantenimiento deja de ser opcional. Por eso mantengo dos productos propios ahí: SILICIE VapeTax, para impuestos especiales del vapeo, y Tictacdicta, para el registro de jornada. Si tu caso entra ahí, el presupuesto tiene que incluir el después.
Migrar los datos de lo anterior casi nunca es exportar e importar
Los datos viejos llevan años de decisiones humanas encima. Clientes duplicados, un campo de observaciones donde alguien guardaba información crítica, NIF con formatos distintos, precios que ya no aplican. Migrar no es mover ficheros: es decidir qué se conserva, qué se limpia y qué se abandona, y eso lo decides tú, porque solo tú sabes qué significa cada cosa. Luego está el corte, el día que se apaga lo antiguo.
- Cuánto histórico necesitas de verdad y cuánto es solo por si acaso.
- Quién valida que los totales del sistema nuevo cuadran con los del viejo.
- Si basta con poder consultar lo antiguo en solo lectura.
Por qué un presupuesto cerrado sin diagnóstico previo es una señal de alarma
Un número exacto sobre información incompleta solo puede acabar de tres maneras. Una: llevaba un colchón enorme y pagas de más por si acaso. Dos: se queda corto, y aparecen los extras o el proyecto se muere a mitad. Tres: se cumple recortando por donde no se ve, que son las pruebas, la seguridad, el rendimiento y la documentación. Las tres las pagas tú. Un precio cerrado es honesto cuando el alcance está cerrado, y el alcance solo se cierra después de mirar. Por eso el diagnóstico se cobra y se entrega como documento tuyo: si no te convencemos, te lo llevas a otro y le sirve igual.
El trabajo por fases no protege al desarrollador, te protege a ti
Por fases no significa sin compromiso ni a ver qué sale. Significa que cada fase tiene alcance, precio y entregable definidos, y que al terminarla puedes seguir, corregir el rumbo o parar sin haberlo perdido todo. La primera fase es entender el problema. La segunda debería ser el núcleo que resuelve lo que más duele, en producción y usado por gente real, no una demo. A partir de ahí decides con datos. El orden lo marca el riesgo: primero lo más incierto, no lo más vistoso. Lo bonito es fácil de añadir después; lo incierto no.
Qué preguntar a cualquier desarrollador antes de firmar
Valen para cualquier proveedor, sea este o cualquier otro. Si alguna incomoda a quien tienes enfrente, ya has aprendido algo.
- De quién es el código al terminar y cuándo tendré acceso al repositorio.
- A nombre de quién quedan el dominio, el hosting y las cuentas de los servicios.
- Qué pasa si mañana no estás: puede otro coger esto y cómo se despliega.
- Qué entra y qué no en el mantenimiento. Corregir un fallo no es añadir una función.
- Cómo se piden los cambios y cómo se valoran antes de hacerlos.
- Dónde se alojan los datos y quién más tiene acceso.
- Hay copias de seguridad y se ha restaurado alguna. Una copia sin restaurar nunca no es una copia.
- Qué pruebas automáticas hay y quién se entera antes de que la aplicación falle, tú o yo.
- Qué me llevo si el proyecto se para al acabar la segunda fase.
- Puedo ver software tuyo funcionando, no solo capturas.
Lo que encarece un proyecto sin darte nada a cambio
No todo lo que sube el presupuesto aporta valor. Copiar el proceso viejo tal cual, con sus vicios, en vez de simplificarlo antes de programarlo. Pedir que todo sea configurable cuando hay una sola forma de trabajar. Encargar una app móvil cuando una web bien hecha resuelve lo mismo. Y la clásica: funciones por si algún día. Cada una se paga dos veces, al construirla y al mantenerla.
Preguntas frecuentes
¿Cuánto cuesta un software a medida?+
No hay tarifa de catálogo, y quien da una cifra sin preguntar nada no presupuesta, tantea. El coste depende de cinco cosas: cuántos tipos de usuario entran, con cuántos sistemas ya existentes hay que conectar, si mueve dinero o datos personales, si tiene que rendir cuentas ante un organismo y cuántos datos antiguos hay que migrar. Con esos cinco puntos claros, cualquier desarrollador puede darte un rango razonado.
¿Sale más barato un programa estándar que uno a medida?+
El estándar suele costar menos al principio y merece la pena mirarlo antes de encargar nada. El coste real aparece cuando tu forma de trabajar no encaja: licencias por usuario, módulos extra, horas de configuración y el trabajo manual que hace tu gente para tapar lo que no cubre. Lo a medida tiene sentido cuando tu proceso es parte de tu ventaja o cuando una obligación concreta no la cubre nadie.
¿Puedo pedir un presupuesto cerrado para todo el proyecto?+
Puedes, siempre que el alcance esté cerrado antes, y eso exige un diagnóstico que mire procesos, roles, integraciones y datos. Lo más sano es cerrar precio por fases: cada una con su alcance, su precio y su entregable, y tú decidiendo si sigues. Un precio cerrado sobre un proyecto que nadie ha mirado esconde un colchón o un recorte, y los dos los pagas tú.
¿De quién es el código de una aplicación a medida?+
De quien diga el contrato, así que conviene que lo diga claro antes de firmar. Si pagas un desarrollo a medida, lo razonable es que el código sea tuyo y que tengas acceso al repositorio desde el primer día, no en la entrega. Lo mismo con el dominio, el hosting y las cuentas de los servicios: a tu nombre y con tus credenciales. Si alguien se niega, tienes un problema.
¿El mantenimiento de un software a medida se paga aparte?+
Normalmente sí, y lo importante es que quede escrito qué incluye. Arreglar un fallo de algo ya acordado no es lo mismo que añadir una función nueva. Además hay trabajo que no se ve: actualizaciones de seguridad, copias, vigilancia para enterarte de una caída antes que tus clientes y cambios que imponen terceros, como una pasarela o una norma. En software con obligaciones legales, el mantenimiento no es opcional.
¿Qué pasa si a mitad del proyecto cambio de idea sobre algo?+
Es normal y no es un drama si el proyecto va por fases y hay algo funcionando pronto. Lo caro no es cambiar de idea: es cambiarla tarde sobre una pieza que ya tiene otras encima. Por eso conviene atacar primero lo más incierto y enseñar software real cuanto antes. Todo cambio cuesta: pide que se valore por escrito antes de ejecutarlo.
¿Quieres saber qué mueve el precio en tu caso?
Cuéntanos qué haces, con qué herramientas trabajas hoy y qué te está costando tiempo o dinero. Con eso te decimos si necesitas software a medida, si te vale algo que ya existe o si lo que tienes se puede arreglar. Y si hace falta un diagnóstico antes de presupuestar, te explico qué te llevas de él.
Cuéntanos tu caso