Enterprise Compliance Monitoring Platform

Business Problem

Compliance tracking was spread across department-owned spreadsheets with no shared structure and no way for anyone outside a department to see status without asking. Deadlines were missed not because the work wasn't being done, but because nobody had visibility into it until a review surfaced it as overdue.

Business Context

The organization required a centralized compliance monitoring solution to improve visibility, standardize compliance tracking, and reduce manual monitoring across teams that were previously tracking obligations — such as product permissions, fire licences, and other statutory and regulatory requirements — independently, in spreadsheets. I identified this business problem and built the platform using AI-assisted development, working with Claude to accelerate implementation while owning the business and product decisions myself: the requirements, the functionality, the user experience, and the rollout.

Stakeholders

The platform is used by two main groups: Compliance Owners, who add and manage compliance obligations, and Compliance Monitors, who oversee status across two monitoring roles covering different organizational locations. Management and reporting stakeholders consume rolled-up visibility without collecting it department by department. I act as Super Administrator — the product owner and AI-assisted developer responsible for the platform end to end.

Requirements

Requirements were gathered directly from department stakeholders — what they needed to track, how urgency actually varied across very different obligations, and what a usable day-to-day workflow looked like for people who wouldn't be trained extensively on a new system. Those conversations were translated directly into the functional specifications and role model — Compliance Owners and Compliance Monitors — that I then implemented using AI-assisted development.

Functional Design

On the functional side, I focused on how the platform needed to behave for the people using it day to day: what a department view should surface first, what a management roll-up needed to show without requiring someone to dig, and what reporting output would actually get used versus ignored. I implemented this directly — the UI, the dashboard and reporting behavior, and the monthly, department-wise and user-wise report automation — using Claude to accelerate the build.

Key Responsibilities

• Identifying the business problem and designing the application concept
• Developing the application using Claude / AI-assisted development, and implementing it end to end
• Deploying and operating the application on AWS
• Owning the UI, features and functionality from the business and product side
• Defining the compliance-tracking workflow and the role model (Compliance Owners and Compliance Monitors)
• Serving as Super Administrator — managing users, roles and ongoing configuration
• Performing data validation and functional testing ahead of and after rollout
• Automating monthly management reporting, including management-level summaries and department-wise/user-wise reports
• Monitoring usage and continuously improving the solution based on feedback
• Supporting approximately 50 internal users across compliance owner and monitor roles

Technologies I Personally Used

Cross-functional Collaboration

Cross-functional collaboration here centered on department compliance owners and the two monitoring roles, rather than a separate engineering team — since I owned both the product decisions and the AI-assisted implementation myself. Requirement gathering, UAT cycles, and ongoing feedback loops with department owners and monitors shaped the workflow and role model, while automated monthly reporting kept management aligned without a separate collection exercise.

Business Outcomes

The organization now has one system for compliance tracking instead of department-owned spreadsheets, with standardized status visibility instead of point-in-time review meetings. The platform is actively used by approximately 50 internal users across compliance owner and monitor roles, with monthly management, department-wise and user-wise reporting automated directly from the system.

Lessons Learned

• Getting departments aligned on a shared framework mattered more to adoption than any individual feature — buy-in had to come before rollout, not after
• Translating business requirements into functional specs early reduced rework that would otherwise have surfaced late, during UAT
• Direct feedback loops with department owners surfaced real adoption issues faster than dashboard usage data alone

Reflection

What I learned: how much of a system's success depends on the functional layer between "what the business needs" and "what gets built" — a shared taxonomy that made sense to every department mattered more than any single feature.

What I would improve today: I'd push for a lighter, faster UAT cycle earlier in the process, so mismatches between department workflows and the functional design surfaced before the build was largely finished rather than during acceptance testing.

How I would approach this differently today: with more exposure to Microsoft Fabric and newer BI tooling since this project, I'd advocate earlier for embedding self-serve reporting directly into the platform, so department owners could answer their own follow-up questions instead of routing every new report request back through me.

Future enhancements: validated time-saved and efficiency metrics beyond current adoption figures, deeper Excel import handling for departments still migrating historical records, and department-level performance trends in the management view rather than point-in-time status alone.