Corto
Terminkalender und Buchungen für einen Barber Club, vor allem für das Smartphone konzipiert.
Entscheidungen hinter dem Projekt entdecken →Wir konzipieren und entwickeln Apps für Buchungen, Dienstleistungen, Einkäufe oder Betriebsabläufe und wählen Plattformen und Funktionen vor Beginn aus.
Eine nützliche erste Version muss einen vorrangigen Ablauf gut lösen. Konten, Zahlungen, Benachrichtigungen, Backend und Veröffentlichung werden getrennt bewertet und in den Projektumfang aufgenommen.
Einziger Standort in Montecatini Terme: Kreluna hat kein Büro in Florenz. Bürogespräche finden nach Terminvereinbarung statt. Analyse, Abstimmungen und Übergabe können online erfolgen. Andere Treffen werden gesondert vereinbart und sind nicht automatisch enthalten.
Mobiles ErlebnisCorto-App ausprobierenDemo öffnenDie Demos zeigen Ansichten und Abläufe für Buchungen oder Käufe. Sie belegen kein produktives Backend, zugestellte Benachrichtigungen, echte Zahlungen oder eine Veröffentlichung in App-Stores. Diese Teile erfordern ein eigenes Projekt.
Terminkalender und Buchungen für einen Barber Club, vor allem für das Smartphone konzipiert.
Entscheidungen hinter dem Projekt entdecken →
Ein mobiler Ablauf für Behandlungen, Verfügbarkeit und Buchungen.
Entscheidungen hinter dem Projekt entdecken →
Ein Vermietungskonzept mit direkter Suche, Auswahl und Nutzung.
Entscheidungen hinter dem Projekt entdecken →Von Kreluna konzipierte und entwickelte Demo-Konzepte: Sie zeigen Vorgehensweise und Qualität, werden jedoch nicht als Kundenaufträge dargestellt. Alle Projekte und Designentscheidungen entdecken →
Verwaltet die App Besuche, Aufenthalte oder Veranstaltungen, unterscheiden wir Anfrage, Verfügbarkeit und Bestätigung. Vor dem Prototyp benötigen wir Regeln für Kapazitäten, Zeiten und Stornierungen sowie die Quelle aktueller Daten.
Kalender, Zeitfenster, Tickets und Inhalte zum Ort müssen auch funktionieren, wenn Nutzer wenig Zeit haben. Wir erstellen zuerst einen Prototyp des Ablaufs und prüfen, wo Karten, Benachrichtigungen oder ein Offline-Modus benötigt werden.
Check-in, Anfragen, Informationen und Angebote können in einer Web-App bereitstehen, ohne einen Download zu verlangen. Die Wahl zwischen App, Web-App und Integration begründen wir mit dem tatsächlichen Verhalten der Gäste.
Programm, Favoriten, Zugänge und Mitteilungen erfordern klare Regeln zu Konten, Daten und Moderation. Wir gestalten die wichtigsten Zustände, bevor wir Entwicklung und Veröffentlichung in den App-Stores kalkulieren.
Nutzer, Bildschirme und zentrale Aktion werden vor der Programmierung festgelegt.
Der Ablauf wird geprüft und anschließend auf den vereinbarten Plattformen umgesetzt.
Geräte, App-Store-Konten, Veröffentlichung und Wartung werden im Angebot festgelegt.
Wir beginnen mit der Aktion, die die App vereinfachen soll: buchen, kaufen, einen Dienst nutzen oder eine Aufgabe verwalten.
Bildschirme, Konten, Zahlungen, Benachrichtigungen, Backend sowie iOS-, Android- oder Web-Versionen werden vor der Programmierung festgelegt.
Geräte, App-Store-Konten, Daten, Prüfungen und Zuständigkeiten für die Veröffentlichung werden im Angebot angegeben.
Buchungen, Routen, Inhalte, Support und Konten bieten dann Mehrwert, wenn sie im richtigen Moment Schritte reduzieren. Wir definieren den Nutzungskontext und konzentrieren die erste Version auf die zentrale Aktion.
Vor der Entwicklung klären wir, wer Informationen, Verfügbarkeit und Benachrichtigungen aktualisiert. Eine dauerhaft betreibbare App braucht neben der sichtbaren Oberfläche auch einen Verwaltungsablauf.
Wir teilen einen Beispielablauf mit Nutzer, Ausgangsdaten, Aktion und erwartetem Ergebnis einschließlich eines Fehlers oder Abbruchs. Der Prototyp klärt die Schritte. Integrationen und technische Prüfungen werden separat bewertet; Entscheidungen und Korrekturen werden dokumentiert.
Ziel, Zielgruppe, Materialien und aktuelle Tools.
Enthaltene Leistungen, Zeitplan, Kosten und externe Abhängigkeiten.
Vereinbarte Korrekturrunden, Prüfungen und Übergabe.
Das hängt von den APIs und Zugängen des Systems ab. Die Kompatibilität wird geprüft, bevor die Anbindung ins Angebot aufgenommen wird.
Jedes Projekt beginnt mit deinen Anforderungen. Gemeinsam legen wir Ziele, Funktionen und Zeitrahmen fest und erstellen anschließend ein individuelles Angebot.
Ja, wenn beide Plattformen im Projekt vorgesehen sind. Das Angebot stellt immer klar, welche Versionen und Geräte enthalten sind.
Nicht unbedingt. Häufig ist es sinnvoll, mit einer ersten grundlegenden Version zu beginnen und den Nutzen des Hauptablaufs zu prüfen.
Beschreiben Sie die Nutzer, die Hauptaktion und einen vollständigen Beispielablauf einschließlich Fehlern oder Abbrüchen. Nennen Sie Geräte, Daten, bestehende Systeme, Offline-Anforderungen und vorhandene Konten. Das Angebot trennt Prototyp, Entwicklung, Backend, Veröffentlichung und Wartung.
Beschreiben Sie eine Aktion, die sich mit der App abschließen lassen muss, und die Zielgruppe. Nennen Sie Geräte, Daten und anzubindende Systeme. Daraus leiten wir die zu bewertende erste Version ab.
Kreluna schreibenKreluna hat einen einzigen Standort in Montecatini Terme. Gespräche im Büro finden nach Terminvereinbarung statt. Analyse, Abstimmungen und Übergabe können vollständig online erfolgen; andere Treffen werden gesondert vereinbart. Inhalte, Entscheidungen und Zuständigkeiten werden schriftlich dokumentiert.
Wir beschreiben die zentrale Aktion, Nutzer, Daten und unverzichtbare Benachrichtigungen. Prototyp, Plattformen, Veröffentlichung in den App-Stores und anschließender Betrieb werden getrennt betrachtet, um ungeplante Kosten oder Funktionen zu vermeiden.
Bilder und Stil haben eine klare Aufgabe: Menschen dabei zu helfen, das Angebot zu verstehen und ohne Verwirrung zur wichtigen Aktion zu gelangen.