Standortbestimmung für Ihren Prototyp

Sie haben etwas gebaut, es funktioniert, und jetzt steht die Frage im Raum, ob es an echte Nutzer gehen kann. Beantworten kann sie im Haus niemand mit Sicherheit.

Wir sehen uns gemeinsam an, was da entstanden ist. Am Ende wissen Sie, was trägt, was nachgezogen werden sollte und was besser neu gebaut wird.

Ein halber Tag gemeinsam, remote oder vor Ort in Hamburg. Auf Wunsch bei Ihnen.

EUR 1.200, inklusive Vorbereitung und schriftlicher Auswertung.

Termin vereinbaren

Ein Kunde hatte über mehrere Wochen eine Anwendung gebaut, Feature für Feature, und jedes einzelne davon funktionierte. Was fehlte, war eine Entscheidung darüber, wie das Ganze aufgebaut sein sollte, bevor das erste Feature entstand.

Kein Framework, keine erkennbaren Konventionen, jede Funktion einzeln entwickelt, ohne zu prüfen, ob es dafür längst eine etablierte Bibliothek gibt. Jede Iteration hat gelöst, was gerade anlag, und dabei die Struktur weiter verschoben. Das geht eine Weile gut, weil das Modell auf jede Anfrage etwas Lauffähiges liefert. Nach einigen Wochen war eine Codebasis entstanden, die sich in angemessener Zeit weder lesen noch sinnvoll reviewen ließ, und ohne Tests ließ sich auch nicht feststellen, was eine Änderung an anderer Stelle kaputt macht.

Sicherheitsthemen kommen dazu. Ein Kunde hatte eine Anwendung mit Microsoft 365 Anbindung entwickelt. Anstatt einer eigenen in Microsoft Entra registrierten Anwendung griff er auf die Exchange Online API mit seinem Exchange-Admin-Account via Delegated Access zu. Damit hatte die Anwendung Zugriff auf sämtliche Postfächer der Organisation, ohne eingeschränkten Scope und ohne Trennung zwischen Lesen und Schreiben. Ein Fehler im Code hätte Inhalte verschieben oder löschen können, ohne dass es aufgefallen wäre. Dazu verarbeitet die Anwendung eingehende Nachrichten und reicht deren Inhalt an ein Sprachmodell weiter. Eine präparierte Mail, die Anweisungen enthält, passiert die Schutzmechanismen von Exchange, weil sie technisch kein Angriff ist, sondern erst im Modell als Anweisung wirkt.

Häufiger als solche Funde sind die unauffälligen Dinge, die sich erst im Betrieb zeigen. 

• API-Keys im Frontend, 
• Berechtigungen, die es nur in der Oberfläche gibt, 
• ein Datenmodell und eine Datenbank ohne Migrationsdateien (Stichwort: fehlende Datenintegrität),
• Logging, das personenbezogene Daten wegschreibt. 

Was dabei typischerweise auftaucht und wie Sie es selbst prüfen können, haben wir gesondert beschrieben. Zum Blogpost

Keiner dieser Punkte ist ein Argument gegen den Prototypen, sondern ein Argument dagegen, ihn ohne Prüfung an echte Nutzer zu geben.

Vorab brauchen wir Zugriff auf den Code, als ZIP-Datei übermittelt oder durch Zugriff auf das Repository, und eine kurze Beschreibung dessen, was die Anwendung tun soll. Beides sehen wir uns im Vorfeld in Ruhe an. Wir gehen den Code durch, bevor wir zusammensitzen, damit die gemeinsame Zeit nicht mit Orientierung vergeht.

Am Termin selbst gehen wir die Funde mit Ihnen durch. Wie Authentifizierung und Berechtigungen umgesetzt sind, wo Secrets liegen, wie das Datenmodell aufgebaut ist und ob es sich ändern lässt, was die Anwendung an angebundenen Systemen darf, was protokolliert wird und was an Tests existiert. Zu jedem Punkt besprechen wir, was er praktisch bedeutet, wie er sich beheben lässt und was das kosten würde. Für Ihre Fragen ist dabei genug Zeit, das ist der eigentliche Sinn des Termins.

Zum Abschluss ordnen wir das Gefundene ein. Was zuerst behoben werden sollte, was danach noch Zeit hat, und was sich sinnvoll nicht mehr reparieren lässt. Diese Reihenfolge hängt davon ab, wohin Sie wollen. Wenn ein Go-Live ansteht, sieht die Priorisierung anders aus, als wenn Sie zunächst weiterentwickeln und die Entscheidung über den Betrieb noch offen ist. Manches, was vor einem Go-Live zwingend ist, kann warten. Anderes, etwa das Datenmodell, sollte geklärt sein, bevor die nächsten Features darauf aufsetzen. Die schriftliche Auswertung erstellen wir im Nachgang und schicken sie Ihnen zu.

Genau das ist die Frage, die Sie danach beantworten können. Sie bekommen eine schriftliche Aufstellung der Funde, jeweils mit der praktischen Bedeutung und einer Aufwandseinschätzung für die Behebung.

Dazu eine klare Antwort auf die Frage, mit der Sie gekommen sind, also ob der Prototyp tragfähig ist, sich mit überschaubarem Aufwand nachziehen lässt oder besser neu aufgesetzt wird. Wenn Ihr Prototyp weitgehend in Ordnung ist, sagen wir Ihnen das genauso deutlich, und Sie haben einen halben Tag investiert, um mit dieser Gewissheit weiterzuarbeiten.

Die Person, die den Prototypen gebaut hat, sollte dabei sein. Ob das ein Entwickler ist, der Gründer oder jemand aus der Fachabteilung, spielt keine Rolle. Wichtig ist, dass jemand im Raum ist, der erklären kann, warum die Dinge so gelöst sind, wie sie gelöst sind.

Hilfreich ist es, wenn zusätzlich jemand teilnimmt, der über das weitere Vorgehen entscheidet. Dann muss niemand die Erkenntnisse aus dem Termin später aus zweiter Hand weitergeben.

Je nach Anwendung ein Lead Developer mit Architekturschwerpunkt, ein Entwickler mit langjährigem Hintergrund im Requirements Engineering, oder einer unserer Geschäftsführer, der seit Jahren digitale Geschäftsmodelle aufbaut und verkauft. Alle drei arbeiten täglich mit KI-gestützter Entwicklung und bauen selbst.

In vielen Fällen ist das Ergebnis eine Bestätigung. Sie wissen, woran Sie sind, kennen die Punkte, die noch offen sind, und gehen den Weg weiter, den Sie ohnehin vorhatten.

Wenn Sie den Prototypen nachziehen oder neu aufsetzen möchten und die Kapazität dafür im Haus knapp ist, unterstützen wir Sie dabei gern. Das ist aber keine Entscheidung, die an diesem halben Tag ansteht. Der Termin hat seinen Zweck erfüllt, wenn Sie danach wissen, wo Sie stehen.

Dann ist die Standortbestimmung nicht das passende Format. In solchen Fällen bieten wir Ihnen einen gemeinsamen KI Protoyping Workshop an. In unserem zweitägigen Workshop entsteht ein Prototyp mit einer Basis, auf der sich weiterbauen lässt. Hier

Gern vereinbaren wir ein unverbindliches Kennlerngespräch.

Schreiben Sie uns kurz, was Sie gebaut haben und was Sie daran beschäftigt. Wir melden uns mit einer Einschätzung, ob eine Standortbestimmung das richtige Format ist.

Termin vereinbaren