Die Fragen, die vor der Anmeldung im Weg stehen

Eine Plattform, die das Entwickeln mit KI kontrollierbar und skalierbar macht. Kontrollierbar für dich allein, skalierbar, sobald mehrere Leute an derselben Sache arbeiten.

Praktisch besteht sie aus einem Board, auf dem deine Anforderungen liegen, und einer Anbindung an deinen Programmier-Assistenten. Das Board gibt vor, welcher Schritt als Nächstes dran ist und was dafür bekannt sein muss. Dein Assistent führt ihn aus.

Du kannst denselben Weg zweimal gehen. Ein Assistent allein liefert bei derselben Aufgabe zweimal ein anderes Vorgehen, weil jedes Gespräch bei null anfängt und du jedes Mal neu erklärst, wie dieses Projekt funktioniert. Artifacture hält diese Erklärungen fest und führt sie der jeweiligen Aufgabe zu.

Der Unterschied fällt nicht bei der ersten Anforderung auf, sondern bei der dreißigsten.

Es sieht so aus und arbeitet anders. Ein Projektmanagement-Werkzeug verwaltet Aufgaben, die anderswo erledigt werden.

Der Unterschied steckt in den Spalten. Wo bei einem gewöhnlichen Board Todo oder Bereit zur Umsetzung steht, liegt bei uns ein Workflow dahinter: Jede Spalte ist mit einer Anweisung verknüpft, die das Modell steuert, sobald ein Item dort ankommt. Das Item sagt, worum es geht. Die Spalte sagt, was damit jetzt zu tun ist.

Das ist, genau genommen, unsere größte Besonderheit.

Nein. Den Code schreibt dein Assistent, so wie bisher. Artifacture bestimmt, was er wann tut und mit welchem Wissen.

Für Leute, die mit KI entwickeln und dabei nicht bei „Assistent aufmachen und drauflosprompten" stehenbleiben wollen. Du musst kein Entwickler sein, aber du solltest ein Projekt haben, das in einem Git-Repository liegt, und beurteilen können, ob eine Beschreibung das trifft, was du gemeint hast.

Für einzelne Personen genauso wie für Teams, die gerade herausfinden, wie sie KI sinnvoll in ihre Entwicklung bekommen.

Für alle, die eine fertige Anwendung erwarten, ohne ein Repository anzufassen. Wir arbeiten daran, aber heute ist es nicht so.

Am Anfang stand eine kleine Sache: ein interaktives Artefakt aus einem Chat — ein Rechner mit ein paar Reglern — und die Frage, wie daraus eine echte Anwendung wird, mit Datenbank und Anmeldung statt Speicher im Browser. Für einen Entwickler ist das eine halbe Stunde Arbeit. Wer nie entwickelt hat, weiß nicht einmal, was er verlangen müsste.

Aus dieser Lücke ist die Plattform entstanden, und der Name ist geblieben.

Die Dinexis GmbH aus Wiesloch. Wir bauen Artifacture, weil wir es selbst brauchen — unsere eigenen Projekte laufen seit Monaten darüber.

Der Unterschied liegt darin, was ein Zustand bedeutet. In einem klassischen Board ist eine Spalte eine Markierung: Sie sagt einem Menschen, wie weit etwas ist. Hier trägt jeder Zustand eine Anweisung, die deine Session bekommt, wenn sie das Item zieht — im Zustand Spec eine andere als im Zustand Implement.

Das Board verwaltet die Arbeit also nicht, es erteilt sie.

Der Kontext und die Reihenfolge. Beides musst du heute selbst herstellen: erklären, wie das Projekt aufgebaut ist, woran gerade gearbeitet wird, was letztes Mal entschieden wurde, und dann entscheiden, was der nächste sinnvolle Schritt ist. Das kostet Zeit, und weil es jedes Mal etwas anders ausfällt, fallen auch die Ergebnisse unterschiedlich aus.

Artifacture nimmt dir beides ab. Der Assistent bleibt derselbe.

Nein, es steuert ihn. Du arbeitest weiter in deiner gewohnten Umgebung.

Wahrscheinlich funktioniert er gut, und wir würden dich nicht überzeugen wollen, dass er schlecht ist. Zwei Dinge kann er trotzdem nicht.

Er lässt sich nicht weitergeben: Was du dir über Monate erarbeitet hast, steckt in deinem Kopf und in deinen Dateien. Ein neuer Kollege bekommt eine Erklärung und baut sich danach seine eigene Variante. Und er steuert sich nicht selbst — bei datei-basierten Ansätzen entscheidest immer noch du, welcher Schritt jetzt dran ist.

Artifacture legt beides in die Plattform: den Ablauf und die Entscheidung darüber, was als Nächstes kommt.

Dazu kommt etwas, das erst im Team weh tut. Ein Ablauf, der auf Entwicklerrechnern lebt, ist das Gegenteil von Transparenz — was dort passiert, sieht niemand sonst. Solange du allein arbeitest, ist das egal. Sobald jemand fachlich mitarbeitet und wissen will, was entschieden wurde und warum, gibt es nichts, worauf man zeigen könnte.

Es ist für einen anderen Zeitraum gebaut.

Lovable ist für die ersten 48 Stunden. Da ist es großartig, und wir würden niemandem davon abraten, so anzufangen. Artifacture ist für die nächsten 48 Monate.

Der Einstieg dauert bei uns länger, und du musst dich mehr damit befassen. Dafür kannst du auf dem Ergebnis weiterbauen, statt es später neu zu schreiben.

Weil am Anfang Entscheidungen festgehalten werden, die sonst implizit bleiben: welche Datenbank, wie Anmeldung funktioniert, wie das Projekt aufgebaut ist. Das kostet dich einmal ein Gespräch von zwanzig Minuten.

Der Nutzen zeigt sich später. Diese Entscheidungen schränken ein, was bei jeder folgenden Anforderung überhaupt passieren kann — und das ist der Grund, warum Ergebnisse vorhersehbar bleiben, wenn ein Projekt größer wird.

Ja, solange es in einem Git-Repository liegt. Der Bootstrap erkennt vorhandenen Code und leitet die Architekturentscheidungen aus dem ab, was schon gebaut ist.

Weil man ihn nicht befragen kann. Er ist chronologisch, nicht thematisch, und was vor drei Wochen entschieden wurde, findet man nur, wenn man weiß, wann man es gesucht hat. Vor allem lässt sich ein einzelnes Thema nicht wieder herauslösen — man kann das Modell nur erneut arbeiten lassen und hoffen.

Der Gegenentwurf steht im Projekt selbst: ein Chat, der auf das antwortet, was tatsächlich passiert ist. Was wurde letzte Woche fertig, wie wurde das umgesetzt, warum war diese Migration ein Problem und was hat der Kollege dazu geschrieben. Nicht weil ein Verlauf durchsucht wird, sondern weil Items, Spezifikationen, Anmerkungen und Gesprächsnotizen an einem Ort liegen und dieser Ort befragbar ist.

Kannst du, und für manche Vorhaben ist das die richtige Entscheidung. Der Unterschied ist, was danach ist: Wer beauftragt, bekommt ein Ergebnis und braucht für jede Änderung wieder jemanden. Hier kannst du es abgeben und danach selbst weitermachen — dieselbe Plattform, dasselbe Board.

Du legst ein Item an und beschreibst fachlich, was entstehen soll. Das Item durchläuft die Zustände des gewählten Workflows. In den Zuständen, die eine Maschine bearbeitet, zieht deine Session die Arbeit und bekommt die dazugehörige Anweisung. In den Zuständen, die du bearbeitest, wartet das Item auf dich.

Ausführlich steht das in den Ersten Schritten.

Festgehaltene Antworten auf die Fragen, die man in einem Projekt genau einmal beantwortet: welche Datenbank, wie Anmeldung funktioniert, ob Daten mehrerer Kunden getrennt werden, wohin veröffentlicht wird. Jede steht einzeln, mit dem Grund dahinter, und sie gilt verbindlich.

Der Nutzen liegt nicht in der Dokumentation. Er liegt darin, dass jede dieser Entscheidungen den Raum verkleinert, in dem sich das Modell bewegt. Es entscheidet nicht mehr, wie gebaut wird — es füllt aus. Das ist der Grund, warum Ergebnisse vorhersehbar bleiben, wenn ein Projekt wächst.

Und es ist der Grund, warum sich jemand Fremdes in Minuten einarbeiten kann: Er liest die Entscheidungen, nicht den Code.

Aus zwei Richtungen.

Beim Bootstrap entsteht der Grundstock aus deinen Antworten auf strukturelle Fragen. Bei einem bestehenden Projekt wird er stattdessen aus dem abgeleitet, was schon gebaut ist.

Danach kommen sie aus der Arbeit. Fehlt für eine Anforderung eine Entscheidung — es soll etwas benachrichtigt werden, aber niemand hat je festgelegt, wie —, dann schreibt der Spec-Schritt keine Spezifikation, sondern fragt nach und schlägt vor, die Entscheidung festzuhalten. Erst danach geht es weiter.

Das ist der wichtigste Teil: Eine fehlende Entscheidung hält den Ablauf an, statt still improvisiert zu werden.

Du beschreibst das Fachliche — „es gibt einen Knopf, der aus dem Vorgang ein Dokument erzeugt". Was technisch dahintersteckt, kannst du festlegen, musst du aber nicht. Ein Workflow arbeitet die technischen Folgen deiner Anforderung aus und stellt Rückfragen, wo es fachlich mehrere Möglichkeiten gibt.

Diese Rückfragen sind der wertvollste Teil, weil sie Unklarheiten aufdecken, solange sie noch billig sind.

Nein, und der Verdacht ist berechtigt — das Wort ist vorbelastet. Gemeint ist üblicherweise ein Dokument, das über Monate wächst, vorab alles festlegen soll und schon veraltet ist, wenn die Umsetzung beginnt. Die Kritik daran ist verdient.

Bei uns ist eine Spezifikation etwas anderes: Sie gehört zu einem Item, entsteht in Minuten, gilt für diese eine Änderung und ist danach Vergangenheit. Nichts wächst, nichts wird gepflegt.

Was drinsteht, hat sieben Teile — welche Architekturentscheidungen gelten, welche Dateien betroffen sind, was sich an Schnittstellen und Datenmodell ändert, was schiefgehen kann, und woran man erkennt, dass es fertig ist.

Ein Teil davon ist technisch, mit Dateipfaden und Feldern. Zwei Teile sind es ausdrücklich nicht: Was kann schiefgehen und woran erkennen wir, dass es fertig ist. Genau die kann jemand fachlich beurteilen, ohne eine Zeile Code zu lesen — und genau dort liegen die Missverständnisse, die sonst teuer werden.

Deshalb ist die Freigabe auch keine technische Prüfung. Du beantwortest eine Frage: Ist das, was ich meinte?

Dein Assistent, in deiner Umgebung, mit deinem Zugang. Artifacture führt keine Modelle für dich aus.

Intern arbeiten wir bereits mit autonomen Arbeitern und daran, sie auch dir zur Verfügung zu stellen.

Du beschreibst, was du willst, und du gibst frei. Dazwischen übernimmt deine Session — und stellt dir dabei vielleicht ein paar Fragen.

Der wichtigste Punkt ist die Freigabe der Spezifikation. Du liest dort keine Implementierung, sondern die Beschreibung dessen, was gebaut werden soll, und prüfst genau eine Frage: Ist das, was ich meinte? Trifft es zu, stimmt erfahrungsgemäß auch das Ergebnis. Trifft es nicht zu, hast du eine falsche Umsetzung verhindert, bevor sie stattgefunden hat.

Dass weder du noch das Modell entscheiden, welcher Schritt als Nächstes kommt, sondern der Workflow. Das klingt nach einer Kleinigkeit und ist der eigentliche Unterschied — es nimmt dir den ständigen Erklärungsbedarf ab. Wenn eine Session anfängt, steht bereits fest, was zu tun ist und was dafür bekannt sein muss.

Ein Modell, das bei jeder Aufgabe die gesamte Projektgeschichte liest, arbeitet schlechter und teurer. Schlechter, weil Wichtiges zwischen Unwichtigem steht; teurer, weil alles davon bezahlt wird. Weil jeder Zustand seine eigene Anweisung trägt, bekommt die Session das für diesen Schritt Nötige und nicht mehr.

Ja. Die Arbeit läuft in deiner eigenen Session — du siehst sie, während sie passiert, und kannst jederzeit unterbrechen.

Sie geht zurück, und deine Anmerkung wird Teil ihres Kontextes. Die nächste Session liest sie mit.

Du wählst je Item den Workflow. Für Aufgaben, die keine Spezifikation brauchen, gibt es einen kurzen; für Aufgaben, bei denen du zweimal draufschauen willst, einen langen.

Git und Claude Code auf deinem Rechner, beides installiert und sonst nichts eingerichtet. Dazu ein Projekt, das in einem Git-Repository liegt oder liegen soll.

Programmieren musst du nicht. Du solltest dich aber in einem Projektordner zurechtfinden und beurteilen können, ob eine Anforderungsbeschreibung das trifft, was du gemeint hast.

Wer noch nie ein Repository angefasst hat, wird heute an der ersten Meile hängenbleiben. Das sagen wir lieber vorher als nach der Registrierung.

Ja — Git und Claude Code. Der Setup-Befehl prüft beides und öffnet eine Anleitung, wenn etwas fehlt. Artifacture selbst läuft im Browser, daran ist nichts zu betreiben.

Die Anbindung ist ein offener Standard und funktioniert mit allem, was MCP unterstützt. Der Ein-Befehl-Einstieg ist heute auf Claude Code zugeschnitten; mit einem anderen Assistenten richtest du den Arbeitsbaum von Hand ein.

Das Setup ist eine Sache von Minuten. Danach folgt ein Gespräch von etwa zwanzig Minuten, in dem die Grundentscheidungen für dein Projekt festgehalten werden. Ab da hängt es an deinem Vorhaben.

Du wirst gefragt, du entscheidest, du gibst frei. Wie viel das ist, bestimmst du über den Workflow: Wer jede Spezifikation und jedes Ergebnis prüfen will, ist häufiger dran als jemand, der nur am Ende draufschaut.

Du kannst wählen. Es funktioniert alles, womit ein Modell umgehen kann — und das ist praktisch jeder verbreitete Stack.

Wir haben nur für jede Frage eine Hausmeinung, und die greift, wenn es dir egal ist. Beim Bootstrap wirst du das Wichtige gefragt; wo du keine Präferenz hast, wird entschieden, statt dich in eine Diskussion zu ziehen. Der Standardweg ist heute TypeScript mit React, Postgres auf Neon und Railway zum Veröffentlichen.

Was du wählst, wird als Architekturentscheidung festgehalten und gilt danach — für dich und für jedes Modell, das an dem Projekt arbeitet. Der Vorteil kommt nicht daher, dass wir entschieden haben. Er kommt daher, dass überhaupt entschieden ist.

Alle auf demselben Board, im selben Kontext. Jeder hat einen eigenen Zugang, und die Anbindung liefert jedem die Arbeit, die ihm zugeordnet ist.

Ja. Verschiedene Rollen können auf demselben Board mit verschiedenen Workflows arbeiten. Wer bisher fachlich zuarbeitet, behält seine Arbeitsweise und bekommt einen Ablauf, der dazu passt.

In dem Umfang, in dem Anforderungen und Spezifikationen fachlich lesbar sind — und dafür sind sie gebaut. Ein vollständig nicht-technischer Arbeitsplatz ist das heute noch nicht; daran arbeiten wir.

Es bleibt. Architekturentscheidungen, Spezifikationen und die Vorgeschichte jedes Items liegen im Projekt, nicht in einem Kopf. Das ist der Unterschied zu einem selbstgebauten Ablauf.

Du fragst. Im Projekt gibt es einen Chat, der auf das antwortet, was tatsächlich passiert ist — was letzte Woche fertig wurde, wie etwas umgesetzt wurde, warum eine Änderung am Datenmodell Ärger gemacht hat und was der Kollege dazu geschrieben hat.

Er kann das, weil alles am selben Ort liegt: Items, Spezifikationen, Anmerkungen aus den Freigaben, Gesprächsnotizen. Wenn Entwickler in ihren eigenen Sitzungen arbeiten, gibt es diesen Ort nicht — dann weiß nur derjenige Bescheid, der dabei war.

Nein. Genau dafür gibt es den Chat und die Spezifikationen: Was passiert ist, lässt sich in Geschäftssprache beantworten, ohne dass jemand einen Änderungsvergleich liest.

Das kommt vor. Deshalb steht zwischen Beschreibung und Umsetzung eine Freigabe, und deshalb ist jeder Schritt nachlesbar. Der wirksamere Teil ist allerdings der davor: Festgeschriebene Architekturentscheidungen verhindern eine ganze Klasse von Fehlern, bevor sie entsteht.

Das Problem ist selten, dass ein Modell nicht programmieren kann. Das Problem ist, wie viele Wege von einer Anforderung zu einer Umsetzung führen und wie viele davon in deinem Projekt falsch sind, obwohl sie für sich genommen richtig wären.

Genau dort setzt die Plattform an. Wenn der Rahmen eng genug ist und die Anforderung richtig verstanden wurde, ist das Ergebnis in aller Regel brauchbar.

Du kannst, und in kritischen Bereichen solltest du. Der Hebel liegt aber vorher: Ein Review der Spezifikation fängt mehr ab als ein Review des Codes, weil ein Missverständnis dort noch nichts gekostet hat.

Tests gehören zur Umsetzung und entstehen mit ihr. Wie streng das gehandhabt wird, gehört zu den Dingen, die in deinen Projektanweisungen festgehalten werden.

Dein Code liegt in Git — mit allem, was das an Historie und Rückwegen mitbringt. Auf dem Board bleibt jedes Item mit seiner vollständigen Vorgeschichte erhalten.

Dir, Quelltext eingeschlossen.

In deinen Repositories. Du legst sie an, du bestimmst, wo sie liegen und wer Zugriff hat. Artifacture kennt die Adressen und die Vorgeschichte deiner Items.

Ja. Was gebaut wurde, ist gewöhnliche Software in deinen Repositories und hat keine Abhängigkeit zu uns.

Das Board und die Vorgeschichte der Items. Der Code, die Architekturentscheidungen und die Projektanweisungen liegen in deinen Repositories und bleiben.

Das ist einer der Gründe, warum es so gebaut ist. Wer übernimmt, liest nicht fremden Code, sondern die festgehaltenen Entscheidungen und die Vorgeschichte. Der Code ist danach das Erwartbare.

Nein.

Das steht vollständig auf der Seite zu Sicherheit und Datenschutz.

Pro kostet 29 € im Monat je Person, Team 49 € im Monat je Person. Team ist gedacht, sobald mehrere Leute an derselben Sache arbeiten.

Die Arbeit an deinem Code macht dein eigener Assistent mit deinem eigenen Zugang — dort entstehen deine Modellkosten, so wie bisher auch. Artifacture rechnet keine Token ab und verkauft keine Guthaben. Was innerhalb der Plattform selbst ein Modell nutzt, ist im Preis enthalten.

Es gibt eine Testphase von 30 Tagen mit einem Projekt und vollem Funktionsumfang.

Nur, für wie viele Personen sie gedacht sind. Der Funktionsumfang ist überall derselbe — wir schalten nichts ab, um einen höheren Tarif attraktiver zu machen.

Je Person im Voraus — wahlweise monatlich oder jährlich. Bei jährlicher Zahlung ist ein Nachlass hinterlegt; die Preisseite zeigt beide Varianten nebeneinander. Kommt jemand im laufenden Abrechnungszeitraum dazu, wird das anteilig berechnet. Zu jeder Abbuchung bekommst du eine Rechnung.

Ja, ohne Mindestlaufzeit und ohne Kündigungsfrist. Schluss ist zum Ende der bereits bezahlten Abrechnungsperiode — bei monatlicher Zahlung also zum Monatsende, bei jährlicher zum Ende des bezahlten Jahres. Nach Ende des Zugangs werden die Daten 90 Tage aufbewahrt und dann gelöscht.

Das hängt vom Umfang ab und wird vorher vereinbart. Es gibt keinen Betrag, der ohne Absprache fällig wird. Unter Umständen ist so ein Vorhaben förderfähig — Näheres steht auf der Preisseite.

Du schreibst uns an [email protected]. Dahinter sitzen die Leute, die die Plattform bauen und selbst täglich damit arbeiten.

Schneller als bei fremdem Code, weil wir ihn nicht lesen müssen. Die Architekturentscheidungen, das Board und die Vorgeschichte der Items sagen uns, worum es geht und woran es hängt.

Ja. Das ist ein eigenes Angebot mit eigenem Preis, und wir klären vorher im Gespräch, ob es sich für dich lohnt.

Bist du wieder dran. Nach einer Übernahme ist das Projekt nicht unser Projekt — du kannst am nächsten Tag selbst weitermachen, auf derselben Plattform, mit demselben Board. Wir heben dich über die Schwelle, wir binden dich nicht.

Dann sagst du es, und es wird geändert. Du siehst jeden Zwischenstand, und jeder Zwischenstand lässt sich korrigieren, bevor darauf weitergebaut wird.

Für Vorhaben, bei denen du kein Repository haben willst. Für einen Nachmittag, an dem du schnell etwas ausprobieren willst — dafür ist der Einstieg zu aufwendig, und Prompt-to-App-Werkzeuge machen das besser.

Sie arbeitet nicht ohne dich. Es gibt keine Items, die über Nacht von selbst durchlaufen — jeder Schritt, den eine Maschine bearbeitet, läuft in einer Session, die du startest. Autonome Arbeiter sind in Entwicklung und noch nicht so weit, dass wir sie ernsthaft anbieten würden.

Das Aufsetzen eines Projekts ist heute die Stelle mit der meisten Handarbeit. Wer da nicht durch will, muss es auch nicht allein tun — siehe die nächste Frage.

Ja. Dafür sind wir da.

Ein halber Tag mit uns, und dein Projekt steht: Repository, Umbrella, die ersten Architekturentscheidungen, die ersten Items auf dem Board. Ab da arbeitest du selbst weiter — auf demselben Board, mit denselben Artefakten, ohne dass wir irgendwo dazwischenhängen.

Das ist ausdrücklich kein Auftrag über deine Software. Es ist der Weg über die erste Meile, und die ist bei uns momentan die steilste.

Melde dich gerne bei uns: [email protected]

Beim Aufsetzen der Repositories, beim Betrieb deiner Anwendung und überall dort, wo eine Entscheidung fachlich ist und keine Vorlage sie beantworten kann. Aber auch da suchen wir bereits nach einer passenden Lösung.

Dann passen wir nicht zusammen, und das ist in Ordnung. Die Vorgaben sind kein Beiwerk, sondern der Grund, warum die Ergebnisse vorhersehbar sind.

Es ist im täglichen Einsatz — bei uns und bei zahlenden Kunden. Der Einstieg ist die Stelle, an der noch am meisten Handarbeit steckt; daran arbeiten wir gerade.

Board — Die Übersicht aller Items eines Projekts mit ihrem aktuellen Zustand.

Item — Eine einzelne Anforderung, ein Fehler oder eine Aufgabe.

Zustand — Eine Station im Ablauf eines Items. Anders als eine Spalte in einem gewöhnlichen Board trägt ein Zustand eine Anweisung, die die bearbeitende Session bekommt.

Workflow — Die Abfolge der Zustände und die Festlegung, wer in jedem handelt. HSDD führt von Backlog über Spec, Spec Review, Implement und Code Review nach Done; ASDD denselben Weg ohne die beiden Freigaben. Daneben gibt es einen kurzen Ablauf für Aufgaben ohne Spezifikation und einen für die Vorarbeit an noch unklaren Anforderungen.

Spezifikation — Die Ausarbeitung eines Items, bevor es umgesetzt wird: welche Architekturentscheidungen gelten, was sich an Dateien, Schnittstellen und Datenmodell ändert, was schiefgehen kann und woran man erkennt, dass es fertig ist. Sie entsteht in Minuten, gilt für diese eine Änderung und wächst nicht — kein Pflichtenheft.

Spec Review — Deine Freigabe der Spezifikation. Geprüft wird nicht die Qualität der Umsetzung, sondern ob die Anforderung richtig verstanden wurde.

Umbrella — Ein eigenes Repository, das dein Projekt beschreibt, ohne es zu enthalten: Architekturentscheidungen, Projektanweisungen, Dokumentation. Dein Code liegt darunter in src/ und behält seine eigene Historie.

Architekturentscheidung — Eine festgehaltene Antwort auf eine Frage, die ein Projekt einmal beantwortet: Datenbank, Anmeldung, Mandantentrennung, Veröffentlichung. Verbindlich, mit Begründung, und der Grund dafür, dass ein Modell nicht mehr entscheidet, wie gebaut wird.

MCP-Server — Die Schnittstelle, über die dein Assistent mit dem Board arbeitet: Arbeit ziehen, Kontext nachfragen, Ergebnisse zurückmelden.

Bootstrap — Der einmalige Vorgang, bei dem aus deinen Antworten die Struktur des Umbrellas, die ersten Architekturentscheidungen und die ersten Items entstehen.