From sitemap to the Nexpanion website: what a demo did not solve

What the demo proved

The first version helped me test the visual identity, layout, and basic journey across Home, Notes, Resources, Now, About, and Contact. It also included sign-in screens and Vietnamese–English switching.

Most functions still lived only in the browser. Accounts were not stored, downloads were generated locally, and pages used hash-based routes.

The problem with hash routes

An address such as #/vi/notes/... is not an independent page handled by the server. To make the content easier for search engines to discover, I moved every post to a real URL with its own title, description, canonical URL, and server-rendered HTML.

An account needs a real benefit

I kept sign-in because members will use it to download templates and workflows. Supabase was selected for email/password accounts, Google sign-in, and private file storage. A download works only with a valid session.

Each language needs its own set of pages

Vietnamese is the source version. English has a separate URL, a self-referencing canonical, and matching language annotations. I lock the meaning of the Vietnamese copy before translating so the two versions do not drift.

Email and measurement need user-level tests

I used test addresses to check email confirmation and member status in MailerLite. Public newsletter sign-up is paused until the sending, confirmation, and unsubscribe flows have been checked again in production.

Google Analytics loads only after a reader agrees. I also added a footer control that reopens this choice, then checked the test session in Realtime. One CSS rule once kept the banner visible after consent; browser testing caught it before the release package was frozen.

How I tested the release

The launch candidate has 42 internal URLs across two languages. I checked the response status, H1, canonical URL, and search-verification tag on each one. I also tested email sign-in, Google sign-in, sign-out, blocked downloads while signed out, and all four downloads with a valid session.

Before touching the public site, I unpacked the release in a separate directory on the server and repeated the checks. The existing site remained unchanged, keeping deployment and rollback separate from the rehearsal.

The lesson so far

AI can generate an interface quickly, but product requirements still need to be explicit. A production website also needs data, access control, email, measurement, security, legal content, and an update process.

If you are building a site with AI, keep a separate checklist for the parts a visitor cannot see. Authentication, file permissions, email, analytics, and rollback do not create impressive screenshots, but they determine whether you can operate the site after launch day.