Corto
Agenda y reservas para un barber club, pensadas ante todo para el teléfono.
Descubre las decisiones del proyecto →Definimos y desarrollamos apps para reservas, servicios, compras o procesos operativos, eligiendo las plataformas y las funciones antes de empezar.
Una primera versión útil debe resolver bien un recorrido prioritario. Las cuentas, los pagos, las notificaciones, el backend y la publicación se evalúan por separado y se incluyen en el alcance.
Sede única en Montecatini Terme: Kreluna no tiene oficinas en Pistoia. Las reuniones en el estudio son con cita previa. El análisis, las revisiones y la entrega pueden realizarse online; otras reuniones se acuerdan por separado y no están incluidas automáticamente.
Experiencia móvilPrueba la app CortoAbrir la demoLas demos permiten explorar pantallas y pasos de reserva o compra. No demuestran un backend operativo, notificaciones efectivas, pagos reales ni una publicación en las tiendas de aplicaciones: esas partes requieren un proyecto específico.
Agenda y reservas para un barber club, pensadas ante todo para el teléfono.
Descubre las decisiones del proyecto →
Un recorrido móvil dedicado a tratamientos, disponibilidad y reservas.
Descubre las decisiones del proyecto →
Un concepto de alquiler con búsqueda, selección y uso inmediatos.
Descubre las decisiones del proyecto →Conceptos de demostración diseñados y desarrollados por Kreluna: muestran el enfoque y la calidad, pero no se presentan como trabajos encargados por clientes. Explora todos los proyectos y las decisiones de diseño →
Si técnicos, agentes o empleados trabajan fuera de la oficina, definimos qué datos consultar y registrar desde el móvil. Cobertura de red, permisos y sincronización influyen en la elección entre app y web app.
Las asignaciones, las fotos, las firmas y el estado del trabajo pueden seguir una única secuencia. Evaluamos la cobertura de red, el uso sin conexión y los permisos antes de elegir la plataforma y la tecnología.
Si la app debe leer disponibilidad o enviar solicitudes al sistema de gestión, comprobamos API y accesos antes de estimar la integración. Definimos quién puede corregir datos y qué ocurre ante errores o fallos de sincronización.
Los portales móviles y las web apps pueden recoger solicitudes, documentos y avances sin multiplicar las llamadas y los mensajes. Cada notificación se vincula a un evento útil, no se utiliza como ruido promocional.
Los usuarios, las pantallas y la acción principal se definen antes del código.
El flujo se verifica y después se desarrolla en las plataformas acordadas.
Los dispositivos, las cuentas de las tiendas de apps, la publicación y el mantenimiento se especifican en la oferta.
Partimos de la acción que la app debe facilitar: reservar, comprar, acceder a un servicio o gestionar una tarea.
Las pantallas, las cuentas, los pagos, las notificaciones, el backend y las versiones iOS, Android o web se definen antes del código.
Los dispositivos, las cuentas de las tiendas de apps, los datos, las comprobaciones y las responsabilidades de publicación se indican en la propuesta.
Para el trabajo sobre el terreno, seguimos un ejemplo desde la asignación hasta el cierre: datos obligatorios, fotos o documentos, estado y responsable. Si hace falta trabajar sin conexión, definimos el envío posterior y la gestión de conflictos antes de estimar el desarrollo.
Antes del desarrollo aclaramos quién actualiza la información, la disponibilidad y las notificaciones. Una app sostenible requiere un proceso de gestión además de la interfaz visible para los usuarios.
Compartimos un recorrido de ejemplo con usuario, datos iniciales, acción y resultado esperado, incluido un error o una cancelación. El prototipo aclara los pasos; integraciones y comprobaciones técnicas se evalúan aparte. Decisiones y revisiones quedan documentadas.
Objetivo, destinatarios, materiales y herramientas actuales.
Tareas incluidas, plazos, costes y dependencias externas.
Revisiones acordadas, comprobaciones y entrega.
Depende de las API y los accesos que ofrezca el sistema. La compatibilidad se verifica antes de incluir la conexión en el presupuesto.
Cada proyecto parte de tus necesidades. Definimos juntos objetivos, funciones y plazos, y después preparamos una propuesta a medida.
Sí, cuando ambas plataformas están previstas en el proyecto. El presupuesto aclara siempre qué versiones y dispositivos están incluidos.
No necesariamente. A menudo conviene empezar con una primera versión esencial y comprobar la utilidad del recorrido principal.
Describe quién usará la app, la acción principal y un ejemplo completo, incluidos errores o cancelaciones. Indica dispositivos, datos, sistemas existentes, necesidades sin conexión y cuentas disponibles. La propuesta distingue prototipo, desarrollo, backend, publicación y mantenimiento.
Cuéntanos una acción que la app debe permitir completar y quién la usará. Indica dispositivos, datos y sistemas por conectar: a partir de ahí definimos la primera versión que evaluar.
Escribe a KrelunaKreluna tiene una única sede, en Montecatini Terme. Las reuniones en el estudio son con cita previa. El análisis, las revisiones y la entrega pueden realizarse íntegramente online; cualquier otra reunión se acuerda por separado. Materiales, decisiones y responsabilidades quedan por escrito.
Describimos la acción principal, los usuarios, los datos y las notificaciones imprescindibles. El prototipo, las plataformas, la publicación en las tiendas de apps y la gestión posterior se separan para evitar costes o funciones no previstos.
Las imágenes y el estilo tienen una función precisa: ayudar a las personas a entender la oferta y llegar a la acción importante sin confusión.