Nativ und plattformübergreifend für iOS und Android. In die Stores zu kommen ist der leichte Teil: der schwere ist, dass jemand sie am nächsten Tag wieder öffnet.
analyse --nutzung "was tut die Person in 30 Sekunden"
eine Hand · kleiner Bildschirm · unzuverlässiger Empfang
pruefe --braucht-es-wirklich-eine-app
wenn nur nachgeschlagen wird, kostet eine Website einen Bruchteil
./stores --anforderungen
[ok] Apple- und Google-Konten auf Ihren Namen
[ok] Prüfzeiten der Stores im Zeitplan eingeplant
wartet
$ ./app --tag 30
Ein Startbildschirm hat keinen unendlichen Platz, und niemand räumt ihn aus Freundlichkeit auf. In den ersten Tagen nach der Installation verschwinden Apps, die keinen Grund zum Wiederöffnen geben, von allein. Sehen Sie selbst.
20 noch geöffnete Apps
Es bleiben 3. Die Arbeit besteht darin, eine davon zu sein.
// wann es nötig ist
Veröffentlichen ist einfach. Schwer ist, sich einen Platz auf dem Startbildschirm zu verdienen. Treffen weniger als drei dieser Punkte zu, brauchen Sie vermutlich eine gut gebaute Website.
// was wir bauen
Ändert sich, wer sie nutzt, ändert sich alles: Oberfläche, Prioritäten, sogar die Wahl der Technologie.
Buchungen, Bestellungen, Kundenbindung, Support. Der direkte Kanal zu denen, die Sie wählen, ohne Zwischenhändler, der Prozente nimmt.
Aufmaße, Checklisten, Berichte, Lager, Unterschriften. Sie funktionieren ohne Netz und gleichen ab, sobald der Empfang zurück ist.
Der mobile Begleiter eines Business-Systems oder Portals: dieselben Daten, dieselbe Logik, eine Oberfläche fürs Telefon.
Wir haben keine Technologie zu verteidigen. Eine Codebasis, wo es sich lohnt, zwei, wo Leistung oder Sensoren es verlangen.
// wie wir dahin kommen
Die Prüfung durch Apple und Google schwankt und liegt nicht bei uns: wir planen sie von Anfang an ein, samt Puffer für eine mögliche Änderungsanforderung.
Wer sie nutzt, wo, mit wie viel Netz und wie vielen freien Händen. Daraus kommt auch die Ehrlichkeit: manchmal lautet die Antwort, dass keine App nötig ist.
Ein echter Ablauf, den man auf dem Telefon anfassen kann, keine Folien. Sie testen ihn mit den späteren Nutzern, bevor endgültiger Code existiert.
Alle zwei Wochen installierbare Builds über TestFlight und einen internen Android-Kanal. Getestet auf echten Geräten, nicht im Simulator.
Store-Einträge, Screenshots, Datenschutzangaben, Prüfung. Danach Wartung mit schriftlicher Vereinbarung — oder wir schulen Ihr Team.
$ cat stack.json
$ ./domande --frequenti
Ja, und sie müssen auf Ihren Namen laufen, nicht auf unseren: der Store-Eintrag, die Bewertungen und die Einnahmen müssen Ihnen gehören, auch wenn Sie eines Tages den Dienstleister wechseln. Wir begleiten Sie bei Einrichtung und Konfiguration, aber die Konten gehören Ihnen.
Zur Entwicklung kommt die Prüfzeit der Stores, die schwankt und nicht bei uns liegt. Wir planen sie von Beginn an ein, samt Puffer für den Fall, dass eine Änderung verlangt wird.
Wenn es wirklich nötig ist, ja. Diese Entscheidung fällt am Anfang, weil sie die Architektur verändert: sie später einzubauen kostet weit mehr, als sie einzuplanen.
Das können wir mit einem Wartungsvertrag übernehmen, oder wir schulen Ihr Team. Store-Konten und Zugangsdaten gehören Ihnen ab dem ersten Tag, das Veröffentlichen hängt also nie von uns ab.
Das hängt davon ab, was sie leisten soll. Plattformübergreifend lohnt sich, wenn die App aus Masken, Daten und Abläufen besteht: Zeit und Kosten sinken spürbar. Nativ lohnt sich bei Grafikleistung, intensiver Sensornutzung oder tiefer Systemintegration. Die Entscheidung treffen wir gemeinsam in der Analyse, mit schriftlicher Begründung.
Die Variablen sind die Zahl der Masken, die Zahl der Schnittstellen und ob sie offline funktionieren muss. Eine Zahl nennen wir nach dem Prototyp, wenn der Umfang sichtbar ist: davor wäre es eine als Schätzung verkleidete Wette.
fymera init --projekt "Ihres"
Dreißig Minuten per Video, um zu klären, wer sie nutzt und ob es sich lohnt. Wenn eine Website reicht, sagen wir es.
