Cómo coordinar el desarrollo de tu app con un proveedor externo: guía para no técnicos
Encargar una app sin ser técnico: el reto real
Has decidido que tu negocio necesita una app y tienes claro que no la vas a desarrollar dentro de casa. Vas a confiar en una empresa externa. Hasta aquí, bien. El problema aparece cuando te sientas en la primera reunión, empiezan a hablar de backend, endpoints y sprints, y sientes que estás firmando un cheque en blanco sobre algo que no entiendes del todo.
Es una situación muy común entre gerentes y fundadores de pymes españolas. La buena noticia: coordinar bien un proyecto de app no depende de que sepas programar, sino de que sepas gestionar la relación, hacer las preguntas correctas en el momento correcto y establecer puntos de control claros. Esta guía recorre todo el proceso, desde la definición inicial hasta el traspaso, para que mantengas el control sin fingir una experiencia técnica que no tienes.
Antes de buscar proveedor: define objetivos y alcance
El error más caro no es elegir mal al desarrollador, es empezar a hablar con desarrolladores sin tener claro qué quieres. Cuando llegas con un "quiero una app para mi negocio" a secas, cada proveedor te presupuestará una cosa distinta y no podrás compararlos.
Antes de pedir presupuestos, dedica tiempo a poner por escrito tres cosas concretas.
- El problema que resuelve la app. No la funcionalidad, el problema. Por ejemplo: "mis clientes pierden 20 minutos al teléfono para reservar cita" o "no sé qué stock tengo hasta que voy al almacén".
- Quién la va a usar. Clientes finales, tus comerciales, el personal de almacén. El usuario cambia por completo el enfoque.
- Qué es imprescindible en la primera versión y qué puede esperar. Esta distinción, la de un producto mínimo viable frente a la lista de deseos completa, es la que más presupuesto ahorra.
No necesitas una especificación técnica. Necesitas una descripción de negocio lo bastante clara como para que dos empresas distintas la lean y entiendan lo mismo. Si no sabes por dónde empezar a poner orden en esas ideas, un buen partner te ayuda precisamente en esta fase, antes de escribir una sola línea de código.
Elegir proveedor: qué mirar más allá del precio
Cuando recibas tres o cuatro presupuestos, la tentación es ir directo al total y quedarte con el más barato. Es comprensible cuando el dinero es tuyo, pero en desarrollo a medida el precio más bajo suele esconder un alcance recortado que descubrirás a mitad de proyecto, ya con facturas encima.
Señales de un proveedor con el que se trabaja bien
- Te hace preguntas incómodas. Un buen desarrollador cuestiona tu idea, detecta lagunas y te propone alternativas más baratas o más sólidas. El que dice a todo que sí suele estar vendiéndote humo.
- Presupuesto desglosado. Debes poder ver qué incluye cada partida, no un número global. Si no entiendes una línea, pide que te la expliquen en lenguaje llano; si no saben, mala señal.
- Referencias y proyectos reales. Pide ver apps que hayan lanzado y, si puedes, habla con algún cliente anterior. Una llamada de diez minutos te dice más que veinte páginas de propuesta.
- Cercanía y disponibilidad. Vas a hablar con esta gente durante meses. Trabajar con un equipo que responde y con el que te entiendes vale más de lo que parece.
Desconfía también del extremo contrario: un presupuesto desorbitado no garantiza calidad. Lo que buscas es coherencia entre lo que pides, lo que te proponen y lo que cuesta.
Comunicación y roles: quién habla con quién
Uno de los motivos por los que los proyectos se descontrolan es que nadie tiene claro quién decide. Desde el primer día conviene fijar dos figuras.
Por tu parte, designa una única persona de referencia que canalice las decisiones. Puedes ser tú o alguien de confianza, pero que sea una sola voz. Cuando tres personas de la empresa mandan indicaciones distintas al desarrollador, el proyecto se convierte en un caos y los sobrecostes están garantizados.
Por parte del proveedor, pregunta quién es tu interlocutor de proyecto, normalmente un jefe de proyecto o project manager. Esa persona traduce entre tu lenguaje de negocio y el técnico del equipo. Que exista este rol es una excelente señal: significa que no tendrás que entenderte directamente con los programadores para cada detalle.
Acordad también la cadencia de comunicación: una reunión de seguimiento cada una o dos semanas, un canal para dudas rápidas y un lugar único donde vivan los documentos y las decisiones. Evita que los acuerdos importantes queden enterrados en cadenas de correos o en mensajes sueltos de WhatsApp.
Metodología: por qué se trabaja por entregas
La mayoría de equipos serios trabaja por sprints: ciclos cortos, de dos o tres semanas, al final de los cuales te muestran algo funcionando. Olvida la idea de encargar la app, desaparecer tres meses y recibir el producto terminado. Ese modelo, el del proyecto entregado de una sola vez al final, es el que más disgustos provoca, porque descubres que no era lo que esperabas cuando ya no hay margen ni presupuesto para cambiarlo.
El trabajo por entregas te da algo muy valioso para alguien no técnico: puntos de control regulares donde ver avances reales y corregir el rumbo. No necesitas entender el código, necesitas ver la pantalla funcionando y decir "esto sí" o "esto no es lo que imaginaba".
Si quieres profundizar en cómo se estructura un proyecto de este tipo antes de arrancar el tuyo, merece la pena que hablemos de tu caso concreto y del enfoque de entregas que mejor encaja, porque no todos los proyectos necesitan la misma cadencia.
Cómo revisar avances y demos sin ser técnico
Al final de cada entrega tendrás una demo. Este es tu momento de mayor control, así que aprovéchalo. No hace falta que evalúes la calidad del código; para eso pagas al proveedor. Tu trabajo es comprobar que lo construido resuelve el problema de negocio.
En cada demo, prueba tú mismo los flujos principales como si fueras el usuario final. Intenta reservar esa cita, registrar ese pedido, consultar ese dato. Si algo te resulta confuso a ti, que conoces el negocio, será mucho peor para un cliente que llega de nuevas.
- ¿Hace lo que acordamos para esta entrega?
- ¿Un usuario normal entendería cómo usarlo sin que nadie se lo explique?
- ¿Qué pasa si me equivoco, si dejo un campo vacío o pongo un dato raro?
- ¿Falta algo que dábamos por hecho y no se habló?
Anota lo que veas y compártelo por escrito. Un comentario del tipo "no me convence" no ayuda a nadie; "cuando intento pagar y no hay conexión, la app se queda en blanco" sí es accionable. Cuanto más concreto seas, mejor será el resultado.
Gestión de cambios y presupuesto
Vas a querer cambiar cosas sobre la marcha. Es normal y hasta sano: ver la app funcionando te dará ideas que no tenías al principio. El problema no son los cambios, es gestionarlos sin criterio.
Distingue entre dos tipos. Un ajuste es afinar algo que ya estaba previsto: mover un botón, cambiar un texto, corregir un comportamiento. Suele entrar dentro de lo acordado. Una funcionalidad nueva es trabajo que no estaba en el alcance inicial, y es lógico que tenga coste y plazo adicionales. Un proveedor honesto te avisará cuando una petición cruza esa línea, en lugar de acumular horas en silencio para sorprenderte con la factura.
Acordad desde el principio cómo se tratan los cambios de alcance: que cualquier añadido relevante se estime por escrito, con su coste y su impacto en el plazo, antes de ejecutarlo. Así decides tú, con la información delante, si compensa. Esta transparencia es lo que evita las discusiones desagradables al final del proyecto.
Propiedad del código y documentación
Este es un punto que muchos no técnicos pasan por alto y luego pagan caro. Deja por escrito, en el contrato, que el código de tu app es tuyo una vez pagado. Parece obvio, pero no siempre lo es: hay proveedores que entregan la app funcionando pero se reservan el código fuente, lo que te ata a ellos para cualquier cambio futuro.
Asegúrate también de que a la finalización recibes:
- El código fuente completo, alojado en un repositorio al que tengas acceso.
- Las credenciales y accesos a servidores, tiendas de aplicaciones y servicios contratados, a tu nombre y no al del proveedor.
- Una documentación básica que explique cómo está montado el sistema, para que otro equipo pueda retomarlo si algún día hace falta.
No se trata de desconfiar, sino de proteger tu inversión. Si mañana quieres cambiar de proveedor o incorporar un desarrollador propio, estos materiales marcan la diferencia entre continuar con normalidad y tener que empezar de cero.
Pruebas y aceptación: cerrar bien el proyecto
Antes de dar por buena la app, tiene que pasar por una fase de pruebas seria. Parte la hace el equipo técnico, pero hay una parte que te corresponde a ti: la aceptación de usuario. Consiste en que tú, y si puedes algunas personas que vayan a usarla de verdad, probéis la aplicación en situaciones reales antes del lanzamiento.
Prepara una lista sencilla de las cosas que la app debe hacer sin fallos, la que salió de tus objetivos iniciales, y ve comprobándolas una a una. Prueba en distintos móviles si puedes, porque lo que funciona en un iPhone reciente no siempre se ve igual en un Android de gama media de hace tres años, que es el que tienen muchos de tus clientes.
Define con el proveedor qué significa "terminado". Un criterio claro de aceptación, acordado por ambas partes, evita el limbo de un proyecto que ni se cierra ni avanza porque nadie sabe cuándo se considera completo.
Traspaso y mantenimiento: el día después del lanzamiento
Lanzar la app no es el final, es el principio de su vida útil. Los móviles se actualizan, los sistemas operativos cambian, aparecen errores que no se vieron en pruebas y, con suerte, tu negocio crece y necesitas funciones nuevas. Una app sin mantenimiento se degrada en cuestión de meses.
Antes de firmar, habla del después. Pregunta qué incluye la garantía tras la entrega, cómo se reportan y resuelven las incidencias y qué opciones de mantenimiento continuado ofrecen. No siempre necesitarás el contrato de soporte más completo, pero sí saber a quién llamar cuando algo falle un viernes por la tarde.
Lo ideal es que el proveedor que construyó la app siga acompañándote, porque nadie conoce mejor su funcionamiento. Por eso conviene elegir desde el principio un partner con el que quieras mantener una relación a largo plazo, no solo alguien que te resuelva la primera versión y desaparezca.
El control no es técnico, es de gestión
Coordinar el desarrollo de una app sin ser técnico es perfectamente posible. Tu poder no está en revisar líneas de código, sino en definir bien qué quieres, elegir a la gente adecuada, mantener una comunicación ordenada y establecer puntos de control donde ves avances reales y decides con criterio de negocio.
En Tangram Consulting trabajamos así con pymes y emprendedores que llegan sin conocimientos técnicos y salen con una app que entienden y controlan: hablando claro, mostrando avances por entregas y explicando cada decisión en lenguaje de negocio. Si estás a punto de encargar tu app y quieres hacerlo con las ideas claras, estaremos encantados de acompañarte desde la primera conversación.