Software für Fracht

// Das Problem

Ein regionaler Frachtführer disponiert per Telefon und gemeinsamer Tabelle, also rufen Kunden nach dem Stand an, und Ablieferbelege erreichen die Abrechnung lange nach der Zustellung.

// Was wir bauen würden

Eine Disponiertafel im Web, die Ladungen plant und vergibt, mit einer Fahrer-App für iOS und Android für Stopps, Statusmeldungen, Unterschriften und Fotos, und einem Verfolgungslink, den die Kundin öffnet, statt anzurufen.

// Was drin ist

// Tech-Stack

• Next.js
• React Native
• PostgreSQL mit PostGIS
• ELD- und Telematik-APIs
• AWS

// Das Problem

Ladungsanfragen und Preisanfragen kommen als E-Mails, Tabellen und PDFs in jedem Aufbau, und eine Koordinatorin tippt jede ins TMS ab, bevor irgendwer ein Angebot machen kann.

// Was wir bauen würden

Ein Agent, der jede Ladungsanfrage liest, Abgangsort, Ziel, Daten, Gewichte und Referenzen herausholt, sie gegen die Relationen des Kunden prüft und die Ladung im TMS zur Freigabe durch eine Koordinatorin vorbereitet. Er läuft auf einem Spitzenmodell über dessen API, dem schnellsten Anfang, weil Ladungsanfragen alltägliche Geschäftsdaten sind, die der Anbieter nach seinen Geschäftsbedingungen verarbeitet.

// Was drin ist

// Tech-Stack

• API eines Spitzenmodells
• Python
• Next.js
• PostgreSQL
• TMS-API
• DigitalOcean

// Das Problem

Verlader, Frachtführer und Empfänger führen je eine eigene Kopie des Frachtbriefs und des Zustellnachweises, also wird ein Schadenfall wegen Fehlmenge oder Beschädigung zum Streit darüber, wessen Kopie stimmt.

// Was wir bauen würden

Ein elektronischer Frachtbrief auf einem privaten Register mit Zugangsberechtigung, in dem Verlader, Frachtführer und Empfänger je einen Knoten betreiben, sodass Abholung, Übergaben und die unterschriebene Zustellung eine Aufzeichnung sind, die keiner allein ändern kann. Betreibt eine Firma das System schon und alle vertrauen ihr, schafft eine gemeinsame Datenbank dasselbe günstiger, und wir sagen Ihnen das.

// Was drin ist

// Tech-Stack

• Next.js
• Hyperledger Fabric (privat, mit Zugangsberechtigung)
• PostgreSQL
• S3-kompatibler Speicher
• AWS

// Das Problem

Ein Frachtvermittler bietet selbstfahrenden Unternehmern Ladungen per SMS an, die erste Antwort gewinnt, und später kann niemand sehen, wem wann welche Ladung angeboten wurde.

// Was wir bauen würden

Ein Telegram-Bot, der Ladungen an zugelassene Unternehmer postet, die erste bestätigte Annahme nimmt, die Frachtbestätigung schickt und bei der Zustellung um Fotos bittet, mit einer kleinen Verwaltungsmaske für den Vermittler.

// Was drin ist

// Tech-Stack

• Telegram Bot API
• Node.js
• PostgreSQL
• DigitalOcean

// Das Problem

Verlader und Marktplätze fragen per E-Mail und Telefon nach dem Stand, und jeder große Kunde will einen Datenstrom in seinem eigenen Format.

// Was wir bauen würden

Eine Partner-API, die jedem Verlader Schlüssel, eine Testumgebung und dieselben Sendungs-, Status- und Zustelldaten gibt, die Ihr Team sieht, mit Webhooks, wenn sich eine Ladung bewegt. Ein Entwicklerportal und zwei SDKs lassen die Entwickler eines Verladers ohne Gespräch anbinden.

// Was drin ist

// Tech-Stack

• OpenAPI 3.1
• TypeScript auf Node.js
• PostgreSQL
• Redis
• TMS- und ELD-APIs
• DigitalOcean

// Das Problem

Ein Frachtführer kalkuliert Relationen aus dem Gedächtnis und mit ein paar Tabellen, ohne zu wissen, welche Relationen und Kunden ihre Kosten wirklich decken, wenn Leerkilometer, Kraftstoff und Standzeiten gezählt werden.

// Was wir bauen würden

Ein Analysespeicher, der Ladungen, Kraftstoff, Fahrerlohn und Telematik jede Nacht zusammenführt und Kosten pro Kilometer nach Relation und Kunde mit Leerkilometern und Standzeiten, Pünktlichkeit nach Verlader und die Relationen mit dauerhaft dünner Marge zeigt.

// Was drin ist

// Tech-Stack

• Next.js
• PostgreSQL
• dbt
• Metabase
• DigitalOcean