HorizonID web foundation

Bounded proof app for design quality, auth-ready UX, and shared-stack planning.

Next.js 16 app routershadcn base-nova componentsrepo-local Node 22 toolchainbrowser-reviewed proof route
Foundation proof, not production

A HorizonID cabinet customers can actually trust after checkout.

This route proves the selected stack can support deliberate frontend quality, email-first auth, subscription visibility, and a shared business model with the existing Telegram bot.

Email access preview

Magic link, then cabinet sync.

Email sign-in paired with Telegram identity
Renewals, access state, and instructions stay in one cabinet
Website and bot read the same commercial truth

Pricing and checkout shell

A commercial surface with less guesswork.
quality gate: browser-backed
This proof avoids fake pricing claims. It validates layout quality, hierarchy, and cabinet-to-billing continuity before the real catalog and payment provider are wired in.

1-month purchase shape

Fast start

A direct entry plan for new users who arrive from Telegram or email.

checkout stays inside HorizonID
renewal handled from one cabinet

renewal-first shape

Continuity

A cabinet-led renewal flow with status, instructions, and fallback actions together.

shared subscription state
same billing truth for bot and site

Shared data model

The site reads the same subscription and payment truth instead of forking state.

Billing-ready surface

Checkout and renewal can attach to real product tables without rewriting the shell.

Renewal continuity

Status, device instructions, and recovery actions stay grouped after purchase.

Next section: wire the real catalog and billing intent without changing the cabinet shell.

Auth.js email path
Email-first auth without losing Telegram continuity.
The selected path centers on email login for the website, with Telegram remaining a linked identity rather than a second account silo.
Email login

Magic link sign-in avoids password reset friction for first launch.

Telegram link

One verified bridge connects the website account to the existing bot identity.

Session visibility

The cabinet can expose sign-in history, device actions, and renewal controls in one place.

Cabinet shell preview
Subscription state, renewal actions, and device help should remain on one compact screen.
Netherlands access is healthy

Device instructions, subscription status, and the primary reconnect action can stay visible above the fold.

Architecture notes baked into the proof surface.
The foundation is only useful if the visual shell and the data ownership model stay aligned.

Yes. Keep one PostgreSQL cluster on the control-plane host so the site, bot, and billing data can stay coherent. Split ownership with separate schemas instead of a second database unless a later scale boundary proves necessary.