The RAVV stack: a production app with no backend to build

A lot of software reduces to the same pattern: a company manages a set of cases, clients, or accounts, and only the right people inside that company should ever see any one of them. HR case management. Client engagements at a firm. Patient case management. Field service jobs. Property management. The category is common. Building the access control correctly, every time, for every one of them, is not.

We built a full reference implementation of that pattern, skinned as HR case management. The only thing we had to build was the front end: the platform underneath already provides the secure, isolated backend this kind of app actually needs.

What you don't build

Vectros gives an app like this a full backend already: a secure, scalable, structured data store (typed records and documents) with full-text search, semantic search, and flexible filtering unified into one hybrid index, not three separate systems to wire together, all driven from one fairly simple declarative model you write once. On top of that: per-compartment isolation enforced structurally rather than by a WHERE clause you have to remember every time, grounded AI answers with citations over that same data, and a tamper-evident audit trail. That's not a preview or a roadmap item. It's running production infrastructure today, and it's most of what an app like this actually needs. What it didn't yet cover was a customer-facing app with its own sign-in: your users, your identity provider, not ours.

The one piece that was missing

Every reference app we'd built before this one, including the ones already public (app.vectros.ai, the admin app), still needed something small behind the scenes: a route we owned, gated by our own sign-in, that minted the first credential for whoever showed up. That's a real backend. It's small, but it's real, and it's ours to run, not yours.

Apps built with other third-party or custom backends face a much bigger gap: no data model, no search, no isolation, no audit trail, and all of that comes before you even get to sign-in. On Vectros, this was the one piece left. Sign-in happens through your identity provider, exactly like any app. The token it hands back gets exchanged, directly from the browser, for a Vectros credential. That credential is scoped to exactly what that user is allowed to do, enforced by the same declarative policy that already governs the rest of the backend. The app never holds a master key, because one never reaches it. Read the code and check it yourself.

We're calling this pattern RAVV, because a pattern worth reusing is worth naming: React, Auth, Vercel, Vectros. Three of those four are yours to pick; only the last one is fixed. We built the reference instance on React, Auth0, and Vercel specifically, because concrete setup instructions need concrete tools. Swap in Vue, Cognito, and Netlify and the pattern holds exactly the same.

We ran it ourselves before writing the setup docs

We didn't design this against imagined requirements and call it proven. We stood up our own Auth0 tenant, our own Vercel account, and deployed the whole thing exactly the way the setup docs tell you to, specifically to find what actually breaks when nobody's holding your hand.

A few things did. Two examples: Vercel's Deployment Protection silently blocks Auth0's own callback redirect unless you turn it off for Production, so sign-in works locally and then fails the moment you deploy for real. And a direct link to a client-side route like /callback returns a 404 without an explicit rewrite rule, exactly the kind of failure that only shows up once a real user clicks a real link instead of navigating in from the app's own home page. Both are written into the setup guide now, in the order you'll actually hit them, so the next fork doesn't rediscover them the hard way.

The reference implementation

This is a reference implementation, not a product to run as-is. Point it at your own Vectros deployment and your own Auth0 tenant and it runs exactly as shipped, but the value is in the shape, not the specific screens. Adapt it and you have client engagements, field-service jobs, or your own version of "an org manages compartments for the people or cases underneath it."

What's actually built: an employer creates cases for employees (a grievance, an accommodation request, an onboarding case), assigns them to a case handler, and tracks them to close. Org management, a client roster, case creation and assignment, a filterable case list, file uploads, a team page with an invite flow, self-service password reset and two-factor setup. There's also a chat panel that answers questions grounded in one case's own notes and documents, with citations (today that panel works fully for an HR admin; a case handler's own access to it is still blocked on a platform-side scope limitation we haven't closed yet). None of it required us to write a line of backend authorization logic. It came from the blueprint.

The blueprint itself is worth a look if you want the real depth: two roles, a handful of record types, and enough deliberate detail that we caught our own authorization bugs by tracing through it line by line before anyone else did. A case handler can create a case in their own org but can't grant themselves admin rights over someone else's client. An HR admin who founds a company can delete it; one who was only invited in cannot. Every one of those distinctions is a policy statement, not application code, and every one of them is checked before it ships. The same policy statements would scope an agent's access exactly the same way, not just a person's. More on that soon.

What this first example doesn't do

This is a first example, built for one access pattern: a single company standing up its own case-management team, no public sign-up anywhere in the app. Every account, including the very first one, is invited. That's a deliberate scope, not a missing feature, and not the only way to grant access that the platform supports: a version where people sign themselves up and found their own compartment, or one with a public floor role and staff elevated on top of it, uses the same underlying primitives differently. This is the first one we're publishing, and we have proven it end to end: our own Vercel account, our own Auth0 tenant, our own deployment. The next test is a real fork from someone who isn't us.

Try it

This repo is also written to be read by a coding agent, not just by you. docs/AGENTS.md lists every override point, the data model, and the invariants that must not break. Point a coding agent at this repo and ask it to adapt the pattern to your own domain, and it has a real map to work from.

That holds up even in the extreme case, worth calling out on its own: someone without deep backend experience, pointing a coding agent at this repo and expecting a real, secure, audited app on the other end. Against a hand-rolled backend, that's asking the agent to get security right entirely on its own. Here, it doesn't have to. Vectros enforces isolation and access control structurally, not the agent. Get the blueprint's permission grants wrong, and you have a narrow, reviewable mistake in one declarative file. Get a hand-rolled backend's enforcement wrong, and you have a silent security hole hiding potentially anywhere in application code.

The reference app, its blueprint, and a full setup walkthrough are public. Fork it, point it at your own identity provider and your own Vectros deployment, and see how much of your next app you actually have to write.

Vectros is an invite-only preview right now. Request early access if you don't have a key, and see the platform overview for the rest of what the same backend gives you: hybrid search, grounded RAG, and an agent surface over the identical data and policy model this app runs on.