«Necesito un sistema para mi negocio» sirve para iniciar una conversación, pero no alcanza para comparar presupuestos. Una propuesta puede incluir una primera versión pequeña y otra contemplar todos los módulos imaginables. Aunque ambas tengan el mismo título, están cotizando trabajos distintos.
Para pedir un presupuesto de software a medida, no necesitás escribir especificaciones técnicas. Necesitás explicar el problema, mostrar cómo se trabaja hoy y definir qué resultado debería entregar la primera versión. Con esa base vas a recibir propuestas más claras y vas a poder comparar alcance, plazos y responsabilidades además del precio.
1. Contá el problema con un ejemplo real
Empezá por una situación que ocurra durante una jornada normal:
Cuando entra una compra, cargamos la factura en una planilla y después actualizamos el stock en otra. Si alguien olvida el segundo paso, vendemos con cantidades equivocadas.
Ese ejemplo aporta más información que «quiero digitalizar el stock». Identifica el evento, las herramientas actuales, el trabajo duplicado y el error que se quiere evitar.
Prepará dos o tres casos frecuentes. Si el proceso tiene excepciones importantes, agregá una: una compra que llega incompleta, una devolución o un pedido que cambia después de ser confirmado. El equipo que cotiza podrá descubrir las reglas que realmente afectan el desarrollo.
2. Describí cómo trabajan hoy
Mostrá las planillas, formularios, mensajes o sistemas que intervienen. No hace falta ordenar todo antes de la reunión: el desorden también explica dónde está el problema.
Anotá:
- quién inicia cada tarea;
- qué información recibe;
- dónde la registra;
- quién la revisa o aprueba;
- qué resultado necesita al final;
- qué pasa cuando hay un error.
También conviene indicar el volumen aproximado: usuarios, operaciones por día, productos, clientes o documentos. No es lo mismo diseñar una pantalla que usa una persona algunas veces por semana que un flujo de mostrador atendido por varias personas al mismo tiempo.
No compartas datos personales o comerciales sensibles en una primera consulta. Podés usar registros ficticios que conserven la estructura real.
3. Definí el resultado de la primera versión
Una primera versión útil resuelve un recorrido completo. Por ejemplo: registrar una compra recibida, actualizar el inventario y poder consultar el movimiento. Una lista de veinte pantallas sin relación entre sí dificulta estimar y validar el proyecto.
Separá las funciones en tres grupos:
- Necesarias para operar: sin ellas la primera versión no resuelve el problema.
- Útiles después del lanzamiento: agregan valor, pero pueden esperar.
- Ideas para explorar: todavía no está claro cómo funcionarían o si se usarían.
Esta priorización permite ajustar el presupuesto reduciendo alcance sin romper el objetivo central. También evita pagar desde el comienzo por funciones basadas en supuestos.
4. Aclarar usuarios y permisos
Decir «tendrá usuarios» deja preguntas abiertas. Indicá qué tipos de personas entran y qué puede hacer cada una.
En un sistema de gestión podrían existir dueño, administrador y operador. En Proyecto Legal, los roles y permisos eran relevantes porque no todo el personal necesitaba acceder a todos los expedientes. En FP Repuestos, el núcleo estaba en registrar compras, ventas y movimientos de inventario para un negocio pequeño.
Los dos son sistemas de gestión, pero el tipo de información y las reglas de acceso cambian el trabajo necesario. Por eso conviene incluir los perfiles desde el presupuesto inicial.
5. Enumerá integraciones y datos existentes
Si el nuevo sistema debe conectarse con facturación, pagos, WhatsApp, correo, un ecommerce o un software anterior, mencioná cada herramienta con su nombre y plan actual. La posibilidad de integrarla depende de que exista una API, de los permisos disponibles y de las condiciones del proveedor.
También explicá qué información hay que importar. Una planilla con quinientos productos limpios es distinta de varios archivos con nombres duplicados y formatos diferentes. Pedí que la propuesta aclare quién prepara los datos, qué campos se migran y cómo se validará el resultado.
Cuando una integración todavía no fue comprobada, debería figurar como supuesto o tarea de investigación. Así queda claro qué puede cambiar el alcance.
6. Pedí entregables verificables
Un presupuesto claro describe qué se entrega y cómo se acepta. Para cada etapa, buscá resultados que puedas revisar:
- prototipo o recorrido aprobado;
- módulo funcionando con casos acordados;
- importación de datos de prueba;
- acceso para usuarios definidos;
- despliegue en el entorno acordado;
- capacitación y documentación necesarias.
«Panel administrativo» es demasiado amplio. «El administrador puede crear productos, actualizar precios y consultar movimientos por fecha» se puede probar.
También pedí que se indique qué queda fuera. Esa sección evita interpretar el silencio como una función incluida.
7. Separá desarrollo, servicios y soporte
El costo de poner un sistema en funcionamiento puede incluir conceptos diferentes:
- relevamiento y diseño;
- desarrollo y pruebas;
- migración de información;
- hosting, dominio o almacenamiento;
- servicios externos de correo, mensajería o pagos;
- mantenimiento y soporte posterior;
- nuevas funciones después de la entrega.
Preguntá qué costos son únicos, cuáles se repiten y cuáles dependen del uso. Las guías publicadas en 2026 por Altura y Wizza coinciden en un punto útil para comparar: el presupuesto debe definir alcance y entregas, y separar el trabajo inicial de los costos operativos posteriores.
No hace falta contratar un abono indefinido para todo proyecto, pero sí acordar qué ocurre después del lanzamiento: cuánto dura la corrección de errores, por qué canal se reportan y cómo se cotizan los cambios.
8. Compará propuestas con la misma matriz
No ordenes los presupuestos únicamente por total. Para cada propuesta, revisá estas preguntas y anotá las respuestas en tu propio documento:
| Criterio | Qué comparar |
|---|---|
| Problema principal | ¿La primera entrega permite completar el flujo que necesitás? |
| Funciones | ¿Qué incluye y qué queda explícitamente fuera? |
| Datos | ¿Quién prepara, importa y comprueba la información existente? |
| Integraciones | ¿Se verificaron accesos y compatibilidad con tus herramientas? |
| Entregas | ¿Qué vas a recibir en cada etapa y cómo se comprobará? |
| Costos recurrentes | ¿Cuánto cuestan hosting, servicios externos y mantenimiento? |
| Soporte | ¿Qué cubre, durante cuánto tiempo y cómo se solicitan cambios? |
| Datos y continuidad | ¿Podés exportar tu información y continuar con otro proveedor? |
Si una propuesta cuesta menos porque cubre una primera etapa acotada, puede ser la opción correcta. Si cuesta menos porque deja indefinidos la migración, el despliegue o el soporte, necesitás aclararlo antes de decidir.
Un briefing breve que podés copiar
Para iniciar una consulta, completá esto:
- Negocio y equipo: qué hacen y quiénes usarían el sistema.
- Problema: qué sucede hoy, con uno o dos ejemplos.
- Proceso actual: herramientas y pasos principales.
- Resultado esperado: qué debería poder completarse de punta a punta.
- Primera versión: funciones imprescindibles.
- Datos: qué existe y cuánto habría que importar.
- Integraciones: herramientas con las que debe conectarse.
- Restricciones: fecha necesaria, dispositivos, conectividad o presupuesto disponible.
- Responsable: quién tomará decisiones y validará las entregas.
Podés adjuntar capturas o una planilla de ejemplo sin información sensible. No necesitás elegir la tecnología; esa decisión debe justificarse después de entender el proceso.
Qué hacemos en LevelAr con esa información
La primera conversación sirve para decidir si conviene mejorar una herramienta existente, conectar servicios o desarrollar una solución propia. Si el proyecto requiere software, el objetivo es convertir el problema en una primera etapa que se pueda usar y comprobar.
Si estás comparando opciones, también podés revisar cuándo conviene dejar Excel y cómo abordamos el desarrollo de software a medida.
¿Tenés un proceso que querés ordenar? Contame cómo funciona hoy. Con un ejemplo real alcanza para empezar a delimitar el proyecto.