Building a portal that ends 'any update?' calls: the read-only sync architecture, the translation layer nobody plans for, and why the portal's hardest problem is language, not code. Public excerpt; the full log lives in the Builder library.
A case status portal is a small system with one job: answer the client's question before they call. The code is straightforward — auth, an API sync, a clean view. The build log below is mostly about the decisions, because that's where portal projects actually succeed or die.
Decision 1 — The portal writes nothing. It reads from the practice management system through its API and displays; it never becomes a second place where matter data lives. The moment a portal accepts edits or holds its own state, you've built a sync problem wearing a portal costume, and the firm now maintains two sources of truth.
Decision 2 — A translation layer between internal stages and client-facing status. This is the part nobody budgets for and everyone needs. Internal stage names are written for staff — some are jargon, some are unflattering, some are confidential in spirit ("awaiting client payment," "waiting on adjuster lowball"). Every practice area gets an explicit mapping: internal stage → client-visible status → one plain-language sentence about what it means and what happens next. That mapping is authored with the attorneys, not inferred by the developer.
Decision 3 — Show the timestamp. Every view carries "current as of" prominently. A portal's trust model is fragile: one moment of visibly stale data and clients resume calling — now with a screenshot. Freshness honesty keeps the trust; pretending to be real-time spends it.
Decision 4 — Matter-scoped auth, boring on purpose. Per-client authentication, access scoped to exactly that client's matters, encryption both directions, audit log of every login and view. Nothing novel — which is the point. Novelty in the auth layer of a legal portal is risk with no upside.
A raw stage name reached a client. One matter type's mapping was incomplete, and the portal fell back to displaying the internal stage — mild jargon, no harm done, but the gap was structural: fallbacks meant unmapped stages leaked by default. The fix inverted the rule. Unmapped stages now display nothing and page the admin — fail closed, because in a client-facing legal surface, silence beats leakage every time.
Clients read faster than the firm updated. The portal exposed a truth nobody had seen: some matter stages were updated internally in batches, days late. The portal was accurate about a stale system. The fix wasn't code — it was an internal working agreement on stage hygiene, with the portal's own "last updated" data as the scoreboard. Every portal build since includes that conversation up front.
The full build log — the stage-mapping worksheet we run with attorneys, the fail-closed display rules, the notification triggers worth sending, and the client-auth pattern — lives in the Builder library.
Implementation detail, checklists, and the parts we'd rather not have public — for members.
Unlock with Builder