MGM.TATZ

01

A home for the work. A system behind it.

MGM.TATZ is a custom portfolio and business website for independent tattoo artist Miles. The work combined visual design and full-stack implementation: an artist-first public experience backed by a focused owner publishing system.

Public experience: Artwork, drawings, flash, process, FAQs, and consultation intake under one visual identity.
Owner experience: Private drafts, deliberate publication, controlled placement, and FAQ management without code edits.

02

Beyond a social feed.

The artist needed a controlled, branded home for a body of work that social media alone could not organize. The engineering challenge was to keep unpublished artwork private, make published work reusable across the site, and separate consultation data from the public portfolio.

03

Finished work meets the sketchbook.

Near-black tattoo surfaces alternate with warm ivory drawing and process sections. Restrained warm-gold accents, editorial serif typography, thin architectural rules, graph-paper texture, and charcoal-like transitions support the black-and-grey, illustration-led identity. The artwork sets the hierarchy.

Historical Drawings page showing a paper-textured background, serif heading, and a rail of illustrated studies. — Development-era Drawings capture. It demonstrates the visual direction, not current production database contents.

04

One portfolio model. Several public views.

Next.js and TypeScript provide the public interface and server actions. Supabase supplies PostgreSQL, Auth, Storage, and row-level security; Vercel hosts the application. Gallery, Hero, Drawings, and Available Designs use the same canonical portfolio/media records with visibility and placement rules.

Interface & server: Next.js App Router → validated server actions and published-content queries.
Identity & data: Supabase Auth → application owner gate; PostgreSQL → owner allowlist and RLS.
Media & delivery: Supabase Storage → separate private and public buckets; Vercel → application deployment.

05

Publication is an explicit transition.

The owner can upload multiple images with per-file metadata and status, maintain private drafts, edit portfolio metadata, publish or unpublish work, control Gallery visibility, assign four Hero and four independent Drawings slots, and manage FAQs. Available Designs automatically selects published flash records.

Private authentication
Draft upload
Metadata review
Explicit publish
Public media
Gallery / Hero / Drawings / Available Designs

Publishing includes the image bytes: Server actions promote private media to public storage, update the record, and remove the draft after the transition succeeds. Failure paths include compensating cleanup and rollback; storage and database writes are not one atomic transaction.
Focused owner controls: This is a bounded publishing system. The artist portrait, much general site copy, and full style-tag assignment are not editable through the current admin. Multi-image ingestion processes files serially with independent outcomes.

Historical owner-admin screen titled Create a private draft, with empty title and type fields. — Historical private-draft creation screen. The later admin shell changed; this image documents the earlier workflow surface.

06

Explore the work, then start a conversation.

The public site brings together the Hero, Drawings/process, About, Gallery, Available Designs, and managed FAQs. Gallery visitors can use Type/Style filters, Featured/Newest sorting, six-item pagination, and a focused image dialog. Desktop and mobile navigation and filters share destinations and state-update logic across different presentations.

Available Designs is implemented: Published portfolio records classified as flash populate the catalog automatically. It is a visual catalog, without checkout, reservations, or payment handling.
Responsive behavior: Mobile uses a sticky disclosure menu and compact Gallery controls. The project verification record includes exact 375 × 812 checks.

MGM.TATZ Gallery with Type and Style filters above tattoo artwork tiles. — Development Gallery capture with Type/Style controls and sample records. It predates the final Available Designs navigation entry.

07

Private intake, with a clear promise.

The consultation form accepts a request and optional reference or body-area images. Validation and persistence run through a narrow server action; consultation tables and uploaded images remain separate from the public portfolio. Submission is a consultation request, not a confirmed appointment booking.

Historical consultation page showing its artwork background and empty name and email form fields. — Development consultation UI with empty fields. This capture shows the form; successful production persistence is separately owner-confirmed.

08

Separate identities, permissions, and media.

Supabase Auth establishes identity. Next.js checks the authenticated user against the server-side OWNER_USER_ID setting; PostgreSQL independently uses the owner_users allowlist and is_portfolio_owner() for RLS and owner-only functions. These are implemented controls, not a claim of comprehensive security certification.

portfolio-drafts · private: Unpublished image bytes stay in private Storage until explicit publication.
portfolio-media · public: Published image bytes are public. Public portfolio queries require published state; Gallery queries additionally require Gallery visibility.
consultation-intake · private: Anonymous users have no direct consultation table or Storage permissions. A validated server action uses a server-only privileged client as the controlled write boundary.

09

A working publishing system, with clear limits.

The evidence package supports the implemented owner authentication, private/public media workflow, published-only Gallery, independent art placements, flash catalog, managed FAQs, and consultation persistence architecture. Production media, owner login, and consultation submission on mgmtatz.com were owner-confirmed after configuration corrections. No business-performance outcome is claimed.

Production acceptance · moderate evidence: The supplied audit could not independently access the live custom domain. Deployment and configuration screenshots support the owner’s report; production actions were not rerun for this case study.
Open content & provider work: Some biography, studio, and process copy remains forthcoming. Newsletter provider code and mocked tests exist, but live activation and delivery remain deferred and unverified.

10

The boundaries are part of the design.

The most useful decisions connected a simple owner experience to explicit data and trust boundaries.

Canonical data prevents duplicate administration: Treating Gallery, Hero, Drawings, and flash as views or placements keeps publication changes consistent without separate copies of each work.
Published includes the bytes: Separating private draft storage from public media gives publication a concrete storage transition, beyond a database flag.
Authorization needs independent layers: The application owner gate serves navigation and user experience; database policy separately controls access to records and owner operations.
Responsive layouts can share behavior: Different desktop and mobile markup can still use the same navigation destinations and Gallery update path.
Evidence keeps outcomes bounded: Tests, migrations, source history, and acceptance records support functional claims while keeping unmeasured business outcomes out of the story.

11

Evidence, with its limits attached.

This case study adapts the supplied evidence package, audited on 2026-09-18 against main@874b2289. Screenshots above are historical implementation captures. Source, schema, Git history, recorded verification, and owner acceptance support different kinds of claims; they are identified separately below.