Corto
Agenda y reservas para un barber club, pensadas ante todo para el teléfono.
Descubre las decisiones del proyecto →Si tu actividad en Roma gestiona reservas y cancelaciones, definimos quién confirma plazas, cuándo caducan solicitudes y cómo funciona una posible lista de espera. Recordatorios y pagos se incorporan solo con reglas operativas claras.
Evaluamos una web app accesible desde enlace o QR si el uso es ocasional y no requiere funciones específicas del dispositivo. Idiomas, accesibilidad y conectividad se consideran junto con la distribución en tiendas de aplicaciones.
Sede única en Montecatini Terme: Kreluna no tiene oficinas en Roma. 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 →
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.
Definimos cuándo enviar confirmaciones y recordatorios, hasta cuándo se puede cancelar y quién reasigna la plaza. También se prevé cómo consultar la reserva si una notificación no llega.
Un QR puede abrir el servicio en el navegador sin instalación. Comprobamos qué acciones deben funcionar en los dispositivos previstos y cuáles necesitan conexión, acceso o funciones nativas.
Los idiomas y pagos dependen del servicio. Si se prevén anticipos, definimos importes, estados del pago y gestión de cancelaciones y reembolsos con los responsables de la actividad y el proveedor elegido.
Para servicios, despachos y negocios con muchos usuarios, partimos de la acción recurrente: reservar, consultar un estado, enviar una solicitud o completar una tarea. La primera versión debe hacerla más sencilla que el recorrido actual.
Definimos qué datos son necesarios, quién los gestiona y cuándo una notificación es realmente útil. Tiendas de apps, servidores, pagos y servicios externos figuran como partidas explícitas en el presupuesto.
El prototipo se revisa con usuarios y responsables de solicitudes usando ejemplos de confirmación, cambio y cancelación. Sirve para revisar el recorrido; carga, sincronización y notificaciones requieren comprobaciones técnicas sobre el sistema desarrollado.
Objetivo, destinatarios, materiales y herramientas actuales.
Tareas incluidas, plazos, costes y dependencias externas.
Revisiones acordadas, comprobaciones y entrega.
Sí. Los prototipos, las versiones de prueba y las comprobaciones se comparten online; los dispositivos compatibles, la publicación y las responsabilidades sobre las cuentas se acuerdan antes del desarrollo.
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 KrelunaPara negocios, estudios y empresas de Roma, el trabajo se organiza a distancia con un único interlocutor, reuniones online programadas y decisiones por escrito. La distancia no cambia el método: primero objetivos y contenidos, después estructura, comprobaciones y publicación.
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.
La primera conversación sirve para distinguir lo que debe funcionar de inmediato de las mejoras posteriores, para que el proyecto no crezca sin control.