Case study · 2025 – Present
Website, Client Management & Business Intelligence
A modular digital platform that connects a configurable public website with inquiry and client management, content administration, analytics and business intelligence. It grew from a real-world legal-services implementation into a reusable architecture for separate client deployments.
Role
Product Builder / Full-Stack Developer
Status
Live · Actively Developed
Deployment
One deployment per customer
Scope
Website → inquiries → clients → BI
Overview
The project started from a real client use case in legal services: a public-facing website backed by an administration area for content and incoming inquiries.
As the system grew, I rebuilt it around explicit product modules and shared infrastructure, turning a client-specific implementation into the first deployment of a broader reusable platform.
Today it connects public content, inquiry intake, client management, analytics and business intelligence through clear ownership and server-side boundaries. It intentionally focuses on acquisition and client operations rather than trying to become an all-purpose business management suite.
The problem
The initial problem looked like a website project, but the real need crossed the public and internal sides of the business. 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 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 from a legal-services use case: a professional public presence, editable content and an authenticated administration area.
Stage 2
The application was reorganized around explicit modules for inquiries, clients, content, service 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 a solo professional to grow into a small team through additional users, profile-driven public content and distributed content ownership.
Product surface
The product is intentionally broader than a website, but narrower than an all-purpose business management suite.
Configurable public pages, service areas, articles, FAQs, contact flows and editable Home/About content with administrative previews and controlled publishing workflows.
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, service areas and response workflows, combining platform-owned business data with real GA4 traffic when available.
Consent-aware GA4 measurement and first-party attribution capture connect acquisition context with downstream inquiry and client reporting.
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 service 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
Service-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. Billing, time tracking, private document management and deeper domain-specific workflows remain 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.
Outcome
Started as
A custom website and admin build from a legal-services use case became a reusable product architecture grounded in the original client problem.
Became
Public presence, content, inquiries, clients and reporting now operate as one coherent platform rather than separate tools.
Demonstrates
The project moved my work from page-level implementation toward product engineering across boundaries, workflows, security, data and operational trade-offs.
