TIME TRACKER & INVOICING FOR LAW FIRMS

The heart of the firm's billing is the rate matrix: the same lawyer has a different rate for every client, and clients split into individuals and companies — every staff × client and staff × company pair holds its own hourly rate. The hard part wasn't the multiplication but guaranteeing that at invoicing time every time entry picks the right rate from the right dimension — a mistake here isn't a bug, it's a wrong amount on a real law firm's invoice. I sealed it into one flow: time entries × the rate matrix aggregate into per-client invoice line items, with no manual intermediate step.

Fakturownia has its own model of the world — and dirty data. The client sync must decide on its own who is a company and who is a private person (a three-step heuristic: the company field from the API → PESEL or a missing NIP with a first/last name → name patterns), and tax identifiers arrive in every format: NIPs with spaces and dashes, an 11-digit PESEL, foreign VAT like DE123456789. Naive digit-only cleaning lost the country code, so normalization has a separate branch for the two-letters-plus-5–12-digits pattern. Issuing the invoice itself proved a series of ambushes too: CORS in edge functions needed the Supabase client headers, occasional Fakturownia timeouts got a retry loop, and the amount is computed via the effective rate — per-client beats global — with line items grouped per lawyer and a database unique constraint blocking double-invoicing the same month.

Three roles with conflicting interests in one database are arbitrated by RLS — and RLS has its traps. Policies checking the role read the profiles table, but the policy on profiles also reads profiles: recursion. I solved it with a SECURITY DEFINER get_current_user_role() function with a pinned search_path (without it, that's an attack vector). The best lesson came during permission hardening though: revoking EXECUTE on that function from anon and public was right — but a moment later I also revoked it from authenticated, breaking every RLS policy for logged-in users at once. The GRANT came back four minutes later, and the whole footgun is documented in the history rather than swept away — because a security mistake you don't hide is worth more than feigned infallibility.

The project's most interesting bug was invisible: the list of companies to invoice for the current month was empty even though time entries existed. The cause turned out to be PostgREST's default 1000-row limit — the invoice wizard loaded all entries sorted ascending by date, so at ~1230 records it was precisely the newest ones getting cut off. I wrote the diagnosis down in a plan before the fix existed: cause, solution, file scope and a preventive rule. The fix changes the fetching strategy — entries load only for the selected period (a date range in the query) with a defensive limit — and the rule 'never fetch transactional tables wholesale' stayed in the project for good. Implicit platform limits are exactly the kind of knowledge tutorials don't teach.