Cómo elegir una empresa de desarrollo de apps: preguntas que debes hacer

La mayoría de los proyectos de apps que fracasan no fallan por el código. Fallan porque el fundador contrató al equipo equivocado: un freelancer para un proyecto que necesitaba un equipo completo, una agencia que le pasó el trabajo a otros o una oferta barata que ignoraba la mitad del alcance. Esta guía explica cómo distinguir las opciones, qué preguntar en la primera llamada y qué tiene que estar en el contrato antes de pagar un solo dólar.

Dirijo Loha.dev, un pequeño estudio de apps en Albuquerque, así que tengo un interés en el tema. Aun así, intentaré ser justo, incluso sobre los casos en que un estudio como el mío no es la opción correcta.

¿Freelancer, agencia, estudio, offshore o equipo interno?

Antes de comparar empresas, decide qué tipo de equipo encaja con tu proyecto. Las tarifas por hora de la tabla son rangos típicos aproximados para 2026 en el mercado de EE. UU. y varían mucho según la región y la experiencia.

Una regla práctica: si no tienes un cofundador técnico y vas a construir una primera versión, necesitas un solo equipo responsable que cubra producto, diseño, móvil, backend y publicación. Por lo general, eso es un estudio pequeño o un freelancer sólido con socios de confianza. Contratar personal interno tiene más sentido cuando el producto ya tiene usuarios y una hoja de ruta que mantendrá ocupado a un ingeniero de tiempo completo durante años.

Antes de contratar a alguien, pregúntate también si de verdad necesitas software a la medida. A veces una herramienta no-code o un SaaS existente te lleva al 80 % del camino por una fracción del costo. Escribí sobre esa decisión en app a la medida vs. software comercial.

Señales de alerta a las que debes prestar atención

• Un precio cerrado después de una sola llamada. Nadie puede cotizar una app con responsabilidad a partir de una conversación de 30 minutos. Una cifra tan rápida está inflada o le falta alcance.
• Ninguna app que puedas descargar. Los mockups y las capturas de Dribbble no son software publicado. Pide enlaces de App Store y Google Play.
• Están de acuerdo con todo. Un buen equipo cuestiona las funciones que no aportan a la primera versión. Un equipo que nunca dice que no está optimizando para cerrar la venta.
• Respuestas vagas sobre quién lo construye. Si quien vende no es quien construye, averigua quién lo hará y desde dónde.
• El código solo vive en sus cuentas. Que el proveedor controle el repositorio, el hosting, el dominio y las fichas de las tiendas es la forma en que muchos fundadores terminan secuestrados.
• Un pago por adelantado del proyecto completo. Un anticipo es normal. Pagar el 100 % antes de empezar te quita todo el poder de negociación.
• Ni una palabra sobre pruebas, analítica o soporte posterior al lanzamiento. El lanzamiento es el comienzo del trabajo, no el final.

Señales positivas que anticipan un buen proyecto

• Preguntan por tus usuarios, tu modelo de negocio y cómo vas a medir el éxito antes de hablar de tecnología.
• Proponen recortar el alcance y explican por qué, con una primera versión más pequeña y concreta.
• Te dan un rango con los supuestos por escrito, no una cifra única.
• Muestran versiones funcionales cada una o dos semanas, en dispositivos reales, no en presentaciones.
• Configuran el repositorio y las cuentas de Apple y Google a nombre de tu empresa desde el primer día.
• Pueden explicar sus decisiones técnicas en lenguaje sencillo, incluidas las desventajas.
• Son claros sobre lo que no hacen bien y a quién te recomendarían.

Las preguntas que debes hacerle a una empresa de desarrollo de apps

Úsalas en la primera o segunda llamada. No hace falta hacerlas todas; lo importante es escuchar cómo responden. La honestidad específica, aunque sea un poco incómoda, es buena señal. Las generalidades pulidas, no.

Portafolio y apps publicadas

• ¿Qué apps han publicado que estén disponibles en las tiendas ahora mismo? ¿Puedo descargarlas?
• ¿Qué construyó exactamente su equipo en cada una: diseño, móvil, backend, todo?
• ¿Qué proyecto se parece más al mío y qué salió mal en él?
• ¿Puedo hablar con un cliente anterior? (Si dicen que sí, llama de verdad).

Descarga las apps y úsalas diez minutos. Revisa el onboarding, los estados de carga, qué pasa sin conexión y las reseñas en la tienda. Aprenderás más de eso que de cualquier página de casos de éxito.

Proceso y comunicación

• ¿Cada cuánto veré software funcionando y en qué dispositivos?
• ¿Quién es mi contacto del día a día y es una persona técnica?
• ¿Cómo manejan una solicitud de función a mitad de un sprint?
• ¿Qué necesitan de mí cada semana y cuánto de mi tiempo exige esto?

Si quieres saber cómo se ve un proceso sano, fase por fase, consulta el proceso de desarrollo de apps explicado.

Decisiones técnicas y propiedad

• ¿Qué stack recomiendan para esta app y qué los haría elegir otro?
• ¿Nativo (Swift/Kotlin) o multiplataforma (React Native, Flutter)? ¿Por qué en mi caso?
• ¿Quién es dueño del código, los diseños y la propiedad intelectual al terminar el proyecto? ¿Cuándo se transfiere?
• ¿El repositorio, el hosting en la nube, el dominio y las cuentas de desarrollador de Apple y Google estarán a nombre de mi empresa?
• Si dejamos de trabajar juntos, ¿cómo podría tomar el relevo otro desarrollador? ¿Hay documentación?

Modelo de precios: precio cerrado vs. tiempo y materiales

• ¿Trabajan con precio cerrado, por tiempo y materiales o con un modelo híbrido?
• ¿Qué incluye la estimación y qué queda excluido explícitamente?
• ¿Cómo se cotizan y aprueban las solicitudes de cambio?
• ¿Cuáles son los hitos de pago y qué entrega cada uno?

El precio cerrado funciona cuando el alcance es pequeño y estable. También suele incluir un margen de riesgo, y cada cambio se convierte en una negociación. Tiempo y materiales es más honesto para productos que van a evolucionar, pero necesita un tope de presupuesto y visibilidad semanal de las horas. Un punto medio común es una fase de descubrimiento con precio cerrado seguida de sprints con tope. Para cifras realistas, mira cuánto cuesta desarrollar una app.

Control de calidad

• ¿Quién prueba la app y en qué dispositivos reales y versiones del sistema operativo?
• ¿Escriben pruebas automatizadas? ¿Para qué partes?
• ¿Cómo monitorean los cierres inesperados y errores después del lanzamiento?
• ¿Cuál es su proceso cuando App Store o Google Play rechazan una versión?

Soporte después del lanzamiento

• ¿Qué pasa en los primeros 30 días después del lanzamiento? ¿Está incluida la corrección de errores?
• ¿Cuánto cuesta, más o menos, el mantenimiento mensual?
• ¿Quién se encarga de las actualizaciones del sistema operativo, los SDK obsoletos y los cambios de políticas de las tiendas?
• ¿Cuál es su tiempo de respuesta si la app se cae?

Quién escribe realmente el código

• ¿Quiénes son, por nombre, los desarrolladores de mi proyecto y qué experiencia tienen?
• ¿Son empleados, contratistas o una empresa subcontratada?
• ¿El equipo será el mismo durante todo el proyecto?
• ¿Puedo conocer al desarrollador principal antes de firmar?

Cómo evaluar y comparar propuestas

Cuando tengas dos o tres propuestas, ponlas lado a lado. Es común que los precios varíen hasta 3 veces, y eso suele significar que cada proveedor entendió un proyecto distinto.

1. Revisa primero el alcance y después el precio. Haz una lista de las funciones que incluye cada propuesta. Los elementos que faltan, como panel de administración, notificaciones push, pagos o analítica, explican la mayoría de las ofertas bajas.
2. Busca los supuestos declarados. Las buenas propuestas dicen qué supusieron: cantidad de roles de usuario, integraciones, plataformas, si incluye diseño o no.
3. Compara la primera versión, no el sueño. La mejor propuesta suele decir qué dejar fuera de la v1.
4. Lee el cronograma con realismo. Una app completa para iOS, Android y backend en cuatro semanas es una señal de alerta. Consulta cuánto tiempo se tarda en desarrollar una app para ver rangos típicos.
5. Cuenta quiénes participan. ¿El plan incluye diseño, QA y un líder de proyecto, o solo desarrolladores?
6. Pregunta cuánto cuesta después del lanzamiento. Hosting, servicios de terceros, tarifas de las tiendas y mantenimiento forman parte del costo total.

Lo esencial del contrato: protege tu código, tu PI y tus cuentas

Tu contrato debe estar redactado de modo que, si la relación termina mañana, puedas entregarle todo a un equipo nuevo al día siguiente. Como mínimo, debe cubrir:

• Cesión de propiedad intelectual. Todo el código, los diseños y la documentación creados para ti se ceden a tu empresa, normalmente al pagar cada hito. El lenguaje de "obra por encargo" (work for hire) por sí solo puede no ser suficiente; una cláusula de cesión explícita es más segura. Pide a un abogado que lo revise.
• Acceso al código fuente. Tienes acceso al repositorio Git desde el primer día, no un archivo zip al final.
• Cuentas de las tiendas a TU nombre. Inscribe a tu propia empresa en el Apple Developer Program (USD 99 al año; las organizaciones necesitan un número D-U-N-S) y en Google Play Console (pago único de USD 25). Agrega al desarrollador como miembro del equipo. Transferir una app entre cuentas más adelante es posible, pero lento y engorroso.
• Infraestructura a tu nombre. El hosting en la nube, la base de datos, el dominio, el envío de correos, la analítica y las claves de API deben estar en cuentas que tú controlas y pagas, con el desarrollador como invitado.
• Componentes de terceros y de código abierto. El proveedor debe informar qué bibliotecas o recursos con licencia tienen restricciones.
• Confidencialidad y no captación de personal adaptadas a tu situación, sin impedir que el desarrollador construya otras apps.
• Hitos de pago ligados a entregables que puedas verificar, como una versión en TestFlight o el envío a la tienda.
• Garantía y condiciones de soporte: durante cuánto tiempo se corrigen errores gratis después del lanzamiento y cuál es la tarifa después.
• Condiciones de terminación: qué recibes y qué debes si cualquiera de las partes termina el contrato antes de tiempo.

Esto no es asesoría legal. Pide a un abogado que revise cualquier contrato de desarrollo antes de firmarlo, sobre todo la sección de propiedad intelectual.

¿Desarrollador local o remoto?

Hoy el trabajo remoto es normal, y la mayoría de los proyectos funcionan bien con videollamadas y un canal compartido de Slack. Aun así, un equipo en tu zona horaria toma decisiones diarias más rápido, y poder reunirse en persona ayuda en proyectos complejos o regulados. Si estás en Nuevo México, ofrecemos desarrollo de apps en Albuquerque con talleres presenciales; si no, da prioridad a las horas de trabajo compartidas por encima de la geografía.

Cómo lo hacemos en Loha.dev

Como también nos harás estas preguntas a nosotros, aquí van nuestras respuestas. Somos un estudio pequeño y yo escribo código en cada proyecto. Construimos apps a la medida para iOS, Android y web, principalmente con React Native y Expo, TypeScript, Convex para backends en tiempo real y Cloudflare. Los clientes son dueños de su repositorio, sus cuentas de las tiendas y su infraestructura desde el inicio. Entregamos versiones funcionales con frecuencia y avisamos pronto cuando una función todavía no vale la pena.

También operamos nuestros propios productos, como Star, una app de setlists y presentaciones, así que lidiamos nosotros mismos con las revisiones de las tiendas, las actualizaciones del sistema operativo y el soporte a usuarios. Si estás comparando equipos de desarrollo de apps móviles, puedes obtener un plan gratuito para tu app y usarlo para comparar otras propuestas, nos contrates o no.