Desarrollo de aplicaciones a medida

Qué es el desarrollo de aplicaciones a medida y cuándo compensa

Una aplicación no es una web con un icono en el móvil. Es software: tiene usuarios que entran con su cuenta, roles que deciden quién ve qué, estados que van cambiando a lo largo del día y consecuencias cuando algo sale mal. Una web enseña lo que haces; una aplicación hace que ocurra. Y lo que hace que las cosas ocurran hay que programarlo, probarlo y vigilarlo como tal.

Compensa cuando el proceso ya existe y vive repartido en sitios que no lo aguantan: una hoja de cálculo que solo entiende una persona, un cuaderno en la barra, un grupo de WhatsApp donde se pierden los avisos, tres herramientas que no se hablan entre sí y alguien tecleando el mismo dato dos veces. La aplicación no inventa una forma nueva de trabajar: pone por escrito la tuya y la hace cumplir.

Y no compensa siempre, que es la parte que casi nadie te dice antes de cobrarte. Si lo que necesitas es enseñar tus servicios y que te llamen, eso es una web y te lo diremos. Si lo tuyo lo resuelve una herramienta ya hecha que encaja de verdad, te diremos cuál aunque no la hagamos nosotros. El desarrollo a medida se justifica cuando lo estándar te obliga a cambiar tu forma de trabajar para caber dentro de lo que otro decidió.

La prueba no es un porfolio: es Qomanda, nuestro software funcionando en producción

Lo habitual es hablar de desarrollo de aplicaciones enseñando capturas de proyectos ajenos. Nosotros preferimos enseñarte el nuestro. Qomanda es un software de gestión de reservas para restaurantes que hemos construido en Alture, está desplegado y funcionando en app.qomanda.es, y lo operamos nosotros: cobros, avisos, actualizaciones, incidencias y la vigilancia automática que avisa antes que el cliente.

Son dos aplicaciones sobre el mismo dato. Por dentro, el back-office del personal de sala: la vista del día con la lista del servicio, el plano de la sala en vivo y el cronograma; el editor del plano con sus zonas, mesas y plantas; el CRM del comensal con alérgenos, etiquetas e historial; la analítica; los roles del equipo. Por fuera, un motor de reservas que el restaurante incrusta en su propia web, en doce idiomas con detección automática y con su logo y su color.

Está escrito en Next.js y React sobre TypeScript, con Postgres en Supabase, desplegado en Vercel y con Stripe para los cobros. Se vende a 49 € al mes por restaurante, con el precio publicado y sin comisión por comensal, con treinta días de prueba y sin tarjeta. Nada de eso es una maqueta: son decisiones que hemos tenido que defender delante de un cliente y sostener después en producción, que es donde se ve si estaban bien tomadas.

Y ahora la parte que no suele aparecer en una página de servicios. Qomanda demuestra que sabemos construir y operar un producto de software, no que hayamos ganado un mercado: la tracción se enseña con números de clientes y esos se publican cuando existen, no antes. Lo que traemos hoy es el producto funcionando, el código escrito y las decisiones que hay detrás. Con eso puedes juzgarnos.

Una aplicación no se juzga el día que se entrega: se juzga el día que algo falla. Por eso la prueba que enseñamos es la nuestra, y la operamos nosotros.

La aplicación con la que tus clientes reservan, piden o compran

Es la capa que usa alguien que no trabaja contigo: el que reserva mesa, pide cita, hace un pedido, consulta su expediente o compra. No ha visto tu software nunca, no va a leer instrucciones y lo más probable es que llegue desde el móvil con una mano ocupada. Si duda dos veces, se va. Por eso esta parte se diseña al revés que la interna: menos opciones, menos pasos y ninguna palabra que solo entienda tu equipo.

El motor de Qomanda es exactamente eso. Se incrusta en la web del restaurante y no en un portal ajeno; detecta el idioma del navegador entre doce; adopta el logo, el color y hasta el fondo transparente para que no se note la costura con el resto de la página; deja al restaurante elegir qué campos pide y añadir sus propias preguntas; y confirma, recuerda y agradece por correo sin que nadie tenga que acordarse de hacerlo.

Detrás hay una decisión que va más allá del diseño: quien reserva ahí es cliente del restaurante, no de un intermediario. El nombre, el teléfono y el historial se quedan en su base de datos, y la relación también. Cuando la aplicación con la que compran tus clientes es tuya, dejas de alquilar el acceso a tu propia gente.

El software que opera la maquinaria: planta, sala y almacén

El otro uso es el que no ve nadie desde fuera: el software que mueve tu operación por dentro. Partes de trabajo, órdenes de producción, control de turnos, trazabilidad de lote, mantenimiento preventivo, entradas y salidas de almacén, terminales táctiles en la nave, un código que se lee al pasar. Aquí no manda la estética: manda que alguien con guantes puestos y prisa haga en dos toques lo que hoy hace en un papel que luego alguien teclea.

Y aquí toca ser claros, porque es la regla de la casa: hoy no tenemos una fábrica que enseñarte. Si buscas a quien te presuma de veinte plantas industriales, no somos nosotros y preferimos que lo sepas antes de la reunión. Lo que sí tenemos es la maquinaria completa de un negocio real construida y funcionando, que es el mismo problema con otro decorado.

En Qomanda, además de las reservas, está programado el módulo que opera el servicio: la comanda desde el propio plano de la sala, el terminal táctil a pantalla completa, la pantalla de cocina en tiempo real con alertas por color según lo que tarda cada plato, el escandallo de cada receta con su merma, el descuento de existencias en el mismo momento del cobro, los albaranes de compra con precio medio ponderado, el informe de consumo y desviación y los arqueos de caja. Eso es control de producción, inventario y trazabilidad: cambia «mesa 7» por «línea 2» y el problema es idéntico.

La parte con consecuencias legales se diseñó como documento y no como pantalla: numeración correlativa sin huecos por serie, encadenada con una firma, en una tabla que un disparador impide modificar, y un cierre de caja que congela sus totales para que ninguna venta caiga entre dos cierres. Reimprimir lee lo congelado; nunca se recalcula. Cuando un dato tiene que aguantar una inspección, no basta con que se vea bien.

Ese módulo, por cierto, no está abierto a todas las cuentas de Qomanda: lo habilitamos caso a caso, con un permiso que solo concedemos nosotros. Un terminal de venta no se enciende con un clic y se deja solo, y decirlo nos cuesta ventas y nos ahorra disgustos.

La integridad se resuelve en la base de datos, no en la pantalla

En toda aplicación de verdad llega el momento en que dos personas hacen lo mismo a la vez. Dos comensales pidiendo la última mesa, dos comerciales comprometiendo el mismo stock, dos operarios cerrando el mismo parte. Si comprobar y escribir son dos pasos separados, tarde o temprano los dos pasan por el mismo hueco y nadie se entera hasta que hay alguien de pie esperando.

En Qomanda lo resolvimos donde hay que resolverlo: dentro de la base de datos. Reservar no son dos llamadas seguidas, es una función que toma un cerrojo por restaurante y fecha, comprueba el aforo del turno y la mesa libre y escribe, todo dentro de la misma transacción. Encima hay un disparador que rechaza cualquier solape de mesa aunque la reserva entre por otro camino, y otra función equivalente para reasignar mesas desde el panel.

El criterio es este: la aplicación puede equivocarse —siempre acaba equivocándose— pero la base de datos no la deja. Cuesta más el primer día y es la razón por la que después nadie tiene que explicar por qué se ha sentado dos veces a la misma mesa. Esa es la diferencia entre una demo que funciona en la reunión y un sistema que aguanta el viernes por la noche.

Si tu aplicación cobra, el dinero va a tu cuenta

Cuando una aplicación cobra, la primera pregunta no es qué pasarela usar: es por dónde pasa el dinero. Nosotros tenemos una respuesta fija, y es por la tuya.

En Qomanda, las garantías contra el plantón van por Stripe Connect con cargos directos. Traducido: la cuenta es del restaurante, el cobro cae en su balance y Qomanda no retiene fondos en ningún momento. No es generosidad, es criterio. Ponerte en medio del dinero de otro te convierte en algo que no eres, te mete en un lío contable que no te toca y te obliga a explicar cada retraso de una transferencia que tú no controlas.

El restaurante elige además cómo protege el servicio —guardar la tarjeta, retener un importe o cobrar un depósito— y el sistema hace el resto. El mismo planteamiento vale para cualquier aplicación que cobre: suscripción, pago único, reserva con señal o carrito. Tu cuenta, tu dinero, y la comisión de la pasarela se la pagas a la pasarela, no a nosotros.

Roles, permisos y datos personales: quién ve qué y qué pasa con lo que sobra

Casi toda aplicación de empresa guarda datos de personas, y ahí el descuido se paga muy caro. Lo primero es el aislamiento: en Qomanda cada tabla lleva activado el control de acceso a nivel de fila, de manera que un restaurante no puede ver el dato de otro aunque alguien escriba mal una consulta. No es una comprobación en el código de la aplicación, que es donde suele estar y donde se olvida: está en la base.

Encima van los permisos por persona. Cinco roles con jerarquía —propietario, encargado, sala, camarero y solo lectura— aplicados también en la base de datos y no solo en el menú, invitaciones por correo, y un detalle pequeño que evita un problema grande: un disparador impide dejar la cuenta sin ningún propietario. Cuando entramos a dar soporte, se hace con un aviso visible en pantalla y queda registrado; nadie mira dentro de la casa de un cliente en silencio.

El dato personal caduca, y lo programamos así. Hay una purga que anonimiza al comensal cuando pasa el plazo pero conserva la reserva, la ocupación y la factura: el cliente no pierde ni una estadística y lo que ya no está no se puede filtrar. Va apagada por defecto y la enciende él, porque el plazo lo decide quien responde ante la Agencia de Protección de Datos, no su proveedor.

Los servidores están en Fráncfort y las funciones se ejecutan en esa misma región, junto a la base de datos: el dato no cruza el Atlántico para ir y volver. Y la exportación de reservas, clientes y facturas está deliberadamente fuera del muro de pago. Si alguien deja de pagar se le corta el servicio, no se le secuestran sus datos.

Una aplicación no se mantiene: se opera. Y el silencio no es éxito

Mantener y operar no son lo mismo. Mantener es actualizar y arreglar lo que se rompe. Operar es enterarse antes que el cliente. La mayoría de los desastres de software no avisan con un error rojo: avisan con silencio.

Qomanda tiene siete procesos que se ejecutan solos —recordatorios, cierre del día, encuestas, red de seguridad, salud de la facturación, caducidad del dato y un vigilante—. El vigilante existe por una lección concreta: si uno de esos procesos deja de ejecutarse, por una variable borrada en un despliegue o un cambio de plan, no falla nada visible. Simplemente los recordatorios dejan de salir y el restaurante lo descubre por los plantones. Ahora cada proceso deja su latido y, si alguno se calla, nos avisa a nosotros.

En la misma línea, los errores del servidor nos llegan por correo con su huella y con un tope para que un fallo repetido no nos ahogue, y antes de dar nada por bueno contrastamos lo que dice el repositorio contra lo que está realmente aplicado en la base de datos. Escrito no es desplegado: esa distinción salió de una auditoría propia y nos ahorra ahora la clase de sorpresa que solo se descubre cuando ya es tarde.

Con tu aplicación hacemos exactamente lo mismo. La evolución, la vigilancia y el soporte entran en una minuta mensual: no te entregamos un producto y desaparecemos. Un software sin nadie detrás dura hasta el primer cambio que necesite, y ese cambio siempre llega.

Lo que todavía no funciona se marca «Próximamente», no con un check verde

Hay un detalle de Qomanda que dice más de cómo trabajamos que cualquier lista de tecnologías: cuando un control de la configuración todavía no gobierna ningún comportamiento, no enseña un check verde. Enseña «Próximamente». Existe incluso una pieza del sistema de diseño hecha solo para eso.

Parece menor y no lo es. El interruptor que finge que guarda es la forma más rápida de perder la confianza de un equipo: alguien lo activa, se queda tranquilo y descubre tres semanas más tarde que nunca hizo nada. En Qomanda hay funciones escritas y todavía no conectadas —el contestador de voz, por ejemplo— y el panel lo dice con esas palabras en lugar de aparentar que están listas.

En tu aplicación va a pasar igual: habrá cosas de la primera versión que se queden fuera y funciones que se escriban antes de poder encenderse. Lo vas a saber por nosotros, en el presupuesto y en la propia pantalla, y no por sorpresa el día que lo necesites.

Desarrollo de aplicaciones móviles: nativa, web o PWA, y por qué casi nunca hace falta la tienda

«Quiero una app» casi siempre significa «quiero que mi gente lo lleve en el móvil», y eso no obliga a pasar por ninguna tienda de aplicaciones. Lo primero que decidimos contigo es si tu proyecto necesita de verdad una aplicación nativa, porque la respuesta honesta suele ser que no.

Una aplicación web bien hecha se instala en la pantalla de inicio, abre a pantalla completa, funciona igual en móvil, tablet y ordenador y se actualiza sola para todo el mundo a la vez. No hay revisión de tienda que espere una semana, no hay tres versiones viejas conviviendo con la nueva y no hay que mantener dos programas distintos que hacen lo mismo. Qomanda funciona así, y su terminal táctil se usa en tablet.

Lo nativo compensa cuando el proyecto lo exige de verdad: uso intensivo de cámara o sensores, funcionamiento sin cobertura, notificaciones push fiables en iPhone o presencia en la tienda como canal de venta en sí mismo. Cuesta más, tarda más y hay que pasar por Apple y por Google, así que la decisión se toma con el motivo delante y no con la moda. Lo que no vamos a hacer es venderte una aplicación en la tienda para que tu equipo entre a lo mismo que abriría con un enlace.

Qué aplicaciones desarrollamos a medida

Reservas, citas e inscripciones. Disponibilidad, turnos, aforo, confirmaciones y recordatorios automáticos, con motor propio incrustado en tu web o integrando el que ya utilizas. Es el terreno que mejor conocemos porque es el que hemos tenido que resolver para nosotros mismos, hasta el último caso raro.

Portales de cliente y áreas privadas. Cada usuario entra y ve lo suyo y solo lo suyo: sus pedidos, sus documentos, su expediente, sus facturas. Aquí ya no hablamos de páginas sino de software con cuentas, roles y estados, y se programa, se prueba y se documenta como tal.

Paneles de operación y cuadros de mando. Reunir en una pantalla lo que hoy vive repartido en cinco herramientas y en la cabeza de dos personas, con el dato en vivo y no con un informe de ayer. Sirve para decidir por la mañana en lugar de reconstruir a final de mes.

Terminales táctiles y aplicaciones de campo. Pantallas pensadas para usarse de pie, con prisa y con las manos ocupadas: tomar el pedido, cerrar un parte, registrar una entrada de almacén, leer un código. Poco texto, botones grandes y ninguna decisión que obligue a pararse a pensar.

Integraciones y automatismos entre sistemas. Conectar por API lo que ya usas —ERP, CRM, facturación, pasarela, correo— para que el dato entre una sola vez y viaje solo. Es, con diferencia, lo que más horas al mes le devuelve a un equipo cuando está bien hecho.

Producto propio, cuando el software es el negocio. Aplicaciones multiempresa con suscripción, alta autónoma de clientes, panel interno de administración y facturación: exactamente la arquitectura que hemos construido para Qomanda. Si tu idea es vender el software y no solo usarlo, ese camino ya lo hemos recorrido entero, con sus curvas.

Primeras versiones y rescates. Validar una idea con una versión corta antes de invertir de más, o hacerse cargo de una aplicación que empezó otro y hoy no avanza. Auditamos qué se aprovecha y qué sale a cuenta rehacer, y te lo decimos aunque la respuesta sea incómoda.

Cómo desarrollamos una aplicación a medida, fase a fase

El orden es siempre el mismo: entender el proceso real, modelar el dato y los estados, construir una primera versión corta, ponerla delante de gente que trabaja con ella y operar. Sin fases sorpresa ni partidas que aparecen a mitad de camino.

Empezamos yendo a verlo. Un proceso no se modela desde una videollamada: hay que ver quién toca qué, en qué momento, con qué prisa y qué hace hoy cuando el sistema le estorba. De ahí sale lo que de verdad hay que construir, que casi nunca coincide con lo que se pide en la primera reunión.

Antes de dibujar una pantalla escribimos los estados. En Qomanda una reserva tiene quince: pendiente, confirmada, reconfirmada, en revisión, sin tarjeta, ha llegado, en barra, sentada, postre, cuenta, limpiando, liberada, plantón, cancelada y pasada. Esa lista no salió de una sesión creativa, salió de mirar cómo se trabaja en una sala. Cuando los estados están bien puestos, las pantallas casi se escriben solas; cuando están mal, no hay diseño que lo arregle.

Después lanzamos pronto y en pequeño: una primera versión con lo imprescindible, delante de usuarios reales, y a partir de ahí decisiones tomadas con uso en lugar de con suposiciones. Cuesta mucho menos corregir una versión corta que una grande, y te ahorra meses construyendo funciones que luego no abre nadie. Tú validas cada fase y sabes en todo momento qué se está construyendo y por qué.

Desarrollo de aplicaciones a medida en Granada, Madrid y toda España

Somos un equipo de Granada que trabaja en remoto y se desplaza donde hace falta: llevamos habitualmente proyectos de empresas de Granada, Madrid, Málaga y Almería, además de clientes repartidos por toda España. Un desarrollo se lleva igual de bien en remoto que en persona siempre que haya un interlocutor fijo y reuniones de verdad, y eso lo mantenemos estés donde estés.

La excepción es el arranque: cuando la aplicación gobierna una operación física —una sala, un almacén, una nave— vamos a verla antes de escribir una línea, porque hay detalles que no salen en ninguna reunión y sí en diez minutos mirando. Después, lo que no cambia es quién programa tu aplicación ni a quién llamas cuando algo hace falta: el mismo equipo, sin relevos a mitad de proyecto.