Back to selected work

SaaS Product Case Study

Secure Record Viewer

A record data viewer platform that lets teams create access-controlled public views of their operational data — without sharing credentials or exposing the native admin UI.

This project turned record system into a backend for configurable, shareable data surfaces. The key challenge was designing an access model flexible enough to cover public links, password protection, and login-gated views — while keeping the record system connection secure regardless of which access mode was chosen.

Core result

Controlled external access

Teams can publish specific record data as external views with fine-grained access control. No record system login required for viewers — and no credentials ever leave the server.

Access modes

4 modes

Public, password-protected, login-gated, and signed URL — each viewer is configured independently.

server-side record proxy

Server-side only

All record API calls are proxied server-side. Credentials are never exposed to the browser regardless of access mode.

Audit trail

Per-request logs

Every viewer access is logged with auth mode and result — granted, denied, or error — for audit and debugging.

01

Problem

record data was only accessible through the native admin UI — which required admin credentials, offered no fine-grained access control for external viewers, and exposed far more surface area than most sharing scenarios needed. Teams had no way to share a specific operational view with an external partner or stakeholder without handing over login credentials.

02

Constraints

The record API token had to stay server-side regardless of which access mode was configured. Different viewers also needed different security levels — some views were safe to make fully public, others needed password gates or login requirements — without complex per-user record system setup.

  • source credentials must never reach the client regardless of viewer access mode
  • Schema cache needed to reduce live record API calls on every page load
  • Four access modes must be configurable per viewer without code changes
  • Access logs must be granular enough to debug auth failures across access modes

03

Approach

Each viewer is a configured wrapper around a source app. The access mode — public, password, login, or signed URL — determines how the platform authenticates the incoming request before proxying the record system fetch. The record system connection details and schema cache live in Supabase; the viewer page resolves the access check server-side before any data is returned.

  • Server-side server-side record proxy — all API calls happen in Next.js route handlers
  • Schema cache stored in Supabase to reduce live field-schema fetches
  • Access log per request with auth mode, result, and timestamp
  • Viewer status (draft / published / archived) controls public reachability independently of access mode

04

Dashboard Design

The management surface was designed for operators configuring and monitoring viewers, not engineers reading logs. The dashboard surfaces what matters: which viewers are live, how they are being accessed, and whether any access attempts are being denied.

  • Viewers list with status badge and access mode indicator at a glance
  • URL management for signed URL generation and rotation
  • Per-viewer analytics showing access patterns over time
  • Settings for source app ID, API token, and schema refresh per viewer

05

Outcome

Teams can publish specific record system views externally with the access model that fits the use case — a public dashboard, a password-protected partner view, or a login-gated internal link. source credentials stay server-side throughout, and every access attempt is logged for audit and debugging.

Continue Exploring

Document Template Studio is also live.

Each case study covers a different part of the stack — see how the same engineering principles show up across different problem types.

Read Document Template Studio