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 Pistoia. 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 →
Arbeiten Techniker, Vertriebsmitarbeiter oder andere Beschäftigte außer Haus, klären wir die mobil zu lesenden und zu erfassenden Daten. Netzabdeckung, Berechtigungen und Synchronisierung beeinflussen die Wahl zwischen App und Web-App.
Zuweisungen, Fotos, Unterschriften und Arbeitsstatus können einem gemeinsamen Ablauf folgen. Wir prüfen Netzabdeckung, Offline-Nutzung und Berechtigungen, bevor wir Plattform und Technologie auswählen.
Soll die App Verfügbarkeiten lesen oder Anfragen an ein Verwaltungssystem senden, prüfen wir vor der Aufwandsschätzung APIs und Zugänge. Wir klären Korrekturrechte und das Verhalten bei Fehlern oder fehlender Synchronisierung.
Mobile Portale und Web-Apps können Anfragen, Dokumente und Fortschritte erfassen, ohne Anrufe und Nachrichten zu vervielfachen. Jede Benachrichtigung wird an ein nützliches Ereignis gebunden und nicht als Werberauschen eingesetzt.
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.
Für den Außeneinsatz verfolgen wir ein Beispiel von der Zuweisung bis zum Abschluss: Pflichtdaten, Fotos oder Dokumente, Status und Zuständigkeit. Bei Offline-Bedarf definieren wir vor der Aufwandsschätzung auch späteres Senden und Konfliktbehandlung.
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.