Über das Projekt und den Kunden#
Ein intuitiv bedienbares Produkt auf Basis des Marktwissens unseres Kunden entwickeln, das den Markt für die Betreuung von Angehörigen verbessert: Menschen mit Unterstützungsbedarf werden in wenigen Minuten mit passenden Betreuungskräften aus der Umgebung zusammengebracht – ohne Vermittler, was beiden Seiten Zeit spart und einen klaren Einblick in die Details der vorgeschlagenen Profile gibt.
Die Zusammenarbeit mit dem Team war von Anfang an auf einem sehr hohen Niveau. Am meisten schätze ich die Professionalität, das Engagement und den ständigen Kontakt in jeder Phase des Projekts. Ich wusste jederzeit, wo die Arbeiten standen, und jede Frage wurde laufend besprochen.
Am meisten beeindruckt hat mich, wie sie mit meinen Ideen umgegangen sind. Ich konnte meine Vorstellung frei äußern, auch wenn sie noch nicht ganz ausgereift war, und sie konnten daraus konkrete Lösungen machen und eigene, oft noch bessere Konzepte vorschlagen.
Womit wir uns beschäftigt haben#
Opiekly entstand in einem Feld, das sensible Daten, zwei sehr unterschiedliche Nutzertypen und einen komplexen Abgleich zwischen Betreuungskraft und Familienbedarf verbindet. Die zentralen Herausforderungen: wie man eine sehr komplexe Auswahlentscheidung vereinfacht, wie man sicher mit den Daten umgeht und wie man ein Produkt für zwei unterschiedliche Rollen gestaltet.
Wie vergleicht man Kriterien, die sich nicht vergleichen lassen?
Eine Familie auf der Suche nach einer Betreuungskraft wägt vieles gleichzeitig ab: Umfang der Hilfe, Erfahrung, Standort, Verfügbarkeit und konkrete gesundheitliche Bedürfnisse. Die Schwierigkeit: Diese Kriterien haben kein gemeinsames „Gewicht“ – verschiedene Nutzer gewichten sie unterschiedlich. Also mussten wir eine Darstellung der Ergebnisse entwerfen, die die Entscheidung nicht künstlich vereinfacht.
Sensible Daten in der Anwendung
Die Anwendung arbeitet mit Daten wie Gesundheitsangaben, Adresse und Kontaktdaten. Die Schwierigkeit: dem Nutzer genug zu zeigen, damit er entscheiden kann, diese Daten aber weder unnötig offenzulegen noch angreifbar zu machen.
Wann im Profil-Assistenten soll das Konto entstehen?
Das Onboarding musste einen einfachen Einstieg mit der nötigen Verifizierung in Einklang bringen. Ein zu früh angelegtes Konto schreckte Nutzer ab, ein zu spätes bedeutete verlorene Daten und keine Möglichkeit zur Kontaktaufnahme. Gesucht war der Moment, in dem der Nutzer bereits eingebunden, aber noch nicht von Formalitäten „erschlagen“ ist.
Zwei Rollen in einer Anwendung
Die Anwendung bedient zwei unterschiedliche Nutzertypen: Familien und Betreuungskräfte. Die Schwierigkeit: Trotz gemeinsamem System haben beide Gruppen andere Bedürfnisse, andere Informationen und eine andere Art, das Produkt zu nutzen – und das musste in eine einzige, stimmige Erfahrung passen.
Während der ganzen Zusammenarbeit hatte ich das Gefühl, dass wir für jede Frage gemeinsam eine Lösung finden können. Ich habe nie gehört, dass etwas „nicht machbar“ sei – das Team hat immer nach einem Weg gesucht, das gewünschte Ergebnis zu erreichen. Diese professionelle Haltung war mir am wichtigsten und hat mir sehr viel Sicherheit und Vertrauen gegeben.
Ein ähnlich komplexes Projekt? Sprechen wir darüber.
Vermittlung, Rollen, sensible Daten und Skalierung – wir wissen, wie daraus ein stimmiges Produkt wird.
Wie wir an das Projekt herangegangen sind#
Vier Grundsätze, nach denen wir das Projekt geführt haben: zuerst das Gespräch mit dem Kunden – einem langjährigen Praktiker der Branche, dann Code. Schlichtes, wirksames Design – viele Menschen in der Zielgruppe nutzen im Alltag keine komplexen Anwendungen. Jede Stufe liefern wir vollständig – Datenbank, Server und den fertigen Screen im Browser – damit der Kunde eine funktionierende Funktion sieht und keine Skizze. Wir fragen nach, wenn wir etwas nicht wissen – weil es uns um das beste Produkt geht, nicht um eine eindrucksvolle Demo.
Die Richtung gemeinsam mit dem Kunden festlegen, einem Praktiker der Branche
Bevor wir begannen, haben wir gemeinsam mit dem Kunden, der über langjährige Erfahrung in der Betreuungsbranche verfügt, den Produktumfang präzisiert: die Listen der Betreuungsaufgaben, die Krankheitsbilder und den optimalen Nutzerweg – von der Bedarfsbeschreibung durch die Familie über das Profil der Betreuungskraft bis zum Kontakt. Außerdem haben wir eine gemeinsame Fachsprache vereinbart, was die weiteren Schritte deutlich beschleunigt hat.
Eine einfache und selbsterklärende Oberfläche
Wir gestalten für Menschen, die im Alltag oft keine Anwendungen nutzen – auf Seiten der Familien wie auf Seiten der Betreuungskräfte. Deshalb muss jeder Screen auf den ersten Blick verständlich sein. Statt umfangreicher Formulare setzen wir auf kurze Schritte, einfache Sprache und eine Hauptaktion je Screen. Einfachheit ist hier kein ästhetisches Element, sondern die Bedingung dafür, dass das Produkt zur Zielgruppe passt.
Nach jeder Iteration eine funktionierende Funktion
Jede Aktualisierung ist eine funktionierende Funktion im Browser, keine statische Demo. Der Ablauf folgt einer kurzen Schleife: zeigen, Rückmeldung, iterieren. Jedes Modul wird vollständig geliefert – samt Datenbank, Oberfläche und Tests. Die Integration läuft fortlaufend mit, statt auf spätere Phasen verschoben zu werden.
Ständiger Kundenkontakt und frühe Validierung der Annahmen
Das Branchenwissen des Kunden ist für uns der Wegweiser, deshalb halten wir über einen jederzeit offenen Kanal ständigen Kontakt. Wir zeigen regelmäßig den Fortschritt und prüfen Annahmen, bevor wir tiefer einsteigen – so verringern wir das Risiko großer Änderungen in fortgeschrittenen Phasen und können Anregungen schnell aufnehmen und Ideen besprechen.
Zentrale Ansichten#
Der Registrierungsassistent ist eine durchgehende Ansicht in mehreren Schritten – von der Wahl der Rolle und der Betreuungsart über Mobilität und Aufgabenumfang bis zur Adresse mit Einsatzradius. Für die Betreuungskraft sieht der Assistent anders aus als für die betreuungssuchende Person – jede Rolle hat ihren eigenen Weg. Unten einige ausgewählte Ansichten aus dem Assistenten.
Was wir geliefert haben#
Eine startbereite Webplattform mit dem vollständigen Ablauf für Familie und Betreuungskraft – von der Registrierung über die Vermittlung und sichere Konten bis zum Kontakt zwischen den Nutzern.
Ich kann dieses Team mit voller Überzeugung jedem empfehlen, der einen Partner sucht, der nicht nur eine App entwickelt oder Software schreibt, sondern auch eigene Erfahrung, eigenes Wissen und Engagement als unschätzbaren Wert in das Projekt einbringt.
Möchten Sie ähnliche Ergebnisse im eigenen Haus?
Erste Analyse und Einschätzung innerhalb von 48 h. Unverbindlich — der erste Schritt liegt immer bei uns.
Entscheidungen, die den Unterschied gemacht haben#
Die technischen Entscheidungen, die die Qualität des Systems am stärksten geprägt haben. Ein moderner, aber standardnaher Stack – ohne exotische Abhängigkeiten, leicht zu warten und zu prüfen.
API aus OpenAPI generiert statt handgepflegter Verträge
NestJS erzeugt die OpenAPI-Spezifikation aus Controllern und DTOs, das Frontend nutzt einen automatisch generierten Client (TypeScript, React Query, Zod). Damit ist OpenAPI die einzige Quelle der Wahrheit.
Eine Vertragsänderung im Backend führt sofort zu einem Compile-Error im Frontend – Typabweichungen und Runtime-Fehler entfallen.
Die Vermittlungslogik in die Datenbankschicht verlagert
Der Algorithmus (Filter, Haversine-Distanz, Aufgabenabdeckung und Ranking) läuft in einer einzigen SQL-Abfrage. Die Anwendung erhält ein bereits sortiertes Ergebnis, ohne zusätzliche Verarbeitung in JS.
Das erspart den Aufwand für die Datenübertragung und hält das System skalierbar, wenn die Zahl der Betreuungskräfte wächst.
Sentry als Quelle der Wahrheit über die Stabilität der Anwendung
Sentry überwacht Runtime-Fehler in Frontend und Backend. Es beantwortet die Frage nach der Stabilität: Was bricht, an welcher Stelle im Stack, bei wie vielen Nutzern, in welcher Version.
Source Maps und ein Sentry-Tunnel liefern lesbare Stack Traces und umgehen Adblocker, sodass das Fehlerbild die reale Nutzerschaft abbildet.
PostHog als Maßstab für die Nutzbarkeit des Produkts
PostHog wertet Nutzerverhalten und Conversion im Produkt aus. Es beantwortet die Frage nach der Nutzbarkeit: Welche Wege funktionieren, wo brechen Nutzer ab, welche Funktionen werden tatsächlich genutzt.
Die gemeinsamen Event-Definitionen liegen in einem geteilten Enum, was Abweichungen in der Analyse zwischen Frontend, Backend und Dashboards ausschließt.
Feedback dort erheben, wo echte Interaktion mit dem Produkt stattfindet
Die Befragungen starten nach zentralen Aktionen (z. B. dem Senden einer Anfrage, dem Freigeben der Kontaktdaten) statt über dauerhaft eingeblendete Widgets.
Das System arbeitet in zwei Modi: mit Einwilligung (vollständige Anbindung an PostHog) und ohne Einwilligung (anonyme Events ohne Nutzeridentifikation, ohne Möglichkeit, Sitzungen zu verknüpfen).
Tech-Stack#
Die Bibliothekswahl rund um die Entscheidungen oben. Standard, gut gepflegt, ohne Verwaisungsrisiko.
FRAMEWORK · NAVIGATION
SPRACHE
UI & STYLING
STATE, DATEN & CODEGEN
BACKEND & DB
AUTH · BENACHRICHTIGUNGEN
OBSERVABILITY & ANALYTICS
INFRA & DEVOPS
Umgebungen und Wege in die Produktion#
Vier Umgebungen, jede mit einem anderen Vertrauensbereich. Build und Deployment sind über GitLab CI/CD automatisiert, die Image-Tags sind je Commit unveränderlich – ein laufendes Image lässt sich nie versehentlich überschreiben.