02 / Selected Work
Velora Manager
Private operations software
Fictional production-quality demonstration, not a client project or operating business.
A private workspace built around the same detailing requests created by the public Velora website, from first review through scheduling and completion.
The business problem
A request is only the beginning.
Once requests begin arriving, someone needs to understand them, follow up, prepare a quote, schedule the work, and remember what happened.
Velora Manager gives that work a private, focused home. It carries the information collected by the public website into a working queue, then keeps the customer, vehicle, service need, schedule, quote, notes, and history attached to one record.
The interface is intentionally quieter than the customer site. It is designed for repeated scanning, fast decisions, and a clear next action.
Request discovery
Find the work that needs attention.
The request list gives the operator useful context at a glance and several direct ways to narrow the queue. The goal is not a dashboard full of metrics; it is a reliable view of current customer work, so requests do not disappear into separate email or text threads and their current state remains organized.
- Search
- Find a request by customer, vehicle, or identifying detail.
- Package
- Narrow the list to the service the customer selected.
- Status
- See which requests need contact, a quote, or scheduling.
- Sort
- Bring the newest or most relevant work into view.
- Records
- Open the complete request without losing its context.
- Schedule
- Keep timing visible as a request moves toward service.
From list to record
The whole request stays together.
Opening a request turns a row into a working record. Customer and vehicle details remain visible beside the service package, focus, schedule, workflow status, quote, notes, and available next actions.
Customer context
Contact, vehicle, and submitted service details remain close to the work they describe.
Current state
Status and schedule make it clear where the request sits and what should happen next.
Working record
Quotes, internal notes, and activity accumulate without replacing the customer's original request.
Workflow pipeline
Progress follows defined steps.
Each status represents a real stage in the service process. Available actions move the request through sensible transitions while server-side rules reject impossible jumps, such as moving directly from New to Complete.
- NewReceived and ready for review.
- ContactedThe customer conversation has begun.
- QuotedA price has been prepared and recorded.
- ScheduledThe work has an agreed service time.
- CompleteThe request has reached its working conclusion.
CancelledDeclined
Working detail
Quote and notes serve different jobs.
A quote the business can rely on.
A price is attached to the request and shown in ordinary currency. Behind the interface it is stored as integer cents, avoiding floating-point ambiguity while keeping the operator's task straightforward.
Private context for the next decision.
Internal notes are kept separately from the customer's submission. The original need remains intact while the team can add the context required to follow through.
Activity history
The record remembers what changed.
Meaningful events such as Request created, Status changed, Quote updated, and Internal notes updated become part of the request's history. That history is produced by database-backed audit behavior rather than temporary interface state, giving later decisions a clear basis after a refresh or restart.
Security model
Private means authorized at every layer.
Signing in is necessary, but it is not enough. Access is restricted to approved Manager users, and request reads and mutations are checked again where the data is handled.
Supabase Auth establishes the signed-in user.
Server-rendered routes receive authenticated session context.
Only approved Manager members reach private operations views.
RLS and server-authorized mutations protect request records.
Persistence
The workflow survives the interface.
Requests live in PostgreSQL rather than temporary page state. Public submissions and private operations use the same records, so status, quote, notes, and history remain after refreshes and application restarts.
- Server ComponentsRequest authenticated page data.
- Supabase clientCarries server session context.
- PostgreSQLStores the shared working record.
- RLSEnforces access beside the data.
- Database historyPreserves meaningful activity over time.
Engineering notes
The stack supports the operating model.
The private application combines server-rendered reads, focused client interactions, server-authorized mutations, typed business rules, persistent relational data, and database-backed activity history.
- Next.js
- React
- TypeScript
- Server Components
- Server Actions
- Supabase Auth
- PostgreSQL
- Row Level Security
- Vercel
What it demonstrates