Waving Knowledge / Customer experience / 26 October 2026
A home for
every avatar.
Design the full journey before connecting real accounts and payments: a customer signs in, requests generation and reviews an avatar preview. Only then do they see a quote and decide whether to purchase and download.
The commercial model
- Prices appear only in the ordering flow, after the generated avatar has been previewed. The quote identifies an initial project, an additional avatar or a revision.
- One licence covers one avatar identity across supported platforms. Web is the first delivery target. Native desktop, iPad and Android downloads appear only after release.
- Hosted AI, cloud speech and custom engineering are separate. Final tax treatment, licence wording and preparation estimates must be configured before live sales.
- The server decides price eligibility from paid, active licences. A URL, browser flag, unfinished checkout or typed email cannot unlock the additional-avatar price.
The customer area
| Section | Customer’s task | Key states |
|---|---|---|
| My avatars | Find an avatar and create another | Empty, preparing, ready, action needed |
| Downloads | Get acquired files and setup material | Available release, preparation, planned platform |
| Orders & billing | Follow payment and preparation; access receipts | Pending, paid, failed, refunded, disputed |
| Licences | See which identity each licence covers | Active, suspended, revoked |
| Account | Manage profile and sign-in methods | Verified email, Google link, data requests |
| Help & guides | Install the package and request help | Setup guide, FAQ, support contact |
Account first, without a password
- Offer Continue with Google and an email address field. Email sign-in sends a short-lived, single-use code. Existing customers use the same entry point.
- Verify the email code or Google identity on the server, then create a secure session. Preserve the customer’s intended destination after sign-in.
- Bind all orders, photos, licences and releases to the authenticated customer. Do not ask for a separate order email at payment time.
- Require verified account control before linking a Google identity to an existing email account. Use Google’s stable subject identifier, not the email as its identity key.
Google sign-in will require an OAuth client configured for the final domain. The server must validate tokens and the sign-in request. Google’s server verification guide ↗
Generate, preview, then purchase
- After sign-in, choose a photograph, name the avatar and confirm permission to use the likeness. Existing customers can request a revision of an owned avatar.
- Validate the request and enqueue generation. The customer can leave and return while the single GPU processes accepted requests.
- Publish a quality-reviewed avatar preview. The customer sees the result before requesting their quote.
- Show a quote for the initial project, additional avatar or revision only in the ordering screen. Bind it to the reviewed version; confirm final scope, terms and tax before payment.
- Open Stripe Checkout only after the customer accepts. A verified paid webhook unlocks the approved version and queues final packaging, not another avatar generation.
- Deliver the purchased package through the customer account. Preserve existing purchased versions when a revision is requested.
Read the generation service architecture and download the SVG diagram →
Database foundation
A dedicated wavingknowledge database has been created on the existing PostgreSQL 17.9 server. It uses a separate owner and restricted application role; both are currently unable to log in. The wk schema is empty. No customer records or authentication credentials have been created.
The revised model separates generation requests, jobs and immutable avatar versions from later quotes and purchases. The earlier SQL draft is superseded by the generation architecture and remains unapplied.
The existing order service still uses SQLite and private order links. Connecting the new account API requires a deliberate migration; this HTML prototype does not change the existing payment service.
Implementation sequence
- Review this HTML: account entry, new customer, purchased library, first and additional purchases, downloads and order progress.
- Implement identity: PostgreSQL migration, transactional email, verification codes, Google sign-in, secure cookies, CSRF protection, rate limits and account recovery.
- Connect commerce: authenticated orders, queued generation, approved previews, version-bound quotes, Stripe sandbox payments and idempotent webhook processing. Claim any legacy orders only after verifying account and order access.
- Deliver material: operator preparation queue, private versioned releases, email notifications and account-authorized downloads.
- Launch checks: prove account isolation, test refund and dispute handling, confirm product terms, photo retention, backups and the actual downloadable package.
What works in this prototype
Email, Google and generation journeys are demonstrations only. Kenji is a prepared sample; your photo is not generated. No email is sent, no Google token is requested and no payment is made. Sample data is stored in this tab’s browser session; selected photographs stay in memory and are not uploaded. The sample guide is a real download, clearly marked as a demonstration document.
Use the account selector in the customer area to compare an empty account with one that has purchases. The sample payment handoff leads back to the order list for final packaging of the already reviewed avatar.