How gig workers earn more with UnifyOne

A driver splitting the week between Uber, Lyft, DoorDash, and Instacart had four payout schedules, four earnings screens, and no idea what any given hour actually netted after fuel. UnifyOne pulled all of it into one place: 1. **One Earnings Dashboard** (Gig Command): Every shift across all four apps logged together. Start a shift and mileage logs automatically — no spreadsheets, no screenshots of payout screens. 2. **Tax Autopilot**: Captured mileage from every logged shift at the current IRS standard rate and kept a real-time year-to-date deduction total — 14,700 miles the driver never had to write down. Quarterly estimated-tax alerts fired before each deadline with the Form 1040-ES figures ready to go. 3. **GigIQ Shift Intelligence**: Read the driver's real earnings history — not industry benchmarks — to show which hours and zones paid the most after expenses. Weekend delivery blocks beat weekday rideshare by a wide margin, so the schedule changed and net pay per hour went up without adding hours. 4. **Money Manager**: Budgeting and tax set-aside built on real after-expense income, so the money owed each quarter was already sitting there when the alert arrived. Kai answered the "can I deduct this?" questions along the way, on the driver's own numbers. Result: A full year of IRS mileage captured automatically, all four quarterly estimates filed on time, and a schedule built on real numbers instead of guesswork. Know what you earn. Keep what you owe.

The Cathedral Framework is not a copy of existing design systems. It is an original architectural language that translates gothic cathedral geometry into digital UI — void-black backgrounds, manuscript gold illumination, Cinzel serif typography, and apex-light radial gradients. Every component reflects structural permanence: zero border-radius, stone-surface textures, illuminated medallions, and arch-top card borders. The system was built iteratively: first by extracting design tokens from 1Commerce, then by recognizing the pattern was too generic. The rebuild started from first principles — what does "cathedral" mean in software? Answer: weight, permanence, light sourcing from a single apex point, and a sense of being inside a constructed space. Result: A design language that is immediately recognizable, defensible, and impossible to confuse with any other SaaS platform.

Kai was integrated not as a chatbot overlay, but as a structural component of the platform. The integration spans three layers: 1. **Floating Chat Widget** (DashboardLayout): Context-aware from current route (Dashboard, Money Manager, Gig Command). Injects live user data (earnings, shift count, miles, tax deduction) into AI prompts. 2. **Dedicated /ai-assistant Page**: Full-screen chat with conversation history sidebar, context selector (10 contexts), suggested prompts, and new/delete/clear controls. 3. **Embedded Insight Panels** (Money Manager, Gig Command): Collapsible "AI Insights" cards that pull live suggestions from user data without leaving the page. The system uses `invokeLLM` server-side with system context that changes per page. Dashboard gets earnings summary context. Gig Command gets platform/mileage context. Money Manager gets tax deduction context. Result: AI that feels native to the platform, not bolted on. Every page can surface AI insights without requiring a dedicated chat page.

The Stripe → Meta CAPI bridge is the critical link between commerce transactions and Meta's advertising algorithm. Without this bridge, every paid conversion is invisible to Meta, which means higher CPM and CPL over time. The implementation: 1. **Stripe Webhook Handler** (/api/stripe/webhook): Listens for `checkout.session.completed` events. Extracts customer email, order amount, and metadata (user_id, customer_name). 2. **CAPI Event Fire** (firePurchase): Calls Meta's Conversions API with: - event_name: "Purchase" - event_id: Stripe session ID (deduplication) - user_data: email, phone, first/last name, city, state, zip - custom_data: value (order amount), currency (USD) - test_event_code: Configured via environment variable for event validation 3. **Webhook Signature Verification**: Stripe signs all webhooks with HMAC-SHA256. The handler verifies the signature before processing to prevent spoofing. 4. **Idempotency**: Event IDs are Stripe session IDs, so duplicate webhooks don't create duplicate CAPI events. Result: Every paid conversion is immediately fed to Meta's algorithm, which learns your customer profile and optimizes future ad delivery. This is the highest-leverage integration for paid acquisition.

Scroll-triggered animations are a common UX pattern, but they are often implemented poorly — using scroll event listeners that fire hundreds of times per second, causing jank and battery drain. UnifyOne uses the modern IntersectionObserver API, which is performant and declarative: 1. **useScrollReveal<T> Hook**: Accepts a ref to a container and an array of child elements. Sets up an IntersectionObserver with threshold 0.1 and rootMargin -40px (bottom). When an element enters the viewport, it adds the `reveal-visible` class, which triggers the `animate-rise` keyframe. 2. **CSS Keyframes**: `@keyframes animate-rise` moves elements from `transform: translateY(40px); opacity: 0` to `transform: translateY(0); opacity: 1` over 0.6s with cubic-bezier easing. 3. **Accessibility**: Respects `prefers-reduced-motion` media query. If the user has enabled reduced motion, animations are skipped entirely. 4. **Staggered Delays**: Each child element has a `data-reveal-delay` attribute (in milliseconds). The hook applies a CSS custom property `--reveal-delay` which is used in the animation-delay property. Result: Smooth, performant animations that enhance the "cathedral being constructed" narrative without causing performance issues.

Commerce is an optional, secondary capability of UnifyOne — the platform leads with gig earnings and taxes — but for the operators who turn it on, multi-tenancy is not just a database feature. It is an architectural decision that affects every layer of the platform. UnifyOne implements four isolation layers: 1. **Database Layer**: Tenants table with unique slug. All data tables include tenant_id foreign key. Row-level security (RLS) policies enforce tenant isolation at the database level. 2. **Authentication Layer**: Users belong to tenants. JWT tokens include tenant_id. Every tRPC procedure checks ctx.user.tenantId against requested resource. 3. **API Layer**: All tRPC procedures are tenant-scoped. No procedure returns data from other tenants, even if a user somehow bypasses the frontend. 4. **UI Layer**: DashboardLayout includes Tenant Switcher. Users can switch between tenants they own or have been invited to. Active tenant is stored in localStorage and passed to all tRPC calls. The schema includes 19 tables: tenants, users, products, orders, customers, subscriptions, webhooks, analytics, social_posts, referrals, leads, automations, and more. Each table is tenant-scoped. Result: A platform that can scale to thousands of tenants without compromising security or data isolation.