Localhost Is Not a Portfolio Link

A site running on your laptop is a development environment. It is not a link. Paste a localhost address into an email and it resolves on the recipient’s machine, where nothing is listening. They get a connection error and a bad first impression of your work.

Anything you want a stranger to open needs three things: a hosted deployment, a name that still makes sense in six months, and enough framing that a visitor knows what they are looking at before they start clicking.

Give the case study and the demo different jobs

For Zehnai Living we run a case study on the main Zehnai site and a separate deployment for the interactive build. The case study carries the brief, the implementation notes, and the limitations. The demo carries the experience and nothing else. Splitting them means we can redeploy the demo whenever we want without touching the studio site’s runtime.

On the work page, the primary link opens the case study. A clearly labeled secondary action opens the live build. If a project is not published yet, it gets an honest local-only or in-progress status instead of a button that dead-ends. A screenshot is a perfectly good stand-in until the deployment is ready.

Name the project once, name it well

Zehnai Living says what the project is. A generic label like Website Agency says nothing and ages badly the moment a second project shows up. Vercel assigns a vercel.app address per project, confirmed at deploy time. A branded subdomain such as living.zehnai.com can come later if we want a consistent family of demo links, but that means configuring the domain against the project. It is not a text edit on an anchor tag.

Review before you publish

Vercel separates development, preview, and production for a reason. We check a preview deployment before pointing anyone at production. A green local run is necessary and not sufficient — the hosted build is where asset paths, environment configuration, runtime differences, and access protection actually get exercised.

Keep each deployment lean

A release directory should hold what the site needs to run and nothing else. Screenshots from a review pass, abandoned design explorations, font conversion exports, and scratch notes do not belong in a public asset directory — they ship, they get indexed, and someone eventually finds them.

Every project keeps a traceable line back to its source files and its deployment settings. That is what makes the next update a fifteen-minute job instead of an archaeology exercise, and it stops two unrelated demos from quietly sharing state.

Walk the visitor’s path, not the deploy log

Start on the studio site and move the way a visitor would: open the project, read the case study, launch the demo. Confirm the final URL, the heading, the images, and one or two interactions that matter. Then run the same path at phone width.

A successful upload proves files reached a host. It says nothing about whether the route from a work page to a working demo holds together.

Search treatment follows the same split. The article and the case study get descriptive titles, canonical URLs on the main site, and sitemap entries. The demo itself can stay noindex. The explanatory page is the one we want ranking; the demo is the thing we hand people directly.

The pattern we apply to every new concept

• One Vercel project per standalone concept, with its work entry living on Zehnai
• Ship on the assigned vercel.app link first; add a branded subdomain only when it earns its keep
• Keep a small registry: project name, source location, local run instructions, deployment name, live URL, work-page URL
• Leave the status as local-only until the hosted page has been opened and verified by someone who is not signed in

None of this is elaborate. It is a checklist. But it is the difference between a portfolio that opens and one that quietly breaks in someone else’s inbox.