Case study · 2025 – Present
Website, Client Management & Business Intelligence
A modular digital platform for legal practices that connects a configurable public website with inquiry and client management, content administration, analytics and business intelligence. Originally built for an independent lawyer, it evolved into a reusable architecture for separate client deployments.
Role
Product Builder / Full-Stack Developer
Status
Live · Actively Developed
Deployment
One deployment per legal practice
Scope
Website → inquiries → clients → BI
Overview
The project started as a digital platform for an independent lawyer: a public-facing website backed by an administration area for managing content and incoming client inquiries.
As the system grew, treating each feature as a client-specific addition became increasingly limiting. I rebuilt the application around explicit product modules and shared infrastructure, turning the original implementation into the first real deployment of a broader platform architecture.
The current platform connects the public website with content administration, inquiry intake, client management, analytics and business intelligence while keeping those capabilities separated through clear ownership and server-side boundaries.
The product is intentionally not a full legal practice-management system. It focuses on digital presence, client acquisition and internal client workflows rather than matters, billing, document management or time tracking.
The problem
The initial problem looked like a website project, but the real need crossed the public and internal sides of the practice. Content had to be manageable without code changes, inquiries needed to become structured internal work, and the client needed visibility into what actually generated useful inquiries and clients.
That created a product-design problem as much as a coding problem: the public site, admin CMS, inquiry pipeline, client records and reporting had to feel like one coherent system without collapsing into one tightly coupled codebase.
The platform also handles sensitive contact and legal-intake data, so security, authorization, auditability and recovery could not be treated as optional infrastructure added after the UI was finished.
Product evolution
The product changed shape as the original use case exposed a larger system worth structuring for long-term growth.
Stage 1
The first version solved concrete needs for an independent lawyer: a professional public presence, editable content and an authenticated administration area.
Stage 2
The application was reorganized around explicit modules for inquiries, clients, content, practice areas, analytics and shared platform concerns instead of continuing as a collection of one-off client features.
Stage 3
The platform can support separate client deployments while also allowing an individual practice to grow internally through additional users, lawyer profiles and distributed content ownership.
Product surface
The product is intentionally broader than a website, but narrower than full legal practice-management software.
Configurable public pages, practice areas, articles, FAQs, contact flows and editable Home/About content with administrative previews and controlled publishing workflows.
Consent-aware GA4 measurement and first-party attribution capture connect acquisition context with downstream inquiry and client reporting.
Public and manual intake, status workflows, assignment, filtering, exact protected-field search, internal notes and operational attention states.
Manual client creation and inquiry-to-client conversion, duplicate handling, responsibility management, lifecycle states, notes and linked inquiry history.
Commercial and operational reporting across acquisition, content, practice areas and response workflows, combining platform-owned business data with real GA4 traffic when available.
Supabase-backed identity is combined with application profiles, role-based permissions, protected server operations and an additional administrative session policy.
Important administrative actions are audited while sensitive inquiry and client fields are protected at the application boundary and kept out of audit metadata.
The project includes migration discipline, Sentry monitoring, automated encrypted PostgreSQL backups and unit, integration and browser-level test coverage.
Product in use
A few selected views show how the public experience, operational workflows, content management and reporting connect inside the same product.
01 · Inquiry management
New inquiries move through a visible pipeline with practice-area context, responsibility and explicit progression toward contact or conversion.
02 · Client management
Converted inquiries stay connected to the client record, alongside responsibility, lifecycle state, internal notes and recent activity. The relationship between acquisition and ongoing client operations is kept visible instead of being split across separate tools.
03 · Content administration
Practice-area pages expose publishing, SEO, imagery, structured page content and preview controls from the same administration surface that owns the operational workflows.
04 · Business Intelligence
The reporting layer follows the commercial path from traffic to inquiries, relevant inquiries and clients, while keeping platform-owned business data separate from external traffic analytics.
Architecture
System map
Next.js App Router
URL · HTTP · rendering · cache composition
Core · Security · Permissions · Audit
Cross-module application boundaries
PostgreSQL
Business truth
Supabase
Auth · storage
GA4
Traffic only
Engineering decisions
Sensitive data
01Sensitive Inquiry and Client values are encrypted before persistence using application-level authenticated encryption. Separate blind indexes support exact search for selected protected fields without making ciphertext deterministic.
Permissions & audit
02Protected mutations pass through server-side permission and action boundaries, and important business/security operations are written to a dedicated audit history.
Transactional workflows
03Inquiry-to-client conversion is handled as a transactional workflow so client creation or reuse and inquiry conversion cannot leave the system in a partially converted state.
Business data truth
04Business Intelligence treats the application database as the source of truth for inquiries, clients and conversions. GA4 is used only for traffic and acquisition dimensions, and mock analytics is never presented as live business performance.
Fresh operational state
05Public content uses explicit cache ownership and invalidation, while operational views such as the dashboard are read at request time to avoid presenting stale queue state as current information.
Delivery discipline
06GitHub Actions validates dependency installation, Prisma generation and migrations, unit tests, TypeScript and the production build against an isolated PostgreSQL environment; broader integration and Playwright suites are run separately.
Trade-offs
The goal was not maximum feature count. It was enough structure for the current product without absorbing complexity before it became necessary.
A customer-per-installation model reduces authorization and data-isolation complexity today. Runtime multi-tenancy is deferred until there is a concrete product reason to absorb that complexity.
The platform deliberately stops at website, inquiry, client, content and reporting workflows. Matters, billing, time tracking and private client-document management are outside the current scope.
GA4 can enrich reporting with traffic data, but lead validity, client conversion and commercial outcomes always come from platform data so external analytics cannot silently redefine business results.
The current deployment has strong application boundaries, encryption, auditing and recovery procedures while intentionally deferring higher-cost infrastructure such as distributed rate limiting, managed PITR and enterprise secret tooling until usage justifies it.
Started as
What began as a custom website and admin implementation for an independent lawyer became a substantially more reusable product architecture without discarding the original real-world use case.
Became
The result is one coherent platform that connects public presence, content, client acquisition, internal client workflows and business reporting rather than maintaining those concerns as separate projects.
Demonstrates
For me, the project marks a shift from page-level implementation toward product engineering: defining boundaries, workflows, security decisions, data semantics, operational safeguards and trade-offs around a real system.
