Cómo subcontratar el desarrollo de una app sin salir escaldado

El manual operativo del founder no técnico para llevar un desarrollo subcontratado de modo que la app se entregue, funcione y sea tuya al final.

Una founder que conocemos le pagó 60.000 dólares a una agencia bien valorada para construir una app de marketplace. Nueve meses después tenía una demo que funcionaba en el celular del dueño de la agencia y en ningún otro lugar, un código que nadie fuera de esa casa podía abrir y una factura por “alcance adicional”. Cuando pidió el código fuente, descubrió que el contrato decía que la agencia era dueña de él hasta el pago final, y el pago final dependía de un lanzamiento que se posponía una y otra vez. Había subcontratado el desarrollo y, sin querer, subcontratado el control del único producto de su empresa.

Ese es el riesgo real, y no es el que te advierten los resultados de búsqueda.

Subcontratar el desarrollo de una app es contratar a un equipo externo para diseñar y construir tu software en lugar de emplear ingenieros tú mismo. Bien hecho, es la vía más rápida para que un founder no técnico ponga un producto real en el mercado sin convertirse en gestor de tecnología. Mal hecho, produce exactamente el naufragio de arriba. La diferencia casi nunca está en la calidad de los desarrolladores. Está en si conservaste el control en los cinco puntos donde los founders lo regalan sin darse cuenta. Este es el manual para conservarlo.

Si todavía estás decidiendo si subcontratar o no, empieza por nuestro análisis sobre montar equipo interno frente a subcontratar. Este artículo asume que ya tomaste esa decisión y ahora tienes que ejecutarla.

Primero, sabe qué estás comprando en realidad

“Subcontratación” es una sola palabra para cuatro arreglos muy distintos, y las historias de fracaso suelen empezar con el founder comprando el equivocado.

El primero es el freelancer: una persona, por hora o por proyecto, barato, rápido y un único punto de fallo. El segundo es el staff augmentation, en el que alquilas a uno o más desarrolladores que trabajan bajo tu dirección pero siguen en la nómina de otra empresa. Escribimos un texto entero sobre cómo funciona el staff augmentation en la práctica; en resumen, te da las manos pero espera que tú pongas la cabeza. El tercero es el proyecto de alcance cerrado, en el que un estudio cotiza un precio para entregar algo definido. El cuarto es el equipo dedicado, un escuadrón continuo que funciona como tu departamento de ingeniería sin ser tu empleado.

Para una primera app con un founder no técnico, el proyecto de alcance cerrado y el equipo dedicado suelen ser los formatos correctos. Los freelancers se rompen en cuanto una persona desaparece, y el staff augmentation solo funciona cuando alguien de tu lado puede de verdad dirigir ingenieros. Elige el arreglo que encaja con cuánto criterio técnico puedes aportar, no el del precio más bajo en la etiqueta. Dónde se ubica ese equipo geográficamente, en tu país, cerca o al otro lado del mundo, es una decisión aparte, con sus propios trade-offs.

Fase 1: cierra el alcance antes de salir a cotizar

El mayor error de los founders es llamar a las agencias primero y escribir el alcance después. Acabas dejando que quienes van a pujar por el trabajo definan el trabajo. Claro que el alcance crece.

Antes de hablar con nadie, escribe tres cosas en lenguaje claro. Qué tiene que hacer la app para su primer usuario real. Qué explícitamente no va a hacer en la versión uno. Y cómo sabrás que funcionó. No necesitas una especificación técnica. Necesitas una descripción lo bastante clara como para que dos proveedores distintos coticen más o menos lo mismo. Cuando las cotizaciones vuelven muy distintas, la brecha mide la ambigüedad de tu alcance, no la diferencia de talento entre ellos.

Ese documento también es tu defensa contra la frase más cara del software, “alcance adicional”. Un cambio solo es adicional si no estaba en la descripción original. Si la descripción vive en tu cabeza, toda discrepancia se resuelve a favor del proveedor. Si vive en papel, tienes una referencia que ambas partes aceptaron.

Un estudio de McKinsey con Oxford sobre grandes proyectos de TI encontró que se pasan, en promedio, alrededor del 45 por ciento del presupuesto, y los sobrecostes vienen más de objetivos poco claros y requisitos que cambian que de código malo. No vas a ganarle a ese riesgo con ingeniería. Lo gestionas decidiendo qué vas a construir antes de pagarle a alguien para construirlo.

Señal de alarma: el proveedor que da un precio y un plazo cerrados antes de hacer una sola pregunta difícil sobre tus usuarios. O está adivinando, o planea facturar la diferencia.

Fase 2: elige sin que te vendan

Cada guía de “cómo subcontratar” que rankea para esta búsqueda la escribió una empresa que quiere ser la respuesta. Léelas por lo que revelan, y luego evalúa a los proveedores por cosas que su marketing no puede fingir.

Pide hablar con los ingenieros que de verdad trabajarían en tu build, no con el vendedor ni con un líder de aire sénior al que pasean en el pitch y desaparece tras la firma. Pide una referencia de un proyecto que fracasó o se torció, y escucha cómo describen lo que salió mal. Un equipo que narra un fracaso con honestidad ya ajustó cuentas con su propio trabajo. Un equipo con solo casos triunfales o es nuevo o está editando.

Pregunta cómo hacen el handoff del código, por escrito, antes de firmar. ¿Dónde vive el repositorio? ¿Quién es dueño de las cuentas? ¿Qué le pasa a tu proyecto si dejas de trabajar con ellos el mes que viene? Un buen socio responde de inmediato porque ya se lo han preguntado. El socio equivocado trata la pregunta como señal de desconfianza, lo que te dice todo.

Señal de alarma: el precio muy por debajo de los demás. El desarrollo de apps tiene un piso real de horas calificadas. Una cotización muy por debajo del grupo es una cotización por algo distinto, más pequeño o más frágil de lo que crees estar comprando, y la diferencia aparece como “alcance adicional” más adelante.

Fase 3: estructura el trato para que el control se quede contigo

Esta es la fase que salvó o hundió a cada founder de nuestra historia inicial, y se reduce a tres cláusulas que la mayoría lee por encima.

Propiedad intelectual. El contrato debe decir que tú eres dueño de todo el trabajo producido, código fuente incluido, en el momento de su creación, no en el pago final. El código por encargo no es automáticamente tuyo: en la mayoría de las jurisdicciones, sin una cesión por escrito, quienes escribieron el código conservan derechos sobre él (la ley de derechos de autor de EE. UU. es explícita en esto). Es una corrección de un párrafo y la frase más importante del acuerdo. Profundizamos en el documento entero en nuestra guía sobre el contrato de desarrollo de software.

Pago atado a hitos que funcionan, no al calendario. Paga por progreso demostrable y desplegado: una pantalla de login que de verdad inicia sesión, un checkout que de verdad cobra. Nunca pagues un saldo grande al final, y nunca dejes que el pago se adelante a la entrega por más de un hito. El dinero es tu único control. Gástalo de último.

Acceso desde el día uno. Debes ser dueño del repositorio, de las cuentas en la nube, del dominio y de las fichas en las tiendas de apps desde el primer commit, con el proveedor trabajando dentro de tus cuentas. Si esos activos están a nombre del proveedor, no tienes un producto. Tienes un rehén.

Señal de alarma: cualquier versión de “te transferimos todo al final”. Todo debe ser tuyo desde el principio. El handoff debería ser un no-evento porque nada salió nunca de tu custodia.

Fase 4: dirige el build aunque no sepas leer código

Los founders asumen que no ser técnico significa no poder gestionar el trabajo. Es al revés. Las cosas que hunden los builds subcontratados son visibles para cualquiera que preste atención, y ninguna exige leer una línea de código.

Exige software funcionando cada una o dos semanas, corriendo en un dispositivo real, no un slideshow de progreso. El software que existe se puede clicar. El software descrito en un reporte de estado puede ser cualquier cosa. Si pasan tres semanas sin nada que puedas abrir y tocar, esa es la advertencia, por bien que suene el reporte.

Mantén a una persona nombrada de su lado responsable de la entrega, y a un tomador de decisiones del tuyo que responda en menos de un día. La mayoría de los builds subcontratados no fracasan por mala ingeniería. Se estancan porque una pregunta pasó una semana en la bandeja del founder y el equipo construyó alrededor del silencio. La respuesta lenta es un costo oculto que pagas en alcance.

Vigila una deriva específica: el build que sigue sumando funciones que ningún usuario pidió. Eso es feature creep, y un equipo subcontratado tiene un incentivo silencioso a su favor, porque más funciones significan más horas facturables. Tu documento de alcance es la cura. Cualquier cosa fuera de él es una conversación, no un valor por defecto.

Fase 5: sé dueño del activo en el handoff

La relación termina de una de dos formas. O se montó para que el handoff sea nada, o descubres en el peor momento que no puedes vivir sin las personas que se van.

Antes del pago final, confirma que puedes entregar el proyecto a un equipo distinto y que este puede operarlo. Eso significa que el código está en tu repositorio, las cuentas están a tu nombre, hay un documento escrito sobre cómo desplegar y operar la cosa, y alguien que no sea el autor original ya lo abrió y lo entendió. Si solo una persona en el mundo puede mantener tu app con vida, no terminaste de subcontratar. Solo cambiaste de quién dependes.

Un handoff limpio también es la prueba honesta de si el trabajo fue bueno. El software hecho para entregarse se hace con claridad, porque el equipo sabía que otra persona lo iba a leer. El software hecho para mantenerte cautivo se hace para mantenerte cautivo. Sentirás la diferencia la primera vez que intentes irte.

Cuánto cuesta, con honestidad

Los founders buscan un número y no existe uno. Una app simple de un equipo competente suele quedar en las decenas de miles de dólares; un producto complejo, de varios lados, con pagos y funciones en tiempo real, llega a las seis cifras bajas. Los rangos honestos, y qué los mueve, están en nuestro análisis sobre cuánto cuesta desarrollar una app.

El encuadre más útil: barato y quemado sale más caro que justo y terminado. El marketplace de 60.000 dólares que no produjo nada costó mucho más que un build de 90.000 que sí salió, porque el primero también costó nueve meses, la ventana de financiación que esos meses contenían, y la reconstrucción. Pon precio al resultado completo, no a la factura.

La prueba real

Quita las fases y una pregunta lo decide: en cada paso, ¿con quién está el control? Si la respuesta es siempre “conmigo, por diseño”, porque cerraste el alcance primero, pagaste por prueba, fuiste dueño de los activos desde el día uno y construiste hacia una salida limpia, entonces subcontratar el desarrollo de la app es la jugada más inteligente que puede hacer un founder no técnico. Si el control se desliza hacia el proveedor, ningún talento de su lado te salva, porque sus incentivos y los tuyos se separaron en silencio.

No necesitas aprender a programar. Necesitas negarte a regalar el control de la única cosa sobre la que funciona tu empresa. Eso es una decisión, y es enteramente tuya.

Preguntas frecuentes

¿Cuánto cuesta subcontratar el desarrollo de una app?

Una app sencilla de un equipo calificado suele caer en las decenas de miles de dólares. Un producto complejo, con pagos, varios tipos de usuario o funciones en tiempo real, puede llegar a seis cifras. La variable es el alcance, no la tarifa por hora, y por eso un documento de alcance ajustado es el control de costos más barato que tienes. Mira nuestro análisis de costos completo para los rangos y qué los mueve.

¿Cuánto cuesta pagarle a alguien para que desarrolle una app?

Las mismas fuerzas aplican, sea ese “alguien” un freelancer, un estudio o un equipo dedicado. Un freelancer solo cotiza el número más bajo y carga el mayor riesgo de punto único de fallo. Un estudio o equipo dedicado cuesta más y absorbe ese riesgo. Compara el resultado y la propiedad en total, no el precio de etiqueta.

¿Cuáles son los cuatro tipos de subcontratación?

Para desarrollo de apps, los cuatro prácticos son: el freelancer (una persona, lo más barato, lo más arriesgado), el staff augmentation (desarrolladores alquilados que tú diriges), el proyecto de alcance cerrado (un estudio entrega algo definido por un precio acordado) y el equipo dedicado (un escuadrón continuo que funciona como tu departamento de ingeniería). La mayoría de los primeros builds encajan en el proyecto de alcance cerrado o el equipo dedicado.

¿Es seguro subcontratar el desarrollo de una app?

Sí, cuando el contrato te da el código fuente y las cuentas desde el día uno, el pago sigue hitos que funcionan, y el build se monta para un handoff limpio. El peligro nunca es solo el lugar o el equipo. Es un trato estructurado para que el control se quede con el proveedor. Estructúralo para que se quede contigo.

¿Es legal subcontratar el desarrollo de apps?

Sí. Contratar a un equipo externo, local o internacional, para construir tu software es estándar y legal. El único punto legal que te importa es la propiedad intelectual: consigue una cesión por escrito de todo el trabajo producido para que el código sea, sin ambigüedad, tuyo.