Was der Starter-Review für 420 € abdeckt

Du hast eine App gebaut und bist an einem Punkt angekommen, an dem du technische Unterstützung brauchst. Ein großes Entwicklungsangebot wirkt vielleicht verfrüht. Ein automatischer Scan liefert womöglich viele Warnungen, erklärt aber nicht, was für dein Vorhaben wichtig ist. Ein kostenloses Gespräch klärt die Zusammenarbeit, ersetzt jedoch keine Prüfung der Anwendung. Ein Starter-Review ist ein kleiner, klar abgegrenzter erster Auftrag.

Der Starter-Review von Launch a Tool kostet 420 € zuzüglich anwendbarer Umsatzsteuer und umfasst bis zu vier technische Arbeitsstunden insgesamt für eine App. Dazu gehören Prüfung, schriftliche Ergebnisse und Besprechung. Gemeint sind nicht vier Stunden Codeprüfung plus unbegrenzte Dokumentation und Gespräche. Korrekturen, Bereitstellung und Hosting werden separat vereinbart. Eignung und Termin klären wir vor der Beauftragung.

Welche Entscheidung soll der Review ermöglichen?

Eine hilfreiche Prüfung beginnt mit einer Entscheidung. Vielleicht möchtest du wissen, ob einige Kollegen einen kontrollierten Test starten können. Vielleicht gibt es Zweifel an den Zugriffsrechten. Oder du willst klären, was vor einem Wechsel aus einer Bauplattform auf eine andere Infrastruktur notwendig ist. Beschreibe deinen nächsten geplanten Schritt und die Unsicherheit, die dich davon abhält.

Dieselbe App kann je nach Nutzung andere Arbeit erfordern. Eine Vorführung mit Beispieldaten unterscheidet sich von einem Tool mit Mitarbeiterdaten oder Ausgabenfreigaben. Eine Anwendung für die eigene Nutzung unterscheidet sich von einer Lösung für mehrere Kunden. Dieser Kontext hilft, die wichtigsten Abläufe für den Review auszuwählen.

Wir vereinbaren deshalb zunächst Anwendung, Fragen und verfügbare Unterlagen. Gegebenenfalls empfehlen wir einen engeren Umfang oder eine tiefere Prüfung. So vermeiden wir, dass hinter einem kleinen Auftrag Erwartungen stehen, die sich in der vorgesehenen Zeit nicht erfüllen lassen.

Was du vorbereiten kannst

Hilfreich sind eine kurze Ablaufbeschreibung, die vorgesehenen Nutzer, die aktuelle Betriebsumgebung und dein wichtigstes Anliegen. Ein öffentlicher Demo-Link kann das Erstgespräch unterstützen. Sende keine Passwörter oder vertraulichen Kundendaten über das öffentliche Formular. Nach einer Beauftragung vereinbaren wir einen geeigneten Zugang zu Code und Testumgebung.

Wenn möglich, stelle nachvollziehbare Startanweisungen und künstliche Testkonten für verschiedene Rollen bereit. Beschreibe, welche Schnittstellen echte E-Mails versenden, externe Datensätze ändern oder Kosten auslösen. Eine aktive Zahlungsanbindung sollte nicht erst durch versehentliche Nutzung auffallen. Für den Einstieg ist lesender Zugriff sinnvoll; weitergehende Rechte brauchen einen konkreten Zweck.

Falls sich die App nicht starten lässt, muss diese Einschränkung vorab bekannt sein. Statische Prüfung kann weiterhin nützliche Ergebnisse liefern, beweist aber kein Laufzeitverhalten. Das Beheben einer defekten Einrichtung beansprucht denselben Zeitrahmen wie die eigentliche Prüfung. Klare Startbedingungen verhindern Missverständnisse.

Wie die Prüfpunkte ausgewählt werden

Im Mittelpunkt stehen die vereinbarte Frage und die folgenreichsten Abläufe. Bei einem kleinen internen Tool können das Anmeldung, eine Rollengrenze, der wichtigste Schreibvorgang, eine externe Verbindung und die Betriebskonfiguration sein. Es handelt sich um eine begründete Auswahl, nicht um einen statistischen Nachweis für alle ähnlichen Stellen.

Geprüft werden kann beispielsweise, ob Geheimnisse im ausgelieferten Browsercode landen, ob der Server die Zugehörigkeit eines Datensatzes kontrolliert, ob Eingaben validiert werden oder ob Fehler zu falschen Erfolgsmeldungen führen. Hinzu kommen möglicherweise unklare Abhängigkeiten, fragile Abläufe oder fehlende Wiederherstellungsanweisungen.

Direkt nachgewiesene Probleme und offene Verdachtsmomente müssen unterscheidbar bleiben. „Ein Testkonto konnte einen fremden Antrag abrufen“ ist eine andere Aussage als „die Berechtigungsfunktion ist schwer nachvollziehbar“. Beides kann relevant sein. Der Bericht sollte deutlich machen, welche Evidenz vorliegt und was erst ein weiterer Test klären kann.

Was der Bericht dir ermöglichen soll

Die Ergebnisse sollen eine nächste Handlung ermöglichen. Eine wichtige Feststellung braucht den betroffenen Ablauf, nachvollziehbare Beobachtungen, mögliche Folgen und einen Vorschlag für das weitere Vorgehen. Eine ungefilterte Liste automatischer Warnungen reicht dafür nicht aus.

Du erhältst einen Überblick über den Umfang, priorisierte Ergebnisse, offene Fragen und eine Empfehlung zum nächsten Schritt. Auch nicht geprüfte Bereiche gehören dazu. Wenn nur eine Nutzerrolle verfügbar war oder eine Integration nicht sicher getestet werden konnte, muss diese Grenze unmittelbar bei der Schlussfolgerung stehen.

Prioritäten richten sich nach dem geplanten Einsatz. Ein Fehler bei der Trennung von Datensätzen kann einen gemeinsamen Test verhindern. Eine unklare, aber korrigierbare Fehlermeldung lässt sich möglicherweise später verbessern. Uneinheitliche Benennungen können Wartung erschweren, ohne unmittelbar den Start zu blockieren. Diese Unterscheidung hilft, Aufwand sinnvoll einzusetzen.

Die Besprechung gehört zum Zeitrahmen

In der gemeinsamen Besprechung verbinden wir Beobachtungen mit Entscheidungen. Wir erläutern die Nachweise, klären Begriffe und sprechen über den nächsten Arbeitsumfang. Danach solltest du wissen, welche Punkte vor der vorgesehenen Nutzung bearbeitet werden müssen, was warten kann und wo weitere Untersuchung nötig ist.

Der begrenzte Auftrag setzt eine konzentrierte Besprechung voraus. Er umfasst keine unbegrenzten Rückfragen, fortlaufenden Meetings oder offene Fehlersuche. Zusätzliche Unterstützung kann separat vereinbart werden. Gerade bei einem kleinen Auftrag schützt ein klarer Rahmen beide Seiten.

Du kannst die Ergebnisse selbst umsetzen, mit einem anderen Entwickler besprechen oder uns um ein Folgeangebot bitten. Der Bericht soll deine Entscheidung verbessern. Er soll nicht dazu führen, dass nur ein einziger Anbieter mit deiner Anwendung weiterarbeiten kann.

Was vier Stunden nicht nachweisen können

Der Starter-Review ist kein Penetrationstest, keine vollständige Codeprüfung, keine Compliance-Zertifizierung und keine Garantie gegen künftige Vorfälle. Er beweist nicht, dass jede Abhängigkeit sicher ist, jede Integration korrekt arbeitet oder sämtliche Berechtigungspfade getestet wurden. Er enthält auch nicht automatisch die Behebung aller gefundenen Probleme oder eine produktive Migration.

Große Codebestände, mehrere Anwendungen, komplexe Zahlungsabläufe, besonders sensible Daten oder schlecht dokumentierte Infrastruktur können einen anderen Umfang erfordern. Deshalb klären wir die Eignung vorher. Eine nachvollziehbare Grenze ist hilfreicher als eine pauschale Zusage, die sich in der verfügbaren Zeit nicht belegen lässt.

Auch eine Empfehlung für einen begrenzten Pilotbetrieb gilt genau für diesen Rahmen. Neue Rollen, zusätzliche Integrationen und andere Datenarten können die Einschätzung ändern. Ein Review beschreibt einen bestimmten Stand zu einem bestimmten Zeitpunkt. Er ist kein dauerhaftes Gütesiegel.

Wie es anschließend weitergeht

Ein sinnvoller nächster Schritt kann ein kleines Korrekturpaket, eine vertiefte Untersuchung, eine kontrollierte Einführung oder auch eine Pause sein. Eine Neuentwicklung sollte sich aus den Ergebnissen begründen. Die bloße Tatsache, dass KI beim Schreiben geholfen hat, reicht dafür nicht.

Für Folgearbeiten solltest du ein separates Angebot mit Leistungen, Annahmen, Zuständigkeiten und Kosten erhalten. Hosting und Wartung müssen erkennbar sein und dürfen nicht unsichtbar im Begriff „Launch“ verschwinden. Einmalige Entwicklungsarbeit und laufender Betrieb sind unterschiedliche Leistungen.

Wenn du unsicher bist, ob der Starter-Review passt, beginne mit dem kostenlosen 30-minütigen Erstgespräch. Erkläre, was du gebaut hast und welche Entscheidung ansteht. Der erste sinnvolle Fortschritt besteht darin, die richtige Frage für die Prüfung festzulegen.

Quellen und Einordnung

• OWASP Application Security Verification Standard — Referenz für technische Anforderungen, keine Zusage vollständiger Abdeckung durch dieses Paket.
• Beispiel eines Starter-Review-Berichts — eine Illustration des Ergebnisses, kein Kundenbericht und kein Nachweis gemessener Kundenerfolge.