Overview

Portfolio Analytics Dashboard is a web application built for freelance creatives who manage multiple clients but lack visibility into their business health. It aggregates project timelines, payment statuses, client engagement, and revenue forecasts into a single real-time dashboard — turning scattered spreadsheets and email threads into actionable business intelligence.

Problem

Most independent designers and developers track their work across 3–5 disconnected tools: a spreadsheet for revenue, a project tool for timelines, email for client communication, and an invoicing app for payments. There is no single view that answers: "How is my business actually performing this quarter?"

Research

Interviews with 25 freelancers uncovered consistent pain points:

• ▸88% used spreadsheets as their primary "dashboard" for tracking revenue
• ▸76% said they had missed invoice follow-ups because nothing surfaced overdue payments proactively
• ▸60% couldn't quickly answer "how many hours did I bill last month" without manually summing data
• ▸The average freelancer used 4.2 separate tools for what should be one workflow

We also found that freelancers didn't want a complex ERP — they wanted a clean summary view with smart alerts, not another tool to maintain.

Solution

The dashboard provides four core views:

Overview — Monthly revenue vs. target, active project count, outstanding invoices, and a rolling 12-month revenue chart.

Projects — A Kanban-adjacent timeline with each project's status, deadline health (green/amber/red), billable hours logged, and invoiced amount.

Clients — Lifetime value per client, average project duration, repeat engagement rate, and satisfaction score (manually entered or linked to a post-project survey).

Revenue — Income breakdown by client and project type, invoice aging report, and a 3-month forecast based on confirmed upcoming projects.

Technical Architecture

Database — PostgreSQL via Supabase, accessed through Prisma ORM. The schema centers on three core entities: Project, Client, and Invoice, with a TimeEntry table for billable hours.

API layer — Next.js Route Handlers provide RESTful endpoints for CRUD operations. Mutations are optimistically updated in the UI and reconciled on response.

Charts — Recharts renders all data visualizations. Custom chart components wrap Recharts primitives with consistent dark-theme styling and responsive containers.

Authentication — NextAuth with credential and Google OAuth providers. Each user's data is fully isolated via row-level security policies in Supabase.

Challenges Faced

Revenue forecasting required projecting future income from incomplete data. We settled on a conservative model: confirmed project value × (1 - probability of scope change based on historical data per client). This was imperfect but transparent — users could see the assumptions and override them.

Date math for invoice aging had more edge cases than expected: partial payments, disputed invoices, and retainers that renew automatically. Each required a separate invoice state machine rather than a simple overdue/paid boolean.

Chart responsiveness on mobile required abandoning Recharts' default responsive container in favor of a custom resize observer hook that recalculated chart dimensions on container size changes.

Results

• ▸Used actively by 18 freelancers in a private beta over 6 months
• ▸Beta users reported 35% faster invoice follow-up due to the overdue alert system
• ▸Average 2 hours/week saved on manual revenue reconciliation
• ▸0 critical bugs in production over the beta period

Future Improvements

• ▸Stripe integration for direct payment tracking without manual invoice entry
• ▸Time tracking widget (browser extension + native timer)
• ▸Client portal — read-only view clients can log into to see project status
• ▸Contract management with e-signature via DocuSign API
• ▸Tax export — generate quarterly estimated tax reports from revenue data

Learnings

The most valuable technical decision was modeling invoices as a state machine rather than a simple record with a status field. Each invoice has a defined lifecycle (draft → sent → viewed → partial → paid → overdue → disputed), and encoding the valid transitions explicitly prevented a class of data integrity bugs early on.

The product lesson: dashboards should answer questions users already have, not teach them new questions to ask. Every metric we added that users didn't ask for in interviews went unused. The final MVP was 40% smaller than the initial feature list, and satisfaction scores were higher for it.