The visible feature was only the surface
Sharing links, expiring text/code, and QR payloads often requires separate tools and gives users little control over slugs, access, expiry, or basic view/click records.
The system also had to respect concrete constraints. Password protection is application access control, not safe secret storage. Click/view logging has privacy and retention implications. Installed Redis and checked-in Docker artifacts are not documented as active/reliable runtime paths.
My role covered product design and full-stack engineering, with responsibility for product workflows, data boundaries, and delivery.
I turned the constraints into boundaries
Next.js localized URL/text/QR UI; server actions/routes for creation, redirect, and access checks; Prisma/MongoDB persistence; authentication, validation, and QR/browser-share adapters.
Put URLs and text shares on one persistence/access model.
Enforce expiry/password/view limits at the server path.
Document inactive/stale infrastructure instead of advertising dependency presence as a capability.
The key decision: Put URLs and text shares on one persistence/access model.
The implementation had to prove the model
I delivered the work across the full path: Implemented custom-slug URL creation and redirects. Added text/code shares with language/visibility/expiry/password/view settings. Built QR customization/download/copy/share. Modeled persistence and account/localization flows with validation/tests.
The result is concrete: Users can shorten and track links. Share bounded text/code. Create reusable QR payloads. Apply supported access and lifecycle controls while understanding their privacy limits.
The senior engineering lesson was that solving the visible workflow is only half the job. The architecture must also make constraints, failure modes, evidence, and ownership explicit enough for the next change to remain safe.