Desarrollo de aplicaciones móviles
iOS y Android, para tus clientes o para tu equipo. Lo que decide si una app sirve no es la pantalla: es si lee y escribe sobre los datos que tu empresa ya tiene, sin que nadie los cargue dos veces.
Cuándo aparece la pregunta
Cada pedido entra por un mensaje, alguien lo copia a una planilla y el estado real depende de a quién le preguntes. No es un problema de orden: es que nadie tiene el dato en el momento en que lo necesita.
Quieren pedir, reservar o ver en qué estado está lo suyo sin llamar y esperar respuesta. Hoy esa consulta la contesta una persona, en horario de oficina.
Sirve para que te encuentren y te consulten. Cuando la misma persona vuelve cada semana a repetir la misma tarea, el navegador pasa a ser el camino largo: buscar la página, iniciar sesión otra vez, y enterarse de un cambio sólo si entra a mirar.
Qué construimos
Pedir, reservar, seguir un envío, ver el historial y pagar donde corresponda. Lo que hoy resuelve una persona por mensaje, disponible a las once de la noche de un domingo.
Para quien trabaja lejos del escritorio: la carga ocurre donde ocurre el trabajo, con la foto y la firma adjuntas ahí mismo, y lo hecho no se pierde cuando el depósito o la ruta se quedan sin señal.
Cuentas de desarrollador, ficha, capturas, política de privacidad, firma y el ida y vuelta con la revisión de Apple, que rechaza por motivos que no siempre son obvios. Después, cada actualización vuelve a pasar por ahí.
La app no inventa una base de datos paralela: consulta la tuya. Si tu sistema no expone una API, la escribimos nosotros. Es el mismo trabajo que hay detrás de los sitios que publicamos.
Cómo trabajamos
Un día real de operación: quién carga qué, dónde se traba, qué se resuelve por mensaje y qué papel sigue dando vueltas. Sin esto, la app termina siendo una versión digital del desorden.
La lista de funciones siempre entra completa en una reunión y nunca entra completa en la primera versión. Elegimos las pocas que justifican que alguien se baje la app, y dejamos el resto anotado para después.
Cada entrega se prueba en teléfonos reales, con la persona que la va a usar y con datos de tu operación. Es incómodo, y es donde aparece todo lo que ninguna reunión anticipó.
Salida a las tiendas, medición de qué se usa y qué no, y correcciones con esa señal. Una app sin mantenimiento no se rompe de golpe: Apple y Google actualizan sus requisitos, y un día una actualización deja de aceptarse.
Preguntas frecuentes
En la mayoría de los casos escribimos una sola base de código y de ahí salen las dos apps: hay menos que mantener y las dos versiones no se van separando entre sí. Vamos a nativo cuando la app depende de algo que el sistema operativo sólo entrega ahí: trabajo sostenido en segundo plano, integración con un equipo o un lector específico, o una exigencia de rendimiento que medimos antes de decidir. Nativo significa dos códigos, y dos códigos cuestan el doble de mantener. Es una decisión que se toma con el caso sobre la mesa, no por preferencia.
Depende de cuatro cosas, y en este orden: cuántas pantallas toman una decisión de negocio, si hay que construir la API que hoy no existe, si la app maneja pagos o datos sensibles, y si tiene que funcionar sin señal. Una app para consultar un estado y una app que reemplaza el proceso de facturación no comparten presupuesto ni conversación. El número llega después del primer paso —entender la operación—, no en el primer mensaje. Y hay costos que no son nuestros: las cuentas de desarrollador de cada tienda y la infraestructura donde corre el backend.
Sí, y normalmente salen de la misma base de código. Publicar en las dos tiendas al mismo tiempo no duplica el desarrollo, pero sí duplica el trabajo de tienda: dos fichas, dos revisiones, dos ciclos de actualización. Si la app es para tu equipo y los teléfonos los da la empresa, a veces alcanza con una sola plataforma, y conviene decirlo desde el principio.
Casi siempre sí, y la pregunta real es por dónde. Si tu sistema expone una API, la app la consume. Si no la expone pero podemos llegar a los datos, escribimos la capa intermedia. Si es un producto de terceros cerrado, sin API ni forma de integrarlo, no hay magia: te lo decimos antes de empezar y decidimos ahí qué hacer, en vez de descubrirlo a mitad del proyecto.
El trabajo lo hacemos nosotros: cuentas, ficha, capturas, política de privacidad, firma y envío a revisión. Las cuentas de desarrollador, en cambio, quedan a nombre de tu empresa. Es más trámite al principio y es la única forma de que la app y sus usuarios queden de tu lado si algún día dejamos de trabajar juntos. Si la app es sólo para tu equipo, las dos plataformas permiten distribución interna sin ficha pública.
En las primeras semanas aparece lo que ninguna prueba anticipó, porque el uso real arma combinaciones que nadie planeó: ahí la corrección es rápida. Después el trabajo cambia de naturaleza: seguir los requisitos de Apple y Google, mirar qué funciones se usan y cuáles no, y decidir qué se construye con esa información. Se puede acordar un acompañamiento mensual o trabajar por cambios puntuales; lo que no recomendamos es publicar y no volver a mirar.
Contanos cómo trabaja tu equipo hoy y qué te están pidiendo tus clientes. Si eso se resuelve mejor arreglando la web o el sistema que ya tenés, te lo vamos a decir antes de que gastes en una app.
Contar cómo trabaja mi equipoServicios relacionados