Proven Build Base

Ein laufendes Produkt, kein Starter Kit

Die meiste Individualsoftware wird aus einem leeren Ordner heraus angeboten, und damit werden die Fundamente in jedem Projekt neu bezahlt. Masken werden aus dem Nichts entworfen, über die Navigation wird gestritten, und das Sign-In löst zum ersten Mal jemand, der es zum ersten Mal löst.

Ein Build startet hier von einem Produkt, das täglich im Einsatz ist und die eigenen Leistungsnachweise und die eigene Verrechnung dieser Praxis trägt. Struktur, Aufbau der Masken und Navigation sind die Specification, und was pro Kunde wechselt, sind das Erscheinungsbild und die Branche darunter.

Deshalb steht die Form Ihrer Anwendung in der ersten Woche fest, statt im dritten Monat entdeckt zu werden.

Die Woche, die Sie nicht verlieren

Ein Popup-Sign-In-Flow in einer modernen Angular-Anwendung kann hängen bleiben, das Popup offen und das Hauptfenster weiter auf dem Login-Screen, weil das Popup den ursprünglichen Token Request im eigenen Storage sucht und der Request im Hauptfenster liegt.

Diagnostiziert wurde das hier einmal. Jeder Build seither kommt mit dem bereits gewählten Redirect Flow, niemand verbringt die Woche noch einmal mit der Suche, und die Entscheidungsregel steht in den Conventions, die das nächste Projekt liest, bevor es eine Zeile schreibt.

Das ist ein Beispiel für dasselbe Muster: Ein hart erarbeiteter Fix wird zum Default, und Defaults stehen auf keiner Rechnung.

Sie zahlen für Ihre Anwendung

Zwei Anwendungen kamen unabhängig voneinander in je rund drei Wochen vom leeren Repository in Production, beide mit Logins, automatisierten Tests, einem Release-Weg und einer Produktivdatenbank.

Möglich ist das nur, weil das meiste von dem, was sie brauchten, nicht noch einmal gebaut wurde. Gebaut wurde der Teil, der wirklich ihrer war: die Regeln der Branche, die geführten Daten, die Begriffe und die Masken, die die Leute jeden Morgen öffnen.

Ihr Angebot deckt genau diesen Teil. Der Unterbau darunter wurde einmal bezahlt, von uns, am eigenen Geschäft, bevor irgendetwas davon einem Kunden angeboten wurde.

Das ist der Unterschied zwischen einem Angebot, das erst herausfinden muss, wie Software dieser Art funktionieren soll, und einem, das nur abdecken muss, was Ihre Branche wirklich von ihr braucht.

3 Wochen

vom leeren Repository bis in Production, zweimal, Logins und Tests inklusive

Sign-In-Defekt, hier einmal diagnostiziert und seither von jedem Build geerbt

Mail-Anbieter kommen dazu: Nachrichten gehen über den Tenant, den Sie ohnehin besitzen

Angular 22

mit Signal Store, auf ASP.NET Core 10 und SQL Server

Was bereits gebaut ist, bevor Ihr Projekt beginnt

Woraus ein Build startet 2 Schritte

Starten Sie von einem Produkt, das läuft, nicht von einem Template

Ein Starter Template ist eine Vermutung darüber, was ein Projekt brauchen wird. Ein Build startet hier von einem Produkt, das täglich im Einsatz ist: dem, in dem diese Praxis ihre eigenen Bücher führt. Jede Entscheidung darin hat jemand geprüft, der mit ihr leben muss. Nichts daran ist theoretisch, denn wer jeden Fehler zuerst zu spüren bekam, waren wir.

Behandeln Sie den laufenden Build als Specification

Übernehmen Sie Struktur, Aufbau der Masken und Navigation des erprobten Builds und ändern Sie nur, was sich wirklich unterscheidet: das Erscheinungsbild, die Sprache der Branche und die Daten, die das Unternehmen tatsächlich führt. Damit wird der riskanteste Teil eines Projekts, nämlich zu entscheiden, wie die Sache geschnitten sein soll, zu einer Entscheidung, die längst getroffen ist und den Kontakt mit echtem Betrieb überstanden hat.

Was bereits gelöst ist 3 Schritte

Sign-In steht fest, bevor die erste Maske entsteht

An der Authentication verlieren Individualprojekte ihren ersten Monat. Die Basis kommt mit Directory Sign-In über Microsoft Entra ID im Front End und Audience Validation in der API, dazu ein lokaler Kontopfad mit Rollen aus der Datenbank. So erreicht ein Konto außerhalb des Directory dasselbe Niveau, ohne dass ein zweites Identity System dazukommt.

Der Release-Weg kommt mit der Software

Ab dem ersten Deploy laufen zwei Slots pro Anwendung: einer bedient die Nutzer, der andere trägt die Kandidatenversion. Die Promotion vergibt dem bereits getesteten Image nur ein neues Tag, statt es neu zu bauen, und damit erreicht genau das Artefakt Production, das die Tests bestanden hat. Ein Rollback ist ein Schritt auf einem unveränderlichen Tag statt eines Notfall-Rebuilds zur denkbar schlechtesten Stunde.

Ausgehende Mail läuft über den Tenant, den Sie schon besitzen

Ein Mail-Anbieter, den ein einziges Kontaktformular nach sich zieht, bedeutet ein weiteres Konto, eine weitere Rechnung und eine weitere Stelle, an der die Zustellung scheitern kann. Bestätigungen, Benachrichtigungen und Formulareingänge gehen über Microsoft Graph an ein Postfach in Ihrem eigenen Microsoft 365 Tenant, mit Application Permission und Admin Consent. So tragen die Nachrichten die echte Reputation Ihrer Domain, und es liegen nirgendwo eigene Mail-Zugangsdaten.

Der Fix, den Sie erben 2 Schritte

Der Sign-In-Fehler, beim Namen genannt statt angedeutet

Ein Popup-Sign-In-Flow in einer modernen Angular-Anwendung kann hängen bleiben: Das Popup steht offen, und das Hauptfenster zeigt weiter den Login-Screen. Die Ursache: Das Popup lädt die Anwendung, will den Austausch abschließen und findet den ursprünglichen Token Request im Storage des Hauptfensters statt im eigenen. Der Fix ist, durchgehend den Redirect Flow zu verwenden.

Ein einmal gelöstes Problem wird kein zweites Mal gelöst

Ein Fix, der nur im Kopf eines Entwicklers lebt, wird im nächsten Projekt zum vollen Preis noch einmal gefunden. Jeder davon geht in die Conventions, die der nächste Build liest, bevor er startet: Symptom, Ursache und Entscheidungsregel beisammen. So geht derselbe Nachmittag kein zweites Mal drauf. Stunden, die nicht in neu gelegte Fundamente fließen, landen auf keiner Rechnung.

Was wirklich Ihres ist 2 Schritte

Was wirklich neu ist, gehört wirklich Ihnen

Von null gebaut wird der Teil, den niemand sonst für Sie hätte bauen können: die Regeln Ihrer Branche, die Daten, die Sie führen, die Worte, die Ihre Leute benutzen, und die Masken, die sie jeden Morgen öffnen. Dorthin geht das Budget, und nur an dieser Stelle ist der Start bei null die richtige Antwort und keine Ausgabe.

Es läuft hier, bevor es Ihnen angeboten wird

Jeder Teil der Basis, den diese Seite beschreibt, läuft in Production im eigenen Geschäft dieser Praxis und trägt dort die eigenen Leistungsnachweise, die eigene Verrechnung und das eigene Sign-In. Das ist der Beweis, der vorliegt, bevor ein Kunde irgendetwas bezahlt: keine Demo-Umgebung, die für einen Termin zusammengestellt wurde, sondern Software, deren Fehler zuerst bei uns landen.

Häufige Fragen

Was genau ist schon gebaut, wenn ein Projekt startet?

Die Teile, die jede Geschäftsanwendung braucht und keine davon zweimal bezahlen will: Directory- und lokales Sign-In mit Rollen, Aufbau der Masken und Navigation, ein Release-Weg mit zwei Slots und Rollback in einem Schritt, End-to-End-Tests und ausgehende Mail über Ihren eigenen Microsoft 365 Tenant. Darauf sitzen ein Angular Front End mit Signal Store, eine ASP.NET Core API und SQL Server.

Heißt das, wir bekommen dieselbe Software wie alle anderen?

Nein. Geteilt wird der Unterbau, nicht das Produkt. Struktur, Aufbau der Masken und Navigation werden geerbt, und alles, was ein Benutzer als Ihres erkennen würde, nicht: das Erscheinungsbild, die Regeln Ihrer Branche, die Daten, die Sie führen, die Begriffe Ihrer Leute und die Masken, die sie tatsächlich öffnen. Die Basis entscheidet, wie gebaut wird, nie was die Anwendung tut.

Was war das Sign-In-Problem, in einfachen Worten?

Ein Popup-basiertes Sign-In bleibt hängen: Das Popup schließt die Authentifizierung ab, bleibt aber offen, und das Hauptfenster kommt nie vom Login-Screen weg. Das Popup sucht den ursprünglichen Token Request in seinem eigenen Storage, und der Request liegt im Storage des Hauptfensters. Stellt man die ganze Anwendung auf den Redirect Flow um, tritt das nicht auf, und jeder Build seither startet so.

Können wir das auf unserer eigenen Infrastruktur betreiben?

Dafür ist es gebaut, und so steht es heute. Die Anwendung ist in Dateien beschrieben und wechselt den Host als Konfigurationsänderung, und die Serveradministration lässt sich übergeben, mit Datenbankzugriff, der auf Ihre eigenen Daten geschnitten ist. Beide Instanzen laufen in Production auf der eigenen Infrastruktur dieser Praxis: Diese Portabilität ist damit eine Design-Eigenschaft und nichts, was eine Lieferung bereits bewiesen hat.