Vorab gerechnet

B2B-Kundenportal mit Livestatus

Kunden geben Bestellungen selbst auf und verfolgen den Lieferstatus live; Login über Azure AD, Warenwirtschaft per REST.

Gerechnet am 11.09.2026 um 22:18 Uhr

Ihr erster Prototyp · Festpreis netto
6.430
Prototyp Aufwand 58,5 / 100 · ca. 5 Wochen

So haben wir Sie verstanden

Ein Kundenportal für Selbstbestellung mit Live-Lieferstatus, Azure-AD-Login und Anbindung an bestehende Warenwirtschaft per REST.

Was der Prototyp enthält

Ein Kunde meldet sich per Azure AD an, gibt eine Bestellung auf und sieht deren Status live, Warenwirtschaftsdaten real per REST.

Aufwands-Meter — 100 heißt maximaler Aufwand und maximaler Preis, keine Note.

Echtzeit, Login-Fremdsystem und Altsystem-Schnittstelle summieren sich, auch wenn der Kernfall schmal ist

Danach: Vollausbau

Vollausbau ab 78.000 € · indikativ bis 101.500 € · 6 Wochen · Team aus 3

Komponenten

  • Azure-AD-Login2,5 PT
  • Bestellstrecke (Katalog, Warenkorb, Bestellung)5,75 PT
  • Live-Lieferstatus (Echtzeit)3,75 PT
  • REST-Anbindung Warenwirtschaft5 PT
  • Projektsteuerung & Tests3 PT

Besetzung

  • Lead Developer (Lead .NET-Entwickler)
  • Senior Developer (Senior .NET-Entwickler)
  • Exceptional Architect (Systemintegration)

Annahmen hinter dem Preis

  • Azure AD ist bereits eingerichtet und liefert nutzbare Tokens
  • Die Warenwirtschaft bietet eine dokumentierte REST-Schnittstelle
  • Es genügt zunächst ein Bestell- und Statusfluss ohne Sonderfälle

Was wir zu Beginn klären

  • Welches Warenwirtschaftssystem wird angebunden und wie sieht dessen API aus?
  • Woher kommen die Statusänderungen — Push vom Altsystem oder Abfrage?

Der Fahrplan — was in welcher Woche fertig ist

0
0
0
0
0
  1. Woche 1 Kickoff Abstimmung, Zugänge, Feinschnitt des Umfangs
  2. Woche 2 Azure-AD-Login 2,5 PT
  3. Woche 3 Bestellstrecke (Katalog, Warenkorb, Bestellung) 5,75 PT
  4. Woche 3 Live-Lieferstatus (Echtzeit) 3,75 PT
  5. Woche 4 REST-Anbindung Warenwirtschaft 5 PT
  6. Woche 4 Projektsteuerung & Tests 3 PT
  7. Woche 5 Abnahme Übergabe nach Abnahme und Restzahlung

Verstärkung: Köpfe auf Abschnitte legen

  • 1 Woche früher, Abnahme in Woche 4 statt 5: „REST-Anbindung Warenwirtschaft“ +1 Senior Developer (Senior .NET-Entwickler), „Projektsteuerung & Tests“ +1 Tester · +130 €
  • 2 Wochen früher, Abnahme in Woche 3 statt 5: „Azure-AD-Login“ +1 Senior Developer (Senior .NET-Entwickler), „Bestellstrecke (Katalog, Warenkorb, Bestellung)“ +1 Senior Developer (Senior .NET-Entwickler), „Live-Lieferstatus (Echtzeit)“ +1 Senior Developer (Senior .NET-Entwickler), „REST-Anbindung Warenwirtschaft“ +1 Senior Developer (Senior .NET-Entwickler), „Projektsteuerung & Tests“ +1 Tester · +320 € hilft am meisten

Legen Sie Köpfe auf die Abschnitte, die schneller fertig werden sollen: dieselben Stunden, mehr Köpfe, weniger Wochen — wie bei den Tempopaketen, ein Kopf mehr +5 %, zwei +8 %, drei +10 %, vier +12 % auf den Anteil des Abschnitts am MVP-Festpreis. Entwickler kommen nicht auf Abschnitte, die andere zusammenführen, und nicht auf, was erst im letzten Drittel beginnt — dort macht ein weiterer Entwickler ein Projekt langsamer. Auf den letzten Abschnitt vor der Abnahme legen Sie stattdessen Tester. Wer die Köpfe sind, wählen wir.

Lastenheft und Pflichtenheft

Ziel Kunden können eigenständig bestellen und den Lieferstatus in Echtzeit verfolgen.

Lösungsweg Ein ASP.NET-Core-Portal mit Azure-AD-Authentifizierung, Bestellstrecke und SignalR-gestütztem Live-Status, das Bestell- und Statusdaten über REST mit der Warenwirtschaft synchronisiert.

  1. Was gefordert istKunden müssen sich per Azure AD anmelden können
    Wie wir es umsetzenAnbindung an Azure AD über Standard-Authentifizierungsmechanismen von ASP.NET Core
  2. Was gefordert istKunden müssen Bestellungen selbst aufgeben können
    Wie wir es umsetzenRazor-basierte Bestellstrecke mit Anlage und Übergabe der Bestellung an die Warenwirtschaft
  3. Was gefordert istKunden müssen den Lieferstatus live verfolgen können
    Wie wir es umsetzenSignalR-Verbindung, die Statusänderungen der Warenwirtschaft in Echtzeit an den Kunden schiebt
  4. Was gefordert istDas System muss Bestell- und Statusdaten mit der Warenwirtschaft per REST austauschen
    Wie wir es umsetzenREST-Client/-Endpunkt zum bidirektionalen Datenaustausch mit der Warenwirtschaft

Rahmenbedingungen

  • Nutzerkreis: bestehende Kunden mit Azure-AD-Konten
  • Anbindung an eine bestehende Warenwirtschaft

Nicht im Umfang

  • Keine Zahlungsabwicklung
  • Keine Lagerverwaltung im neuen System
  • Keine mobile App
  • Keine Änderungen an der Warenwirtschaft selbst

Woran Sie die Abnahme messen

  • Ein Testkunde kann sich per Azure AD anmelden und eine Bestellung abschließen
  • Statusänderung in der Warenwirtschaft erscheint innerhalb von 5 Sekunden im Portal
  • Bestelldaten werden korrekt per REST an die Warenwirtschaft übertragen
  • Alle Kernabläufe sind mit automatisierten Tests abgedeckt

Meilensteine

  • Woche 2: Azure-AD-Login
  • Woche 3: Bestellstrecke (Katalog, Warenkorb, Bestellung)
  • Woche 3: Live-Lieferstatus (Echtzeit)
  • Woche 4: REST-Anbindung Warenwirtschaft
  • Woche 4: Projektsteuerung & Tests
  • Woche 5: Abnahme

Technologien, die wir einsetzen

  • ASP.NET Core MVC & Razor Pages
  • SignalR & WebSockets
  • Minimal APIs & REST / Web API
  • Entity Framework Core & Dapper
  • SQL Server 2025
  • Blazor
  • OAuth2 / OpenID Connect & ASP.NET Core Identity
  • GraphQL (HotChocolate)
  • Tailwind CSS & Barrierefreiheit
  • ASP.NET Core MVCTrägt Bestellformulare, Login-Anbindung und REST-Endpunkte
  • Razor ViewsServerseitig gerenderte Oberfläche für Bestellung und Statusanzeige
  • SignalRSchiebt Lieferstatusänderungen live an den angemeldeten Kunden
  • REST-Schnittstelle (JSON)Austausch von Bestell- und Statusdaten mit der Warenwirtschaft
  • EF Core 10Datenzugriff auf Bestellungen und Statusverlauf in SQL Server
  • SQL ServerSpeicherung von Bestellungen, Kunden- und Statusdaten
  • BlazorBestellmasken und Lieferstatus ohne Neuladen
  • OAuth2 / OpenID Connect & ASP.NET Core IdentityAnmeldung der Kunden über ihr Azure AD
  • Minimal APIs & REST / Web APISchnittstellen zur Warenwirtschaft für Artikel, Preise und Status
  • GraphQL (HotChocolate)Eine Abfrage je Portalansicht statt vieler Einzelaufrufe
  • Tailwind CSS & BarrierefreiheitOberfläche des Portals, bedienbar auch per Tastatur und Vorleser

← Zurück zum Portfolio