Dein Job ist das Produkt.
Nicht die Runtime.
Du hast 18 Monate Runway und 7.000 Dinge zu bauen. Die Hälfte davon macht dein Produkt einzigartig. Die andere Hälfte ist Infrastruktur — Auth, Billing, Observability, Multi-Tenancy, Echtzeit, durable Jobs — und für die gibt dir niemand Anerkennung. Voltro ist diese Hälfte, fertig. Bau den Teil, der wirklich deiner ist.
# Monday morning: have an idea.
pnpm dlx @voltro/cli create-project myidea --baseline=compose
# Monday afternoon: have a working multi-tenant SaaS.
# Tuesday afternoon: have your AI feature wired (defineAgent).
# Wednesday afternoon: have billing live (Stripe + entitlements).
# Thursday afternoon: have observability (OTel + voltro logs).
# Friday afternoon: deploy on Render / Fly / your VPS.
# Friday evening: ship to your first 10 beta users.
# What you didn't do this week:
# - Wire react-query to a websocket.
# - Glue a job queue (Bull / Inngest / Trigger.dev).
# - Pick + integrate an auth provider.
# - Set up multi-tenant row-level security.
# - Write a single useEffect for live data.
# - Re-implement an HNSW vector index.Sechs Dinge von deiner Roadmap, ab Tag eins.
Reaktives Gefühl ab Tag eins
Deine Demo hat die live aktualisierende, "wow, das fühlt sich lebendig an"-Qualität, die Investoren bemerken. Nicht weil du WebSocket-Code geschrieben hast — sondern weil jede Listenansicht ein useSubscription ist.
Multi-Tenant vor dem ersten Kunden
Dein erster zahlender Kunde ist ein 10-Personen-Team, das seine Daten von deinen Testdaten isoliert haben will. tenant() im Schema heißt: Du musst Row-Level-Security nicht in Woche sechs nachrüsten.
KI als Primitiv
Jeder Startup-Pitch 2026 hat ein KI-Feature. Voltro liefert defineAgent, defineTool, Streaming-Threads, pgvector-RAG. Bau das Feature, das dich differenziert — nicht die Runtime, die das LLM aufruft.
Durable Workflows statt Job-Queue
Stripe-Checkout abgeschlossen → Willkommens-Mail senden → Nudge an Tag 3 planen → auf Aktivierung warten → an Tag 7 nachfassen. Das ist eine Workflow-Datei, durable über Deploys hinweg. Keine bullmq-+-EventBridge-Integration.
Observability, die DIR beim Debuggen hilft
voltro logs --trace [id] liefert die ganze Kette frontend → API → Workflow für einen fehlgeschlagenen Request. Über alle Hops, in Reihenfolge. Bevor du Kunden hast, ist das DEIN Debugger.
Deploys ohne SRE-Team
Drei Baselines (bare, compose, helm) bringen dich an einem Nachmittag von localhost zu einer öffentlichen URL. Wenn du die Seed-Runde einsammelst, brauchst du keine Infrastruktur-Leute, um weiter zu wachsen.
Die klassische Startup-Todesspirale, entfernt.
Das Muster: Monat 1, du baust das MVP. Monat 2, "Echtzeit wäre cool" — du fügst einen WebSocket hinzu. Monat 3, "Multi-Tenancy bricht" — du schreibst die Datenschicht neu. Monat 4, "Stripe-Webhooks sind ein Chaos" — du fügst einen Event-Bus hinzu. Monat 5, "Billing-Entitlements werden haarig" — du baust eine Quota-Tabelle. Monat 6, du hast seit Monat 1 kein Kundenfeature ausgeliefert. Voltro ist die Version, in der die Monate 2–5 Konfigurationsänderungen sind.
Die Early-Stage-Checkliste:
- • Pre-Revenue. Self-hoste auf einem einzigen VPS — `compose`-Baseline. Fünf Minuten bis zum Deploy.
- • Erste Kunden. Tenants im Schema heißt: Jeder Kunde ist bereits isoliert. Kein Nachrüsten.
- • Erste Integration. Stripe-Webhook? Slack-Hook? GitHub-Event? @voltro/plugin-webhooks liefert Signaturprüfung + Idempotenz für die gängigen Anbieter.
- • Erste Team-Einstellung. Onboarding übergibt EIN Framework, EINE Codebase, EIN Set an Mustern. Keine Tour durch neun NPM-Pakete.
- • Seed-Runde. Investoren sehen eine Echtzeit-UI. Kunden sehen ein poliertes Produkt. Du siehst Runway, den du ins Produkt gesteckt hast, nicht in die Runtime.
Was du am ersten Tag nicht aufstellst.
Plugins, verfügbar in dem Moment, in dem du eines brauchst — vorher läuft keines
veröffentlichte Pakete hinter einer Installation, damit der Stack mit dem Produkt wächst
Von einer Idee zu etwas, das ein Beta-Nutzer öffnen kann.
- 1
Scaffolden
Ein Befehl liefert eine api und ein Frontend, die schon miteinander sprechen, mit Tests und einer Deploy-Baseline. Der erste Commit ist eine Produktentscheidung, keine Woche Verkabelung.
- 2
Modellieren
Tabellen deklarieren; der Planer wendet sie an. Frühe Produkte ändern ihr Datenmodell wöchentlich — genau da bestrafen handgeschriebene Migrationsketten am härtesten.
- 3
Die Schleife ausliefern
Queries pushen, Mutations schreiben optimistisch, Hintergrundarbeit überlebt einen Neustart. Was die meisten Teams später anschrauben, ist bereits koordiniert.
- 4
Deployen
Ein Container und eine Datenbank sind ein vollständiges Produktions-Deployment. Replicas kommen dazu, wenn du sie brauchst — nichts im Code nahm an, dass es nur eine gibt.
Warum Startups diesen Stack wählen.
Wie viel Infrastruktur brauche ich am ersten Tag?
Einen Node-Prozess und eine Datenbank. Durable Workflows journalisieren in diese Datenbank, geplante Jobs koordinieren sich darüber, und der Cache ist per Default Memory — es gibt also keinen Broker, keinen Workflow-Dienst und keine separate Cache-Ebene aufzustellen, bevor der erste Nutzer existiert.
Das zählt, weil frühe Infrastrukturentscheidungen meist unter Zeitdruck fallen und dann jahrelang geerbt werden. Die Teile, die die meisten Teams später anschrauben — Hintergrundjobs, die einen Absturz überleben, Cron, das nicht doppelt feuert, Echtzeit-Updates — sind bereits koordiniert; einen zweiten Container hinzuzunehmen ist also eine Config-Änderung und keine Re-Architektur.
Nichts davon verlangt eine Managed-Plattform. Self-Hosting ist der Default: dein Connection-String, deine Backups, deine Zugriffsregeln — deployt, wo du ohnehin deployst.
Was spart mir das im ersten Monat?
Die Klempnerei, die mit deinem Produkt nichts zu tun hat: Auth mit Sessions, MFA und Passwort-Reset; File-Storage mit öffentlichen und privaten Objekten; Transaktions-E-Mail; Hintergrundjobs; eine Admin-Oberfläche für den internen Gebrauch; und die reaktive Schicht, die Screens frisch hält, ohne dass du Invalidierungsregeln schreibst.
Jedes davon ist eine Woche, die du nicht ausgibst — und, wichtiger, eine Woche, deren Fehler du nicht debuggst. Das Design der Kontosperre, der Session-Widerruf, die Mandantengrenze, die geschlossen scheitert: das sind die Details, die trivial aussehen, bis sie in Produktion falsch sind.
Templates machen das konkret statt theoretisch. Scaffolde eine laufende App, die genau die Schicht zeigt, die du brauchst, lies sie in einem Rutsch und lösch, was du nicht willst. Ein Startpunkt, der dir gehört, keine Abhängigkeit mit Update-Channel.
Was passiert, wenn das Produkt seine Form ändert?
Schema-Änderungen sind deklarativ: deine Schema-Datei ist der Sollzustand, der Planer diffed sie gegen die Live-Datenbank und druckt die Operationen. Produkte in der frühen Phase ändern ihr Datenmodell wöchentlich — und handgeschriebene Migrationsketten sind genau da schmerzhaft.
Breaking Changes im Framework kommen mit Codemods statt mit einer Anleitung zum Nachmachen. `voltro update` hebt die Pakete, gleicht Peers an und schreibt deinen Quellcode um, wo es automatisierbar ist — das ist der Unterschied zwischen Upgraden und Upgrades aufschieben, bis sie eine Tortur sind.
Und wenn eine Seite sich als dynamischer entpuppt als angenommen, ist der Render-Modus eine Export-Zeile. Du entdeckst nicht beim Launch, dass Marketing-Site und App zwei Toolchains brauchen.
Was, wenn wir größer werden als gedacht?
Die Skalierungsgeschichte steckt schon im Code, den du geschrieben hast. Multi-Tenancy ist ein Schema-Mixin, dessen Grenze die Runtime erzwingt; geplante Jobs koordinieren sich über Replicas; das Echtzeit-Fan-out ist auf Postgres und MySQL flottenweit. Wachsen heißt Replicas hinzufügen statt die Teile umzuschreiben, die einen einzelnen Prozess annahmen.
Die enterprise-förmigen Anforderungen, die mit dem ersten großen Kunden kommen — SSO, SCIM-Provisionierung, Audit-Spuren, Datenresidenz, RBAC — sind Plugins statt eines Umbaus. Du aktivierst sie, wenn jemand fragt, nicht vorsorglich.
Nichts davon ist ein Argument, jetzt zu überbauen. Es ist ein Argument, dass die billigen frühen Entscheidungen hier nicht zu den teuren späten werden — der Tausch, den die meisten Stacks still an deiner Stelle machen.
Was du nicht zuerst bauen musst.
| Bereich | Was du bekommst |
|---|---|
| Auth | Sessions, MFA, Passkeys, Magic Links, Einladungen und Kontosperre — First-Party, ohne Anbieterzwang. |
| Hintergrundarbeit | Durable Workflows und koordiniertes Cron in deiner Datenbank — kein Broker, kein Worker-Dienst. |
| Live-UI | Subscriptions über den Change-Feed der Datenbank; keine Cache-Keys, keine manuelle Invalidierung. |
| Interne Tools | Ein Admin-Dashboard, aus deinem Schema abgeleitet — internes CRUD ist kein Nebenprojekt. |
| Deployment | Ein Container und eine Datenbank; Compose- oder Helm-Baselines, wenn du sie willst. |
| Spätere Anforderungen | SSO, SCIM, Audit, RBAC und Residenz als Plugins — aktiviert, wenn ein Kunde fragt. |
Häufige Fragen
Ist das für ein MVP überdimensioniert?
Der Startabdruck ist ein Prozess und eine Datenbank — kleiner als die meisten MVP-Stacks, die schon eine Queue und einen Cache haben. Was enthalten ist, ist verfügbar statt verpflichtend: du aktivierst ein Plugin, wenn du es brauchst, nicht vorab.
Wie schnell kann ich wirklich etwas ausliefern?
Ein Befehl scaffoldet ein laufendes Projekt mit api und Frontend, verdrahtet, Ports vergeben, Tests dabei. Ab da bearbeitest du eine laufende App, statt eine zusammenzusetzen.
Sitzen wir dann fest?
Die Datenbank gehört dir, und nichts wird durch unsere Infrastruktur geleitet. Gescaffoldeter Code gehört dir, ohne Update-Channel, der hineinschreibt. Die Hauptkopplung sind die APIs des Frameworks — was jedes Framework kostet, und weshalb der Upgrade-Pfad Codemods mitliefert.
Was, wenn wir schnell einstellen müssen?
Es ist TypeScript, React und SQL mit dateibasierten Konventionen, und jedes Projekt sät einen Agent-Guide, damit KI-Assistenten Code passend zu den echten Konventionen erzeugen statt zu raten. Der ungewohnte Teil ist Effect — und die üblichen Pfade lesen sich wie gewöhnlicher async-Code.
Was kostet es?
Das Framework ist self-hosted und läuft auf deiner eigenen Infrastruktur. Bezahlte Pläne rechnen pro Entwicklersitz; die Managed Cloud ist ein separates, optionales Produkt und für den Betrieb nicht nötig.
Die Features, auf die sich deine Demo stützt.
Reaktive Queries
Die "es fühlt sich lebendig an"-Demo-Qualität. Ein useSubscription pro Listenansicht.
KI-Primitive
Das differenzierende Feature in jedem Pitch-Deck 2026 — Agents, RAG, durable Threads.
Durable Workflows
Der Onboarding-Flow, der wirklich zu Ende läuft — selbst wenn dein einziger Produktionsserver neu startet.
Öffne das Framework. Schau es dir selbst an.
Jede Primitive auf dieser Seite ist heute im Framework. Klone den Starter, lass `voltro dev` laufen, in zwei Minuten ist es auf dem Bildschirm.