Vida · Insurance operations
From scattered operations to one source of truth.
I turned an Excel- and CSV-driven insurance brokerage into a dedicated operating system connecting policies, clients, finance, commissions, documents, teams, approvals and day-to-day operations.
Before
Spreadsheets + CSVs
After
One operating system
Control
Permissions + approvals
Growth
Built for expansion
The transformation
Stop scaling the chaos.
The problem was not the absence of software. It was that the business existed across disconnected files, duplicated records, manual handoffs and knowledge held by individual employees.
01
Before
Fragmented operation
Policy sheet
Client sheet
CSV exports
Commission file
Payment records
Employee sheet
Documents
Repeated manual entry
Duplicated records
Disconnected reporting
No reliable audit trail
Manual reconciliation
Dedicated
business
operating system
one record
one workflow
one source of truth
02
After
Vida
Source of truth
Client
One customer record
Core operation
Policy
The business record everything connects to
Claims
Documents
Payments
Commissions
Employees
Broker payables
Govern
Roles + permissions
Control
Approvals + audit
Observe
Business + team metrics
Operational control
Sensitive by design.
Insurance operations involve customer records, financial data, commissions, payroll and business-critical changes. Access and accountability therefore had to be part of the product model, not an admin feature added later.
A sensitive operation
Can this person do this, right now?
Authorization depends on more than whether a button exists. The system evaluates access, business state and the workflow required for that operation.
01 / 05
Control path
Permission · state · approval · audit
Intent
User action
A business operation is requested.
Gate 01
Permission
Is this capability available to this user?
Gate 02
Business state
Is the operation valid at this point in the workflow?
Controlled path
Approval request
When an operation requires explicit approval, the request becomes a visible workflow rather than an informal handoff.
Authorized path
Execute
Valid actions can change business state through the same application boundaries that enforce its rules.
Record
Audit event
The resulting business change remains attributable and inspectable.
Visibility
Permission-scoped
Transitions
Business-rule guarded
History
Attributable
Permissions
Capabilities are granted explicitly so sensitive financial, operational and administrative data is not exposed simply because someone can access the application.
Approval requests
Actions that need another level of control can move through an explicit request and approval workflow instead of relying on messages or verbal confirmation.
Audit trail
Important changes preserve who performed them and how business state changed, creating an operational history the team can actually inspect.
Business rules
One lifecycle. Many consequences.
A policy is not an isolated record. Its financial state controls what the business can do next, and those decisions propagate into commissions, payroll, broker liabilities and operational reporting.
Policy lifecycle
State decides what happens next.
Important operations unlock only when the conditions behind them are true. The workflow itself carries the business rules.
Core flow
Policy → finance → distribution
Explicit state transitions
01
Policy issued
The policy becomes the active business record.
02
Installments
Expected payments and collection state are tracked.
03
Fully paid
The financial condition required for commission work.
Unlock
Commission coding
04
Commission coded
The brokerage records the commercial commission basis.
05
Allocation
Commission is distributed to the people or brokers involved.
06
Finance records
Downstream obligations become explicit.
Employee path
Payroll
Employee commission allocations can flow into payroll processing and statements.
External path
Broker payable
External broker allocations become liabilities that can be tracked and settled independently.
Policy
Business state
Payment
Financial state
Commission
Commercial state
Settlement
Downstream state
Payment first
Commission work stays locked until the policy has been fully paid.
Code before allocation
Commission allocation only becomes valid after the commission has been coded.
Downstream state stays explicit
Employee payroll and external broker payables remain their own financial workflows instead of being inferred from the policy UI.
Architecture
Structure behind the operation.
The system is organized as a monorepo with an interactive Next.js application and a separate background worker. Business rules stay behind explicit application boundaries while both runtimes operate on the same business platform.
Vida monorepo
Interactive runtime · background runtime · shared data
01
Interactive runtime
Next.js application
App Router · RSC · Server Actions
Interface
UI + React Server Components
Business workflows presented to employees through one operating surface.
Application boundary
Server Actions
Mutations enter through an explicit server-side request boundary.
Validate
Zod schemas
Authorize
Permissions
Coordinate
Services
Data boundary
DAL
Database access stays behind application-specific data boundaries rather than leaking into UI components.
02
Background runtime
Worker
Long-running + retryable
Excel imports
Parse · validate · import
Scheduled work
Reminders · recurring jobs
Bulk operations
Notifications · batch processing
Document jobs
Large PDFs · statements
Recovery
Retryable background work
Runtime decision
Interactive requests stay responsive while work that can outlive a page request gets its own execution model.
03
Data foundation
One business record
Application state + private assets
Relational state
PostgreSQL
Policies, clients, payments, commissions, users, workflows and operational state.
Data access
Prisma 7
Typed persistence through the PostgreSQL adapter behind the application's DAL and service boundaries.
04
Business documents
Private + reproducible
R2 · PDF generation
Private object storage
Cloudflare R2
S3-compatible private storage with controlled signed access for policy documents, proofs and generated business files.
Document generation
Versioned PDF templates
Quote output can preserve the template generation it was created with.
Application boundaries
Server Actions handle the request boundary, while validation, permissions and business behavior continue through services and the data-access layer instead of living inside UI components.
Private business records
Documents are stored privately in Cloudflare R2 and accessed through controlled application flows rather than treated as public static assets.
Work outside the request
Imports, reminders, bulk work and retryable jobs run through a separate worker so long-running operations do not occupy the interactive application.
Reproducible documents
Generated quote documents use versioned templates so a historical business artifact can preserve the format it was created with even as future templates evolve.
Operational visibility
See the business as one system.
Centralizing the operation did more than remove duplicated records. It gave management a bird's-eye view of the business, the team and the work moving through it.
Business + team
One source of operational truth
Business overview
From records to operating visibility.
The same operational data that drives workflows also becomes the management view.
Production
Policies
Issued · active · lifecycle
Financial
Premiums
Expected · collected · outstanding
Commercial
Commission
Coded · allocated · payable
Operations
Claims
Open · progressing · closed
Work
Tasks + requests
Assigned · pending · completed
People
Sales activity
Contribution · target · trend
Management consequence
Reporting no longer needs to be reconstructed separately from the operation. The records employees work with every day are the same records management uses to understand the business.
Team performance
Give performance a reference point.
Sales targets sit beside actual production so performance can be understood against an explicit expectation rather than evaluated from isolated totals.
Sales employee
Actual
Sales target
Target
Contribution
Team share
Activity
Operational
Compare
Employee ↔ team
Measure
Actual ↔ target
Business overview
Policies, production, financial state and operational activity can be understood from one management surface instead of reconstructed from separate files.
Employee performance
Sales contribution and operational activity can be compared using the same records that drive the underlying workflows.
Sales targets
Individual sales targets give the team a clear reference point for performance instead of evaluating results without a shared expectation.
Operational workload
Tasks, requests, claims and other active work become visible as part of the same operating environment.
Continued expansion
Add capability. Not another system.
Once the operating model was centralized, new workflows could extend the same clients, policies, permissions and financial state instead of creating another disconnected tool.
Stable foundation
The core does not need to move.
New product capabilities continue to operate on the same business records, permissions and workflow boundaries.
Business identity
Clients
Core operation
Policies
Financial state
Payments + commissions
Operational control
Permissions + audit
Expansion surface
New workflows
Extend the operating model rather than duplicate it.
Data intake
Excel + CSV workflows
Structured import flows can move legacy operational data into the same validated business model instead of creating another parallel spreadsheet process.
Access
Cross-domain search
Clients, policies, claims, employees and operational records can become discoverable through one search surface rather than separate lookup workflows.
Documents
Bilingual quotes
Arabic and English quote generation builds on versioned templates so new document workflows remain reproducible business artifacts.
Execution
Background work
Imports, reminders, bulk operations and heavier document jobs can move to the worker without changing the interactive application model.
Language
Arabic + English
Execution
Interactive + background
Business model
Shared
Business expansion
A new location should not mean new operational chaos.
Existing operation
Vida
Business rules already encoded.
New location
Same operating model
Employees enter an existing system instead of inheriting another set of files.
Same workflows
Same permissions
Same source of truth
Same reporting model
Outcome
The business became easier to operate.
The result was not simply a more modern interface. Manual processes became explicit workflows, fragmented records became one operating model, and business knowledge moved into the system itself.
Time
Hours of manual work removed every week.
Repeated CSV handling, reconciliation and movement between disconnected files were replaced by workflows operating on the same underlying records.
Clarity
One record. One source of truth.
Clients, policies, payments, commissions, documents and operational activity now belong to one connected model instead of being duplicated across files.
Visibility
Management can see the operation as a whole.
Business activity, financial state, employee performance and sales targets can be understood from the same system employees use to run the business.
Scale
Growth no longer means multiplying the chaos.
New employees and future locations can enter an existing operating model with established workflows, permissions and reporting instead of inheriting another collection of spreadsheets.
What Vida changed
The operation no longer depends on knowing where everything lives. The system knows.
Operate
One connected system
Onboard
Rules already encoded
Expand
Without duplicating process