Cómo crear una app para Android en una empresa

Casi toda la información sobre crear una app para Android está escrita para alguien que quiere aprender a programar. Este artículo es para el otro caso: una empresa que necesita una app y quiere entender el proceso antes de contratar a alguien o de asignarlo internamente.

La parte técnica —qué lenguaje, qué framework— es la que menos problemas causa y la que más se discute. Las decisiones que sí determinan si el proyecto sale bien son cuatro, y ninguna es técnica.

Por qué Android primero en México

Si va a empezar por una sola plataforma, en México es Android. Según StatCounter, en agosto de 2026 Android tenía 66% del mercado móvil mexicano contra 34% de iOS.

Vale la pena matizarlo en lugar de tomarlo como regla: dos tercios del mercado es una mayoría clara, pero un tercio en iOS no es residual. La distribución además cambia según a quién va dirigida la app. Si es para su personal operativo —choferes, técnicos, personal de campo—, la proporción de Android suele ser bastante mayor que el promedio nacional. Si es para clientes de segmentos altos, iOS pesa más de lo que sugiere la cifra general.

La forma útil de decidirlo no es el dato de mercado: es contar qué traen en la mano las personas que van a usarla.

Las cuatro decisiones que importan

1. A nombre de quién queda la cuenta de desarrollador

Es la que más caro sale y la que casi nunca se discute al inicio.

Para publicar en Google Play se necesita una cuenta de Google Play Console. Si el proveedor publica la app desde su cuenta, la app es suya en términos prácticos: las reseñas, las métricas, la relación con Google y la capacidad de publicar actualizaciones viven ahí. Cambiar de proveedor después implica migrar o republicar, y republicar significa perder reseñas e historial y obligar a los usuarios a reinstalar.

La cuenta debe estar a nombre de su empresa desde el primer día, con su proveedor como usuario invitado. Es un trámite de una tarde al inicio y un problema serio si se deja para después. La misma lógica aplica al código, que tratamos en de quién es el código del software que le desarrollan.

2. Si de verdad va a la tienda pública

Mucha app empresarial no debería estar en Google Play. Si la van a usar solo sus empleados, hay dos caminos mejores: distribución interna a través de Google Play (canal privado para su organización) o un sistema de gestión de dispositivos que la instale directamente.

Ir a la tienda pública cuando no hace falta agrega revisión de Google, requisitos de política que no aplican a su caso y un ciclo de aprobación en cada actualización. Es fricción sin beneficio.

3. Qué datos toca

Esta decisión define la mitad del trabajo. Una app que solo muestra información es un proyecto pequeño. Una app que escribe en su ERP, consulta inventario en tiempo real o genera un CFDI es otra cosa completamente distinta, y el trabajo pesado no está en la app sino en la integración.

Si su sistema administrativo es CONTPAQi o Aspel corriendo en un servidor local, eso no se conecta solo. Está a fondo en cómo integrar CONTPAQi o Aspel con tu sistema.

4. Si tiene que funcionar sin señal

Es la pregunta que más cambia el presupuesto y la que más se olvida. Una app que asume conexión permanente es sencilla. Una que debe seguir funcionando en una bodega sin cobertura, guardar lo capturado y sincronizar después, requiere resolver conflictos de datos, colas de envío y estados intermedios.

Si su caso es de operación en campo, conviene leer cómo digitalizar operaciones en campo antes de especificar nada.

El proceso, sin adornos

Etapa	Qué pasa	Quién carga el peso
Definición	Qué hace, para quién, con qué se integra	Usted
Diseño	Pantallas y flujos antes de programar	Proveedor, con su revisión
Construcción	Entregas parciales que ya se pueden usar	Proveedor
Pruebas en dispositivos	Probar en los modelos reales de su gente	Ambos
Publicación	Cuenta, políticas, ficha, revisión de Google	Proveedor, cuenta suya
Operación	Errores, actualizaciones, cambios	Depende del contrato

La etapa que más se subestima es la cuarta. Android no es un dispositivo: es cientos de modelos con versiones, tamaños de pantalla y capas del fabricante distintas. Una app que funciona perfecto en el teléfono del desarrollador puede fallar en los equipos que de verdad trae su personal. La forma de evitarlo no es sofisticada — es conseguir tres o cuatro de los modelos que realmente usan y probar ahí antes de publicar.

La etapa que más se omite del contrato es la sexta.

Qué exige Google para publicar

Antes de que la app esté disponible hay requisitos que conviene conocer desde el principio, porque varios dependen de usted y no del programador:

• Cuenta de Google Play Console, con verificación de identidad. Las cuentas de organización requieren verificación adicional de la empresa.
• Política de privacidad publicada en una URL accesible.
• Declaración de seguridad de datos: qué recopila la app, para qué y con quién lo comparte. Debe coincidir con lo que la app hace de verdad.
• Nivel de API objetivo reciente. Google exige que las apps apunten a una versión de Android relativamente actual para seguir disponibles.
• Ficha de tienda: ícono, capturas, descripción, clasificación de contenido.

Los requisitos de Google cambian con regularidad, así que verifique la documentación vigente de Play Console antes de planear fechas con base en esta lista.

El costo anual que nadie presupuesta

Aquí está el punto que hace que tantos proyectos de app se sientan como un fracaso dos años después.

Una app para Android no es un gasto único. Google sube periódicamente el nivel de API mínimo que debe declarar una app para seguir disponible para nuevos usuarios. Cuando su app deja de cumplirlo, no se borra del teléfono de quien ya la tiene — deja de aparecer para quien la busca. Silenciosamente.

Eso significa que cada año hay trabajo obligatorio aunque nadie pida una sola función nueva: actualizar el nivel objetivo, actualizar librerías, volver a probar y volver a publicar. A eso se suman los cambios que sí pide el negocio y los ajustes cuando algo del otro lado cambia.

Si el proyecto se cotizó como una obra con fecha de entrega y no como un sistema que hay que mantener, ese trabajo no tiene presupuesto ni responsable. La app sigue instalada, cada vez más vieja, hasta que un día alguien nota que ya no aparece en la tienda.

La conversación honesta con cualquier proveedor es: ¿quién hace esto el año que entra y cuánto cuesta?

¿Y si no necesita una app nativa?

Vale la pena preguntarlo antes de arrancar. Si lo que necesita es que su gente abra algo desde el teléfono, capture información y la mande, quizá una aplicación web bien hecha resuelve igual y se salta tiendas, revisiones y ciclos de publicación.

La comparación completa está en PWA vs app nativa. La regla corta: si necesita cámara intensiva, funcionamiento prolongado sin señal, notificaciones push confiables o estar en la tienda por razones comerciales, vaya nativo. Si no, considere la web primero.

Y si el presupuesto es la duda principal, los rangos del mercado mexicano están en cuánto cuesta desarrollar una app en México.

Cómo lo hacemos en Newsoft

Las primeras preguntas que hacemos no son sobre la app: son con qué sistemas tiene que hablar, qué pasa si se cae, y quiénes exactamente la van a usar y con qué teléfonos.

La cuenta de Google Play queda a nombre del cliente desde el inicio, no al final. El código también. Lo decimos aquí porque es la parte que más veces nos toca corregir en apps que alguien más construyó.

Sobre el mantenimiento somos explícitos antes de firmar, no después: hay trabajo anual obligatorio que no depende de que alguien pida algo, y tiene que tener dueño en el contrato. Nuestro modelo de células de desarrollo existe justamente para esa etapa, que es la larga.

Si está evaluando una app para su operación, platiquemos. En media hora se puede saber si necesita una app, una web, o solo integrar dos cosas que ya tiene.

En resumen

Las decisiones que determinan el resultado son a nombre de quién queda la cuenta de desarrollador, si de verdad necesita estar en la tienda pública, qué datos toca la app y si debe funcionar sin señal. Ninguna es técnica y las cuatro se deciden antes de escribir código.

Android es la plataforma por donde empezar en México —66% del mercado según StatCounter—, pero la cifra que importa es qué traen en la mano las personas que la van a usar.

Y lo más importante: presupueste el año siguiente. Google obliga a actualizar aunque usted no quiera cambiar nada.