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.

terminal · 5 days
bash
# 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.

Die Features, auf die sich deine Demo stützt.

Ö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.