FreelensFlow

The problem

A working freelancer runs their business across half a dozen tools that do not know about each other: a spreadsheet for invoices, a Kanban board for client work, a personal inbox for prospecting, and a stopwatch app for billable hours. The same client ends up existing four times under four slightly different spellings, and none of the four copies agree. That fragmentation is not just annoying — it is where the money leaks. Hours logged in one place never make it onto an invoice. A lead that went cold in the inbox is never connected to the proposal that was written for it. Revenue reporting becomes an end-of-quarter archaeology exercise rather than something you can look at on a Tuesday. FreelensFlow started from the observation that lead, outreach, proposal, project, time entry, invoice and payment are not seven products. They are one record moving through seven states, and almost all of the useful value lives in the joins between those states rather than in any individual feature.

Approach & architecture

The architecture follows from that premise: one Postgres schema in Supabase holds the whole lifecycle, and every module is a different view over the same spine rather than its own island of data. A lead is promoted into a client in place — the row keeps its identity and gains fields — so outreach history stays attached after the deal closes instead of being orphaned in a separate CRM table. Time entries reference project tasks; invoice line items are a projection over those entries rather than a re-typed copy of them, which is what makes 'which hours did I actually bill for?' a query instead of a reconciliation.

Authorization lives in the database rather than in the application layer. Postgres row-level security policies are the single gate: the API surface can be thin because a leaked or mis-scoped query still cannot read another account's rows. That decision is what makes the client portal cheap to build — it is not a second application, it is the same tables behind a narrower policy, so a client sees their own projects and invoices through the same code paths the freelancer uses.

Next.js App Router splits the work along the obvious seam. Dashboard reads are Server Components that query Supabase directly and stream, so the heavy financial and analytics views never ship their data-fetching logic to the browser. Client Components are reserved for the genuinely interactive surfaces — dragging Kanban cards, running a timer, building an invoice. Anything that must not run on the client or must outlive a request — sending an outreach sequence, generating an invoice PDF, reconciling a Stripe webhook — runs in a Supabase Edge Function with the service role, keeping privileged credentials off both the browser and the rendering layer. TypeScript types are generated from the database schema, so a column rename surfaces as a compile error rather than as an undefined at runtime.