Tablet- und Dokumentensituation als Bild für das operative System hinter Energieclub

Plattform

Keine Black Box.
Sondern der Operator-Kern für reale Communities.

Vorne wirkt Energieclub einfach. Dahinter laufen Rollen, Messung, Viertelstunden-Zuordnung, Billing und Audit so zusammen, dass ein erster Betreiberstart belastbar live gehen kann.

Betreiberfall prüfen Kommunalen Rollout prüfen

Kernmodule

Der MVP bildet genau die kritischen Teile des ersten Betreiberstarts ab.

Nicht alles sofort, aber alles Wesentliche für eine erste reale Betreiber-Community: sauber getrennt, nachvollziehbar und nicht von Marketing-Versprechen abhängig.

Community Setup

Region, Bilanzierungsgebiet, Preislogik und Rollenmodell werden explizit konfiguriert, bevor eine Community live gehen kann.

Producer- und Consumer-Onboarding

Assets, Zählpunkte, Dokumente und Zustimmungen werden vollständig erfasst, bevor Teilnehmer produktiv geschaltet werden.

Metering & Datenqualität

15-Minuten-Werte, Deduplikation, Import-Runs sowie Delayed-/Estimated-Zustände machen Datenqualität operativ steuerbar.

Allocation Engine

Lokale Produktion und Verbrauch werden je Viertelstunde deterministisch zugeordnet, inklusive Preis- und Regel-Snapshot.

Billing & Statements

Monatsperioden, Billing-Items und Statements folgen der Allocation, ohne den Rechenkern rückwirkend zu verbiegen.

Audit & Backoffice

Jede Freigabe, Korrektur und jeder Re-Run ist nachvollziehbar dokumentiert, weil ein Pilot ohne Auditfähigkeit operativ kippt.

MVP-Plan

Vier Sprints vom Fundament bis zur Pilotbereitschaft.

Sprint 0

Foundations

Repo, Rollenmodell, Datenbank und App-Shell produktionsnah aufsetzen.

Sprint 1

Onboarding & Stammdaten

Community-, Participant-, Asset- und Metering-Grundlagen inklusive Admin-Flows produktiv machen.

Sprint 2–3

Metering, Allocation, Dashboard

15-Minuten-Daten ingestieren, Runs rechnen und einen belastbaren operativen Überblick schaffen.

Sprint 4

Billing & Pilot Readiness

Statements, Audit-Trail, Backoffice-Härtung und Go-live-Checkliste schließen.

Build-Prinzipien

Die Plattform wird erklärbar gebaut, nicht pseudo-intelligent.

Vertrauen entsteht hier nicht aus Buzzwords, sondern aus deterministischen Runs, sauberer Datenhaltung und offen sichtbaren Pending- sowie Fehlerzuständen.

Energie in Wh und Geld in ct als Integer, nicht als Float-Annäherung

Keine stillen Updates an Messwerten, sondern versionierte Korrekturen

Append-only Allocation Runs statt Black-Box-Neuberechnung

Monatliche Billing-Logik getrennt vom eigentlichen Matching-Kern

Manuelle Pending- und Override-Mechaniken, weil Marktprozesse nicht überall schon standardisiert sind

V1 bewusst klein

Was der erste Build explizit nicht sein soll.

Der MVP darf kein vollautomatischer Energie-Marktplatz werden. Er muss zuerst ein kontrollierbares Backoffice für reale Pilot-Communities liefern.

Kein offener Self-Serve-Marktplatz in V1

Genau ein Metering-Provider statt Multi-Provider-Komplexität

Keine native App in der ersten Ausbaustufe

Kein vollautomatisches Mahnwesen oder Payment Recovery im MVP

Straßenzug mit Wohnhäusern als Bildsprache für lokale Energiegemeinschaften

Operator-Readiness mit echtem Pilotbezug

Wenn du Datenpfad,
Bestand oder Partnerrolle mitbringst, prüfen wir die operative Passung.

Das Gespräch startet nicht bei Architekturfolien, sondern bei einem konkreten Betreiberfall: welche Community, welcher Datenpfad und welche Pilotverantwortung real gemeinsam getragen werden können.

OnboardingMeteringAllocationBilling

Auditierbar statt Black Box · Go-live-orientiert statt Folienprojekt

Wir sprechen erst über den konkreten Betreiberfall, dann über Architektur.

Keine Black Box.Sondern der Operator-Kern für reale Communities.