Solution · Web app
A full customer-facing app, zero backend of your own.
Your own frontend, your own identity provider, your own host, and Vectros as the complete backend: typed data and documents, hybrid search and RAG, and your own custom logic, all enforced by the exact same access control. Even the token exchange for sign-in needs no route of your own.
The alternative
What you'd otherwise build.
Shipping a real, multi-tenant customer-facing app usually means building the backend first and the product second.
- Build file upload and storage, wired to the same records. Your documents need to be uploaded, stored, and scoped exactly like the record they belong to: usually its own storage bucket, its own metadata table, and its own copy of the isolation logic you already wrote once for records.
- Stand up search and RAG yourself. Full-text, semantic, and hybrid search over the same data, plus a citation-grounded answer panel: normally three systems to wire together and keep in sync with whatever you just wrote to the database.
- Compose your own multi-step logic safely. A database gives you transactions. It doesn't give you a way to run your own logic under the same authorization as every other call, safely retryable, without hand-rolling a second system to enforce it.
- Hand-write a separate scope check for every action. Who can create a record isn't who can delete one. Get the scope check wrong and a caller either sees too little, or worse, grants themselves access they shouldn't have.
- Build a backend just to broker sign-in, on top of all that. A route whose only job is exchanging your identity provider's token for your own session: infrastructure you now own, including the fallback call for when the token itself doesn't carry an email.
What's actually hard
One access model, not five systems.
Each of these exists elsewhere on its own. What's harder to find is all of them enforced by the same declarative, row-level access control, instead of a different auth story bolted onto each one.
Documents and search, already indexed
Documents, scoped like everything else
Files upload straight into the same isolated compartment as the record they belong to: no separate storage bucket, no separate metadata table, no isolation logic to duplicate.
Search and grounded answers, already there
Hybrid search and a citation-grounded answer panel run over the same records and documents already indexed, no separate search service or RAG pipeline stood up.
Your own logic, under the same rules
Custom logic, same access control
When a call needs to do more than read or write one record, your own logic runs as a stored script under the exact same access scopes as everything above it, not a separately managed service credential. Its writes commit atomically, and a resubmitted request replays the same result instead of creating a duplicate.
The access model underneath all of it
In the published reference implementation (see below), that looks like this:
- Scope isn't fixed by the role. It's resolved live from membership records. Read and update require having created the client or holding any-level membership in it; delete narrows further to admin-level membership specifically, checked fresh on every call.
- Case-handler can't add anyone to a client, by design. Access rules constrain who owns a row, not the values inside it, so a create grant on a membership record would let case-handler set its own admin flag. The blueprint withholds that grant entirely rather than trying to restrict which value it could set.
See the access-control mechanics for how roles, namespaces, and enforcement work generally.
Run it
casework-spa proves this end to end.
An org manages compartments for the people inside it, and only the right people ever see any one of them, skinned as HR case management to make it concrete to run, not a product claim about that domain. The same shape works for client engagements, field-service jobs, or property management just as well.
git clone https://github.com/vectros-ai/vectros-casework-spa
vectros bootstrap --blueprint ./vectros-casework-spa/blueprint/casework.blueprint.yaml \
--set companyName="Acme HR" \
--set auth0Domain=acme.us.auth0.com \
--set auth0Audience=acme-hrFollow the repo's Auth0 and Vercel setup guides, apply its blueprint with your own input values, and deploy.
Built entirely on the database, document ingestion, search, functions, and access-control mechanics documented elsewhere on this site, not a special case.
See how it all fits together on the platform page.