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.
What you are not standing up on day one.
plugins available the moment you need one — none of them running before that
published packages behind one install, so the stack grows with the product
From an idea to something a beta user can open.
- 1
Scaffold
One command gives an api and a frontend that already talk to each other, with tests and a deploy baseline. The first commit is a product decision, not a week of wiring.
- 2
Model it
Declare tables; the planner applies them. Early products change their data model weekly, and this is the part hand-written migration chains punish hardest.
- 3
Ship the loop
Queries push, mutations write optimistically, background work survives a restart. The parts most teams bolt on later are already coordinated.
- 4
Deploy
One container and a database is a complete production deployment. Add replicas when you need them; nothing in the code assumed there was only one.
Why startups pick this stack.
How much infrastructure do I need on day one?
A Node process and a database. Durable workflows journal to that database, scheduled jobs coordinate through it, and the cache defaults to memory — so there is no broker, no workflow service and no separate cache tier to stand up before the first user exists.
That matters because early infrastructure decisions are usually made under time pressure and then inherited for years. The parts most teams bolt on later — background jobs that survive a crash, cron that does not double-fire, real-time updates — are already coordinated, so adding a second container later is a config change rather than a re-architecture.
Nothing here requires a managed platform. Self-hosting is the default: your connection string, your backups, your access rules, deployed wherever you already deploy.
What does this save me in the first month?
The plumbing that has nothing to do with your product: auth with sessions, MFA and password reset; file storage with public and private objects; transactional email; background jobs; an admin surface for internal use; and the reactive layer that keeps screens fresh without you writing invalidation rules.
Each of those is a week you are not spending, and — more importantly — a week whose bugs you are not debugging. The account-lockout design, the session revocation, the tenant boundary that fails closed: these are the details that look trivial until they are wrong in production.
Templates make it concrete rather than theoretical. Scaffold a working app that already demonstrates the slice you need, read it in a sitting, then delete what you do not want. It is a starting point you own, not a dependency with an update channel.
What happens when the product changes shape?
Schema changes are declarative: your schema file is the desired state, and the planner diffs it against the live database and prints the operations. Early-stage products change their data model weekly, and hand-written migration chains are where that becomes painful.
Breaking changes in the framework itself come with codemods rather than a migration guide you follow by hand. `voltro update` bumps the packages, aligns peers and rewrites your source where the change can be automated — which is the difference between upgrading and postponing upgrades until it is an ordeal.
And when a page turns out to be more dynamic than you assumed, the render mode is one export line. You do not discover at launch that the marketing site and the app need two different toolchains.
What if we get bigger than expected?
The scaling story is already in the code you wrote. Multi-tenancy is a schema mixin whose boundary the runtime enforces; scheduled jobs coordinate across replicas; real-time fan-out is fleet-wide on Postgres and MySQL. Growing means adding replicas rather than rewriting the parts that assumed a single process.
The enterprise-shaped requirements that arrive with your first large customer — SSO, SCIM provisioning, audit trails, data residency, RBAC — are plugins rather than a rebuild. You enable them when someone asks, not in anticipation.
None of that is an argument for over-building now. It is an argument that the cheap early choices here do not become the expensive late ones, which is the trade most stacks quietly make on your behalf.
What you do not have to build first.
| Concern | What you get |
|---|---|
| Auth | Sessions, MFA, passkeys, magic links, invitations and per-account lockout — first-party, no vendor required. |
| Background work | Durable workflows and coordinated cron in your database — no broker or worker service to run. |
| Live UI | Subscriptions driven by the database's change feed; no cache keys, no manual invalidation. |
| Internal tools | An admin dashboard derived from your schema, so internal CRUD is not a side project. |
| Deployment | One container and a database; Compose or Helm baselines when you want them. |
| Later requirements | SSO, SCIM, audit, RBAC and residency as plugins — enabled when a customer asks. |
Frequently asked questions
Is this overkill for an MVP?
The starting footprint is one process and a database, which is smaller than most MVP stacks that already have a queue and a cache. What is included is available rather than mandatory — you enable a plugin when you need it, not up front.
How fast can I actually ship something?
One command scaffolds a working project with an api and a frontend wired together, ports allocated and tests included. From there you are editing a running app rather than assembling one.
Are we locked in?
The database is yours and nothing is proxied through our infrastructure. Scaffolded code is yours with no update channel writing into it. The main coupling is the framework's own APIs — which is what any framework costs, and why the upgrade path ships codemods.
What if we need to hire quickly?
It is TypeScript, React and SQL with file-based conventions, and every project seeds an agent guide so AI assistants generate code matching the actual conventions rather than guessing. The unusual part is Effect, and the common paths read like ordinary async code.
What does it cost?
The framework is self-hosted and runs on your own infrastructure. Paid plans are per developer seat; the managed cloud is a separate, optional product that is not required to run anything.
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.