Amir Khan
Back
2 min read

Ocular

Ocular is a robust SaaS platform designed to centralize and streamline transaction tracking and inventory management for multi-channel businesses.

Overview

Ocular empowers business owners to consolidate sales data from various platforms—such as Shopify, Amazon, and physical retail outlets—into a single, unified dashboard. The project was born out of the need for a simplified, low-overhead management system for growing e-commerce brands.

The Problem

Many small to medium-sized businesses face significant operational hurdles when selling across multiple channels:

  • Data Fragmentation: Sales data is scattered across different platform dashboards, making it difficult to get a holistic view of business performance.
  • Inventory Mismatches: Lack of a centralized product catalog leads to inconsistencies and manual update overhead.
  • Restricted Collaboration: Owners often have to share primary credentials with staff or pay for expensive per-seat licenses just to record basic transactions.

Tech Stack & Architecture

The architecture follows a Modular Feature-based pattern combined with a custom Service Layer. This decoupling ensures that UI components remain "pure" while all complex database queries and data mapping logic are centralized in dedicated service hooks.

Key Features

  • Unified Transaction Ledger: A centralized repository for recording and viewing sales and returns across all connected platforms.
  • Centralized Catalog Management: A single source of truth for products, brands, and SKUs.
  • Granular Staff Access Control: Owners can provision accounts with specific permissions (read or readwrite), allowing team members to assist in operations safely.
  • Real-Time Analytics: Visual insights identifying top-performing products and profitable sales channels.

Technical Challenges & Solutions

Multi-Tenancy via PostgreSQL RLS

Instead of relying on an application-level authorization layer, I pushed the multi-tenancy constraints directly to the database using PostgreSQL Row Level Security (RLS). Every table is protected by strict policies, ensuring that queries are scoped strictly to the authenticated user's business_id, guaranteeing data isolation at the lowest possible level.

Optimized Service Pattern

To handle the complexity of multi-channel data, I developed a service pattern that abstracts the Supabase client. This allows for easier testing, better error handling, and a cleaner API for the frontend components to consume, resulting in a 40% reduction in redundant data-fetching code.