Antes de pedir presupuesto
Contratar una empresa de desarrollo es dejar en manos de otros una parte de tu negocio que probablemente no puedes revisar línea por línea. No vas a leer el código, pero vas a convivir con él: con la lentitud, con el error que vuelve cada semana, con lo difícil que resulta cambiar una pantalla sencilla. Por eso la decisión tiene que ir más allá del precio y de la buena impresión en la primera reunión.
Antes de hablar con proveedores, escribe en pocas líneas el problema que resuelve el proyecto, quién lo va a usar, qué tiene que estar listo en la primera versión y si hay una fecha que no se puede mover, como un lanzamiento o una temporada de ventas. Ese resumen te ayuda a comparar respuestas y a notar quién está prestando atención a tu caso y quién repite un guion.
Portafolio: pide proyectos en línea
Una imagen bonita en Behance o Instagram no demuestra que el sistema funcione. Pide enlaces a proyectos publicados: el sitio que carga, la app que se puede instalar, la tienda que vende de verdad. Ábrelos en el celular, navega, completa el formulario y fíjate si la página sigue siendo rápida con datos móviles.
Pregunta también cuál fue el papel de la empresa en cada proyecto. ¿Hizo todo o solo el diseño? ¿Tomó un sistema a medio hacer y lo terminó? ¿Sigue a cargo hoy? Una empresa seria responde sin rodeos y, cuando hay un acuerdo de confidencialidad, explica qué puede mostrar y qué no.
Si tu proyecto tiene un requisito específico, como cobros recurrentes, integración con un ERP o una función de inteligencia artificial, pregunta si ya construyeron algo parecido y pide verlo funcionando. La experiencia con tu tipo de problema vale más que la experiencia con la tecnología de moda.
Cómo es el proceso, del diagnóstico a la entrega
Pregunta qué pasa entre la firma y el lanzamiento. La respuesta debería tener etapas claras: entender el negocio, definir el alcance, diseñar las pantallas, desarrollar, probar y publicar. Cuando una empresa salta directo del presupuesto a la programación, las dudas que deberían haber surgido en el diagnóstico aparecen a mitad del proyecto, cuando corregir cuesta más.
Fíjate también en el ritmo de entregas. Los proyectos divididos en etapas cortas, con versiones de prueba que abres en tu propio celular o navegador, permiten corregir el rumbo a tiempo. El formato contrario, meses de silencio y una gran entrega al final, es donde nacen las peores sorpresas.
- ¿Cuál es la primera etapa y qué recibo cuando termina?
- ¿Voy a ver un prototipo de las pantallas antes de que empiece el desarrollo?
- ¿Cada cuánto recibo una versión para probar?
- ¿Quién prueba el sistema y en qué dispositivos?
- ¿Qué pasa si quiero cambiar algo a mitad del camino?
Quién hace el trabajo y cómo se van a comunicar
Quien vende no siempre es quien construye. Algunas empresas cierran el contrato y pasan el desarrollo a freelancers o a otra empresa, y el cliente se entera cuando baja la calidad o cuando nadie sabe responder una pregunta técnica. Subcontratar una parte no está prohibido, pero tiene que quedar claro desde el principio. Pregunta quién va a trabajar en el proyecto, si es un equipo propio y si podrás hablar con quien programa cuando lo necesites.
Acuerden también cómo será la comunicación: por qué canal, con qué frecuencia llegan las novedades y quién es la persona de referencia de cada lado. Una llamada corta por semana con lo que se hizo, lo que sigue y lo que está trabado resuelve más que decenas de mensajes sueltos. Si vas a contratar un equipo en otro país de la región, por ejemplo una empresa brasileña, pregunta por las horas de trabajo en común y el idioma del día a día. Y observa cómo se comunica la empresa durante el presupuesto. Si tarda días en responder ahora, difícilmente acelere después de firmar.
Código, dominio y cuentas: de quién es cada cosa
Esta es la pregunta que mucha gente olvida y que más duele después. ¿El código fuente es tuyo? ¿El dominio está registrado a nombre de tu empresa? ¿Las cuentas de hosting, base de datos, App Store, Google Play y pasarela de pago están a tu nombre o al de la empresa de desarrollo?
El escenario que hay que evitar es aquel en el que todo está en las cuentas del proveedor. Si la relación termina, te quedas sin acceso a tu propio producto o tienes que negociar para recuperarlo. Lo ideal es que el código esté en un repositorio al que tengas acceso, que las cuentas principales estén a tu nombre y que haya documentación suficiente para que otro equipo pueda continuar.
Pregunta qué tecnologías van a usar y por qué. Un stack consolidado y bien documentado facilita contratar a otra persona en el futuro. Una herramienta propietaria que solo esa empresa sabe operar te ata a ella.
Contrato y alcance por escrito
Una buena propuesta describe lo que se va a entregar con el detalle suficiente para evitar discusiones después: pantallas, funciones, perfiles de usuario, integraciones, lo que queda fuera del alcance, el plazo de cada etapa, el valor y la forma de pago. Frases como "sistema completo de gestión" o "una app igual a la de la competencia" no sirven como alcance, porque cada parte va a imaginar algo distinto.
Lee con atención qué pasa cuando surge un cambio. Va a surgir, porque el proyecto enseña cosas que nadie sabía al principio. El contrato tiene que decir cómo se evalúan, presupuestan y aprueban los cambios antes de entrar en el cronograma. Revisa también la garantía de corrección de errores después de la entrega, la confidencialidad, el tratamiento de datos personales según la ley que te aplique y las condiciones para terminar la relación.
Qué pasa después del lanzamiento
Lanzar es el comienzo del uso real, y con el uso real aparecen los ajustes. Una pantalla que se rompe en un modelo de celular específico, un flujo que los clientes no entienden, una integración que cambia de versión sin aviso. Pregunta quién se encarga de eso, en cuánto tiempo y cómo se cobra.
Pregunta si hay un plan de mantenimiento, qué cubre (correcciones, actualizaciones de seguridad, pequeñas mejoras, monitoreo) y cómo funciona cuando quieras una función nueva. La empresa que entrega y desaparece te deja buscando otro proveedor para trabajar sobre un código que no conoce, y ese nuevo comienzo suele salir caro.
Señales de alerta antes de firmar
Algunos comportamientos aparecen antes del contrato y dicen mucho sobre cómo será el proyecto:
Desconfía también del exceso de jerga técnica usada para impresionar. Quien domina el tema puede explicar en palabras simples por qué una decisión tiene sentido para tu caso.
- Un presupuesto enviado sin ninguna pregunta sobre tu negocio, tu público o las reglas del sistema.
- Un plazo demasiado corto para el tamaño del alcance, prometido antes de entender el proyecto.
- Un "hacemos de todo" ante cualquier pedido, sin señalar riesgos ni sugerir qué puede quedar para después.
- Resistencia a mostrar proyectos en línea o a decir quién va a desarrollar.
- Código, dominio y cuentas que quedan a nombre de la empresa contratada.
- Pago total por adelantado, sin etapas ligadas a entregas.
- Una propuesta sin ninguna línea sobre lo que queda fuera del alcance.
Preguntas para llevar a la reunión
Si quieres un guion, lleva estas preguntas a cada proveedor y compara las respuestas lado a lado. Más que el contenido, fíjate en quién responde con claridad y en quién se va por las ramas.
En BG Coding el presupuesto sale solo después de entender el proyecto, y la propuesta llega con alcance, plazo y valor definidos, dividida en etapas que puedes seguir. El código y los accesos quedan en manos del cliente. Si estás comparando proveedores, puedes usar esta misma lista con nosotros.
- ¿Puedo ver proyectos parecidos al mío funcionando?
- ¿Cuáles son las etapas y qué recibo en cada una?
- ¿Quién va a trabajar en el proyecto y con quién hablo en el día a día?
- ¿Cada cuánto voy a probar una versión nueva?
- ¿El código, el dominio y las cuentas quedan a mi nombre?
- ¿Cómo se manejan los cambios de alcance?
- ¿Qué incluye el servicio después del lanzamiento?