Studio
A single suite for utilities, private files, games, and workspaces, with executable registries and risk-based persistence.
- Next.js application shell
- Supabase Auth and data
- PostgreSQL and RLS
- Realtime and private Storage
The product tension
Useful tools die as unrelated demos: a new URL, a new nav, a new auth story. I needed one product a person can actually use—utilities in the browser, private files, games, and small workspaces—without turning the public portfolio into a junk drawer of every experiment.
What I built
I built Studio as a single Next.js suite. Catalog, tools, games, and account workspaces share a shell. The source of truth is not a CMS card; it is the runtime registries: inventory, surfaces, hub navigation, games, and the tools list. Tests fail when those drift from routes and SEO.
Public. Browser utilities stay local-first. Weather uses the public OpenWeather key. GitHub stats go through server routes.
Account. File Manager, Activity Tracker, Scratchpad, calculators, and Game Hub sit behind the shared session. src/proxy.ts strips client headers, calls getUser(), checks Studio membership and MFA assurance, then forwards verified identity. Auth owns the login UI; Studio only returns to a safe origin.
Data. The studio schema and private storage own files, game moves, and workspace rows. Realtime is a delivery channel, not the permission check.
How the system fits together
Registries describe what exists. The proxy classifies public vs protected. Domain APIs keep file, game, and tracker contracts from collapsing into one table.
The calls that shaped the build
- 01
I made the catalog executable
If a tool is not in the registry, it is not a Studio product. Documentation explains meaning; it does not invent pages. That keeps 87 utilities and nine games from becoming folklore.
- 02
I chose authority by risk
A formatter can live in Zustand. A signed upload, a game move, or an activity write cannot. Those go through authenticated routes, ownership checks, and RLS.
- 03
I did not put Studio demos on the Portfolio home grid
Tech Tools and Game Hub are capabilities inside Studio. Featuring them as sibling case studies would make the public site look like a student project list. They stay in the Studio catalog and this archive page.
Trust boundaries
Protected routes require a live session and Studio membership. Storage uses private policies and signed URLs. Realtime broadcasts accepted state; it does not authorize writes. Portfolio never imports Studio screens.
What I chose—and accepted
One suite means shared navigation and regression cost on every new tool. A pile of separate apps would have been faster to screenshot. I would rather operate one identity and one schema than explain twelve logins.
Why the work matters
Studio is a working catalog with public utilities and authenticated workspaces, not a mock. The Portfolio site points at the suite once. This page is the engineering record; the product is the shell at studio.jayantgoyal.com.
What I would improve next
I would add cross-product health signals on the highest-risk paths—signed file access and game-move RPCs—without coupling tool domains into one module.