Certor — Unser gemeinsamer Weg zur digitalen Zertifizierungsverwaltung
Certor soll die komplette Zertifizierungsverwaltung (Anfragen, Audits, Zertifikate, Deadlines) in ein einziges, modernes Werkzeug zu gießen. Statt Excel-Listen, verstreuten E-Mails und manuellen Erinnerungssystemen gibt es eine zentrale Oberfläche, die sowohl Büroteams als auch Auditor:innen hilft, Fristen einzuhalten und zusammenzuarbeiten.
Bei Certor ging es von Anfang an weniger darum, eine perfekte Lösung auf dem Reißbrett zu entwerfen, als vielmehr darum, gemeinsam etwas Praktisches zu bauen. Wir haben Konzepte geschrieben, Datenmodelle gezeichnet, GUI‑Screens entworfen und dann mit dem Coden begonnen — oft in kleinen Iterationen, mit Feedback‑Schleifen und echten Anwender:innen im Blick.
Vom Konzept zur ersten Version
Unsere Arbeit startete mit klaren Briefings und einer Vision: eine Desktop‑zentrische Anwendung, die Audits, Zertifizierungsanträge und Fristen zuverlässig verwaltet. In Workshops haben wir Abläufe skizziert, Verantwortlichkeiten definiert und die wichtigsten Entitäten festgelegt. Daraus entstanden die ersten ER‑Diagramme und eine Liste mit Kernfunktionen.
Datenmodellieren und Diagramme
Die Datenmodellphase war eine gute Gelegenheit, die Realität des Alltags abzubilden: Kontakte, Adressen, Zertifizierungsanträge, Audit‑Container, Dokumente — all das musste flexibel verknüpfbar sein. Wir haben das Modell so gestaltet, dass es erweiterbar bleibt (customFields) und Inline‑Verknüpfungen von Dokumenten und Notizen zu allen Entitäten erlaubt.
UI‑Design: Klar, ruhig, effizient
Beim GUI‑Design haben wir uns entschieden, auf Desktop‑Konventionen zu setzen: Sidebar, List‑Views, Detail‑Tabs und Split‑Views. Diese Entscheidungen kamen direkt aus den Anforderungen: Nutzer:innen arbeiten mit vielen Datensätzen gleichzeitig und brauchen effiziente Navigation und legere Fokus‑Wechsel.
Erste Implementierungsschritte
Mit Flutter als technischer Basis haben wir die ersten Kernkomponenten implementiert: eine Kontaktverwaltung, einfache Audit‑Objekte und ein Auth‑System (mit Supabase als Backend). Wichtige Prinzipien während des Coden waren: testbare Komponenten, klare Trennungen zwischen UI und Geschäftslogik und eine Provider‑basierte Auth‑Architektur.
Zusammenarbeit und Lernen
Besonders wertvoll war die iterierende Zusammenarbeit: Konzepte wurden in Code geprüft, Code erzeugte neue Fragen für das Konzept, und die GUI‑Entwürfe wurden laufend angepasst. Das ist genau das, was wir auch unseren angehenden Entwickler:innen in der Academy beibringen — echtes, projektbasiertes Lernen.
Nächste Schritte
Aktuell arbeiten wir an der Fristen‑ und Task‑Engine, an Report‑Templates und an der Integration der Dokumentengenerierung. Parallel steht die Migration von Test‑daten und die Vorbereitung für erste Pilotanwender:innen an.
Wenn du Lust hast, das Projekt praktisch zu begleiten oder konkrete Anforderungen einzubringen, sag Bescheid — echtes Nutzerfeedback formt das Produkt am stärksten.
