Cómo cotizar un proyecto de software en Colombia

Imagina que pides tres cotizaciones para el mismo proyecto y que la más alta es varias veces la más baja. Las tres dicen ser para "lo mismo".

Es fácil concluir que alguien te quiere cobrar de más. Lo más probable es otra cosa: cada proveedor está cotizando un proyecto diferente, porque nadie ha tomado todavía las decisiones que definen qué se va a construir.

Este artículo explica qué mueve el precio de un proyecto de software, por qué un rango depende de decisiones y qué revisar en una cotización. No vas a encontrar una tabla de precios, porque sin esas decisiones cualquier cifra publicada te diría muy poco sobre tu proyecto.

Por qué "lo mismo" no es lo mismo

Toma una descripción como "quiero una app para gestionar pedidos". Un proveedor imagina una lista de pedidos en el celular. Otro incluye inventario y reportes. Un tercero asume que se conecta con tu sistema contable. Sus cotizaciones no se pueden comparar, porque describen cosas distintas.

Un rango es el abanico de decisiones que te faltan

Un ejemplo hipotético: una tienda en línea. La pregunta "¿cómo te pagan los clientes?" tiene al menos tres respuestas, y cada una es un proyecto distinto:

• Sin pagos en la tienda. El cliente arma su pedido y tu equipo lo cobra por fuera. El sistema solo registra el pedido.
• Con link de pagos. El sistema o tu equipo le envía al cliente un enlace, y alguien tiene que confirmar que el pago entró antes de despachar.
• Con pasarela integrada. El cliente paga dentro de la tienda, con tarjeta o PSE. Ahora el sistema debe confirmar el pago, descontar el inventario y resolver qué pasa si un pago queda pendiente o hay que devolver el dinero.

Ninguna es la correcta de entrada. Depende de cuántos pedidos recibes y de cuánto trabajo manual puedes sostener. Mientras esa decisión esté abierta, lo honesto es que el precio sea un rango.

Por eso un rango serio viene con condiciones: qué cubre y qué lo llevaría hacia arriba o hacia abajo.

Qué mueve el precio

Estas son las preguntas que más pesan al estimar un proyecto:

• Tipos de usuario y permisos. Un sistema con un solo tipo de usuario es más simple que uno donde el vendedor, el bodeguero y el gerente ven cosas distintas.
• Conexiones con otros sistemas. Conectarse con tu contabilidad o con la facturación electrónica ante la DIAN es trabajo adicional, y depende de qué tan bien se dejen conectar esos sistemas.
• Casos borde, es decir, situaciones poco frecuentes pero reales, como un cliente que paga dos veces o un pedido que se devuelve a medias. Cada uno que se quiera resolver dentro del sistema suma trabajo.
• Atributos de calidad, o sea, cuántos usuarios aguanta sin caerse, qué tan rápido responde y qué tan protegidos están los datos. Si manejas datos personales, también cuenta lo que exige la Ley 1581 de 2012.
• Plataformas. Una aplicación web, una app para Android y otra para iPhone no representan el mismo trabajo.
• Datos existentes. Pasar años de información desde hojas de cálculo o desde un sistema viejo puede ser un trabajo por sí solo.
• Lo que pasa después de la entrega. Quién corrige errores, quién mantiene el sistema y cuánto cuestan cada mes los servidores y los servicios externos.

Si el presupuesto no alcanza

Quien tiene presupuesto de Volkswagen no se lleva un Ferrari con descuento. Lo sensato es definir un Volkswagen bien hecho: construir menos cosas, con el mismo cuidado.

En la práctica, eso significa recortar el alcance. Puedes empezar por un MVP (producto mínimo viable: la primera versión más pequeña que ya resuelve el problema, por ejemplo, la tienda con link de pagos antes que con pasarela) y dejar el resto para fases posteriores. Desconfía de quien responde a un presupuesto bajo con el mismo alcance a menor precio, porque el recorte puede terminar donde no lo ves.

Qué revisar en una cotización

Debería decir	Suele quedar por fuera
Lista de funcionalidades incluidas	Lo que el cliente da por sentado y nadie escribió
Con qué sistemas se conecta	Costos de servicios de terceros
Tipos de usuario y permisos	Qué tan compleja es la gestión de accesos
Fases, con lo que se entrega en cada una	De qué dependen, y qué las puede retrasar
A nombre de quién quedan el código y las cuentas	Costos mensuales de servidores
Qué pasa después de la entrega	Quién corrige errores cuando el proyecto termina

Cada elemento que falta es una conversación incómoda más adelante, así que mejor tenerla ahora.

Señales de alerta

Precio fijo sin alcance definido. Si el documento dice un valor "por el proyecto completo" y no detalla qué incluye, ese precio protege poco. El proveedor puede entregar lo mínimo y argumentar que cumplió.

Sin fases ni entregas intermedias. Si la cotización es solo un total, no tienes cómo hacer seguimiento hasta el final.

Plazos que parecen demasiado buenos. Pregunta qué se está dejando por fuera para cumplirlos. O el proveedor no entendió el alcance o va a recortar en algún punto.

Tecnologías sin mencionar. Si no sabes qué se va a usar, te queda difícil pedir una segunda opinión o cambiar de proveedor más adelante.

Precio antes de preguntas. Si recibes un número sin que nadie te haya preguntado por tus usuarios, tus procesos o tus sistemas actuales, ese número no sale de tu proyecto.

Señales de que vas por buen camino

Te hacen preguntas incómodas. Un proveedor responsable necesita entender tu negocio antes de hablar de cifras, y es normal que te haga pensar cosas que no habías considerado.

Te dicen por escrito qué entendieron. Así puedes corregir un malentendido antes de que se vuelva un problema.

El costo está separado por partes. Te permite ver qué vale qué y priorizar.

Te explican qué mueve el rango. Pregunta qué haría cambiar la cifra. Una respuesta sana: que aparezca algo que no se había contado, como una conexión con tu sistema contable que nadie mencionó. Lo que ya se sabía cuando te dieron el rango no debería ser razón para subirlo.

Qué preparar antes de pedir cotizaciones

Si escribes estas respuestas y le entregas el mismo texto a cada proveedor, las cifras que recibas se van a parecer más a una comparación real:

• ¿Quiénes van a usar el sistema y qué necesita hacer cada uno?
• ¿Con qué sistemas debe conectarse?
• ¿Sin qué funciones el proyecto no tendría valor para tu negocio?
• ¿Qué presupuesto tienes, y hay alguna fecha que de verdad no se pueda mover?
• ¿Cómo vas a saber que el proyecto funcionó?

Si te cuesta responderlas, es normal. Es justo el trabajo que hay por hacer antes de construir.

Cómo lo hacemos en Sigma Dev

En Sigma Dev, ese trabajo es la primera fase del proyecto: entendemos tu negocio, buscamos los puntos ciegos y tomamos contigo las decisiones importantes, como la de los pagos en el ejemplo de la tienda. De ahí salen el alcance, las fases y el precio, conectados con esas decisiones. Lo explicamos en nuestro método.

Si ya tienes un sistema y lo que necesitas es mejorarlo, la conversación empieza distinto: por revisar lo que hay.

Cuando quieras hablar de lo tuyo, cuéntanos tu proyecto.