Your job is the product.
Not the runtime.
You've got 18 months of runway and 7,000 things to build. Half of them are the things that make your product different. The other half are infrastructure — auth, billing, observability, multi-tenancy, real-time, durable jobs — and they're the half nobody will give you credit for. Voltro is that half, finished. Build the part that's actually yours.
# 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.Six things off your roadmap, day one.
Day-one reactive feel
Your demo has the live-updating, "wow it just feels alive" quality that investors notice. Not because you wrote websocket code — because every list view is a useSubscription.
Multi-tenant before the first customer
Your first paying customer is a 10-person team that wants their data isolated from your test data. tenant() in the schema means you don't scramble to retrofit row-level security in week six.
AI as a primitive
Every startup pitch in 2026 has an AI feature. Voltro ships defineAgent, defineTool, streaming threads, pgvector RAG. Build the feature that differentiates you, not the runtime that calls the LLM.
Durable workflows, not a job queue
Stripe checkout completed → send welcome email → schedule day-3 nudge → wait for activation → poke on day 7. That's one workflow file, durable across deploys. Not a bullmq + EventBridge integration.
Observability that helps YOU debug
voltro logs --trace [id] returns the whole frontend → API → workflow chain for one failed request. Across hops, in order. Before you have customers, this is YOUR debugger.
Deploys without an SRE team
Three baselines (bare, compose, helm) get you from localhost to a public URL in an afternoon. When you raise the seed round, you don't need to hire infrastructure people to keep growing.
The classic startup death-spiral, removed.
The pattern: month 1, you build the MVP. Month 2, "real-time would be cool" — you add a websocket. Month 3, "multi-tenancy is breaking" — you rewrite the data layer. Month 4, "Stripe webhooks are a mess" — you add an event-bus. Month 5, "billing entitlements are getting hairy" — you build a quota table. Month 6, you haven't shipped a customer feature since month 1. Voltro is the version where months 2–5 are configuration changes.
The early-stage rubric:
- • Pre-revenue. Self-host on a single VPS — `compose` baseline. Five minutes to deploy.
- • First customers. Tenants in the schema mean each customer is already isolated. No retrofit.
- • First integration. Stripe webhook? Slack hook? GitHub event? @voltro/plugin-webhooks ships signature verification + idempotency for the common providers.
- • First team hire. Onboarding hands them ONE framework, ONE codebase, ONE set of patterns. Not a tour of nine NPM packages.
- • Seed round. Investors see a real-time UI. Customers see a polished product. You see runway you spent on the product, not the runtime.
The features your demo will lean on.
Open the framework. See it for yourself.
Every primitive on this page is in the framework today. Clone the starter, run `voltro dev`, and have it on screen in two minutes.