Wir entwickeln Apps für Mobilgeräte und Desktop sowie Browser-Erweiterungen. Kleines Team, unabhängig, Remote-first. Wir veröffentlichen, was wir selbst auf unseren Smartphones, Computern und in unseren Browsern haben wollen – und sonst nichts.
Wir finden, dass der übliche Rhythmus der modernen Mobile-Branche – ständige Releases, halbfertige Funktionen, alles per A/B-Test – Nutzer ermüdet und Teams zermürbt. Wir veröffentlichen, wenn die Arbeit fertig ist, nicht wenn der Sprint es vorgibt. Manchmal dauert das eine Woche, manchmal ein Quartal. So oder so: Das Update kommt an und fühlt sich fertig an.
Wir erheben nur, was eine App wirklich zum Funktionieren braucht. Was auch immer das ist – Analysen, Werbung, Sync-Server –, es steht vor der Installation in den Datenschutzangaben im Store und in der Datenschutzerklärung der App. Keine versteckte Datenerhebung, keine Verhaltensprofile, die an Datenhändler verkauft werden.
Einige unserer Apps sind Einmalkäufe. Einige sind kostenlos mit optionalen Abonnements. Einige sind werbefinanziert. Welches Modell auch immer zum Produkt passt – es steht klar im Store-Eintrag: keine versteckten Gebühren, keine überraschenden automatischen Verlängerungen, keine Dark Patterns.
Wir bleiben klein. So klein, dass die Person, die den Code geschrieben hat, auch Ihre E-Mail über den Fehler darin liest. Keine Support-Stufen, keine Eskalationskette. Es gibt ein Postfach, und wir lesen es.
Gründete Zydeno 2026 nach zehn Jahren, in denen er Software für die Firmen anderer Leute gebaut hat. Entscheidet, was wir veröffentlichen – und, wichtiger noch, was nicht. Ist überzeugt, dass die meisten Apps mit der Hälfte der Funktionen besser wären.
Verantwortet die visuelle Sprache jeder Zydeno-App. Typo-Nerd, bei Animationen minimalistisch. Fünf Jahre Print- und Editorial-Design, bevor es um Bildschirme ging – das sieht man der Typografie an. Lässt kein Interface durch, das nur funktioniert, wenn es sich auch richtig anfühlen könnte.
Hat sechs Jahre lang Motion Graphics für Werbeagenturen animiert, bevor er in die Produktentwicklung wechselte. Jede Federanimation, jeder Tap, jeder Übergang in einer Zydeno-App geht durch seine Hände. Ist überzeugt, dass eine Easing-Kurve von 240 ms den Unterschied zwischen Werkzeug und Spielzeug ausmacht.
Entwickelt nativ für iOS seit iOS 5. Allergisch gegen den SwiftUI-Hype, schreibt Swift-Code, der auf einem fünf Jahre alten iPhone in unter einer Sekunde startet. Liest Release Notes zum Vergnügen. Verantwortet die Architektur jeder iOS-App, die wir veröffentlichen, und prüft jeden Pull Request, der die Laufzeitumgebung berührt.
Acht Jahre Swift, davor zwei Jahre Objective-C. Taucht tief in Core-Data-Migrationen, Hintergrundaufgaben und die Teile von UIKit ein, bei denen StackOverflow aufgegeben hat. Übernimmt die zweite Rufbereitschaft für Abstürze im Live-Betrieb – und mag das lieber als Feature-Arbeit.
Kam zu uns nach zwei Jahren, in denen sie in einem Studio für Design-Tools iOS-Komponenten für Unternehmen gebaut hat. Arbeitet in SwiftUI, wenn es sinnvoll ist, und wechselt zu UIKit, wenn nicht. Verantwortet den Großteil unserer gemeinsamen UI-Komponentenbibliothek – die kleinen, durchdachten Bausteine, die jede App wiederverwendet, damit sich das nächste Release von der ersten Minute an vertraut anfühlt.
Kotlin-Maximalist. Legt mehr Wert auf die Kaltstartzeit und den Akkuverbrauch als auf die Anzahl der Funktionen. Behandelt jedes Kilobyte wie Miete. Kümmert sich um die Android-Portierungen und seit kurzem auch um die Windows-Builds – für die Apps, die es verdienen.
Alles, was die Nutzer nie zu sehen bekommen: Synchronisierung, Offline-First-Speicher – all die langweiligen Dinge, die die App so magisch wirken lassen. Er betreibt unsere Infrastruktur im Alleingang, erstellt unsere Chrome-, Edge- und Firefox-Erweiterungen und hat es genau so am liebsten.
Die letzte Person, die jeden Build in die Hand nimmt, bevor er veröffentlicht wird. Verantwortet die Qualitätssicherung und die Disziplin, „noch nicht“ zu sagen. Pflegt die Regressionstests, mit denen das Team schnell vorankommt, ohne die Apps kaputtzumachen, die schon auf den Homescreens der Leute liegen.
Wir stellen langsam ein. Wir sind uns oft uneins. Und liefern trotzdem.
Skizzen, User Flows, schonungslose Diskussionen darüber, ob es das Ding überhaupt geben sollte. Übersteht es diese Phase, hat es sich das Recht verdient, gebaut zu werden.
Echter Code auf echten Geräten. Keine Mockups, keine Fake-Daten. Fühlt es sich in dieser Phase schlecht an, wird es sich auch beim Release schlecht anfühlen – wir reparieren es hier, oder wir verwerfen es.
Mikrointeraktionen, Textfeinschliff, ein Durchgang für Barrierefreiheit – die 200 kleinen Details, die funktionierende Software von guter Software unterscheiden. Dann geht es raus.
Jeder Fehlerbericht und jeder Funktionswunsch wird gelesen. Nicht alles wird umgesetzt. Was umgesetzt wird, landet im nächsten Zyklus – nicht im nächsten Hotfix.