Software für Entsorger

// Das Problem

Ein privater Entsorger plant seine Touren auf Papier, kann eine verpasste Leerung in keine Richtung belegen und erfährt von überquellenden Behältern durch verärgerte Anrufe.

// Was wir bauen würden

Tourenplanung für die Disposition und eine Android-App auf Tablets im Fahrerhaus, die Fahrer Stopp für Stopp führt, jede Leerung mit GPS und bei Bedarf einem Foto erfasst, zugestellte oder verunreinigte Behälter protokolliert und Abweichungen in Echtzeit an die Disposition zurückschickt.

// Was drin ist

// Tech-Stack

• Next.js
• Kotlin für Android
• PostgreSQL mit PostGIS
• Routing-Engine
• AWS

// Das Problem

Eine Gemeinde liefert Zehntausende Tonnen aus, kann nicht sagen, welche Tonne an welcher Adresse steht, und bearbeitet Beschwerden über verpasste Leerungen ohne Nachweis der Leerung.

// Was wir bauen würden

UHF-RFID-Tags an jeder Tonne, Lesegeräte und ein Edge-Gateway an jedem Fahrzeug, die jede Leerung mit Zeit und Ort erfassen, ein Tonnenbestand je Adresse und Masken für den Kundenservice, die die Leerungshistorie zeigen, wenn eine Bewohnerin anruft.

// Was drin ist

// Tech-Stack

• UHF-RFID (EPC Gen2)
• Edge-Gateways an den Fahrzeugen
• Next.js
• PostgreSQL mit PostGIS
• AWS

// Das Problem

Eine Umladestation schreibt Wiegescheine von Hand, tippt sie später in die Abrechnung, und ihre Gewerbekunden warten Wochen auf Rechnungen, die sie dann bestreiten.

// Was wir bauen würden

Eine Waagenhaus-App, die die Waagenanzeige direkt liest, Scheine druckt und speichert, die Preise jedes Kunden je Material ansetzt und Rechnungen und Zahlungen in QuickBooks Online bucht, gebaut auf der API von QuickBooks Online, mit einem Portal, in dem Kunden ihre Scheine sehen.

// Was drin ist

// Tech-Stack

• Next.js
• PostgreSQL
• Schnittstelle zur Waagenanzeige
• QuickBooks Online API
• DigitalOcean

// Das Problem

Ein Recyclingprogramm verliert Ladungen durch Fehlwürfe, kann aber nicht sagen, welche Touren oder Adressen sie verursachen, also geht Aufklärung an alle und ändert nichts.

// Was wir bauen würden

Ein eigenes Bildmodell, auf den eigenen Bildern der Schüttungskamera des Programms nachtrainiert, das wahrscheinliche Fehlwürfe markiert, während jede Tonne geleert wird, verknüpft mit dem RFID-Leerungseintrag der Tonne, sodass das Programm gezielte Hinweise an die Adressen schicken kann, die sie brauchen.

// Was drin ist

// Tech-Stack

• PyTorch
• ONNX Runtime
• Python
• Next.js
• AWS-GPU-Instanzen

// Das Problem

Ein Programm zur Herstellerverantwortung stützt sich darauf, dass Sammler, Verwerter und Abnehmer die Tonnen melden, die sie bewegen, jeder in seinem eigenen Format, und das Abgleichen dauert Monate.

// Was wir bauen würden

Eine gemeinsame Aufzeichnung der Tonnen, die vom Sammler zum Verwerter zum Abnehmer gehen, auf einem privaten Register mit Zugangsberechtigung, von dem das Programm und seine wichtigsten Verwerter je einen Knoten betreiben, gespeist aus Wiegedaten, sodass der Bericht des Programms bei einer Aufzeichnung anfängt. Vertrauen alle der eigenen Datenbank des Programms, ist sie günstiger, und wir sagen Ihnen das.

// Was drin ist

// Tech-Stack

• Next.js
• Hyperledger Besu (privat, mit Zugangsberechtigung)
• PostgreSQL
• Anbindung an die Waagenhaus-Software
• AWS

// Das Problem

Die kommunalen und gewerblichen Kunden eines Entsorgers wollen jedes Quartal Verwertungszahlen, und das Team baut sie in Tabellen aus Wiegescheinen, Tourenaufzeichnungen und Abrechnungen der Verwerter.

// Was wir bauen würden

Ein Berichtsspeicher, der Wiegescheine, Touren und Verwerterabrechnungen jede Nacht zusammenführt, Tonnage und Verwertungsquote nach Kunde, Material und Standort nach dokumentierten Regeln berechnet und den Quartalsbericht jedes Kunden aus denselben Daten erstellt.

// Was drin ist

// Tech-Stack

• PostgreSQL
• dbt
• Apache Superset
• Python
• DigitalOcean