BizBrain Lite
Documentation.

Product overview

BizBrain Lite is planned as a Windows desktop business-management application built around local-first data storage. The online Moavia infrastructure is intended for accounts, licenses, devices and billing, not for storing the user's daily business transactions.

Intended capabilities

• Business workspaces, daily sales and purchase records.
• Products, stock management and invoice workflows.
• Operational reports and customer/supplier records.
• Google-based Moavia identity with server-validated licenses.
• Local data ownership, explicit backup and restore.

These describe the target product scope; precise features must be confirmed against the final signed desktop build.

System requirements & installation

The exact minimum Windows version, RAM, disk space, installer architecture, code-signing certificate and official download URL have not yet been confirmed. Do not download BizBrain Lite executables from unverified third-party sources.

1. Obtain the official signed release from a verified Moavia download location when announced.
2. Verify the publisher and installer signature before running it.
3. Install the application using standard Windows permissions, avoiding unnecessary administrator access.
4. Launch BizBrain Lite; first-time Google authentication requires internet access.
5. Choose the intended local business workspace and create a backup strategy before real-world use.

Google sign-in & first-time onboarding

Browser-assisted authorization

1. From the desktop login screen, select Continue with Google.
2. The app creates a fresh PKCE challenge and calls POST https://moavia.dev/api/desktop/start with app_id: bizbrain_lite.
3. The desktop UI displays a short-lived eight-digit user code, and opens the returned browser verification URL.
4. Google sign-in occurs through the existing moavia.dev login page, not an embedded Google password form.
5. New users finish their Moavia profile (full name and country required, with additional optional details).
6. Compare the code shown in the software and enter it on the Moavia confirmation page; explicitly approve the device request.
7. The desktop app polls POST /api/desktop/poll with its original PKCE verifier, receives a one-use authorization result and validates the token via GET /api/desktop/me.
8. The token must be stored securely in the operating system's credential store. The local workspace must be linked by verified Moavia user ID, never just email.

Existing session and safety

The website's session cookie is not given to the desktop client. A desktop token is separate from both Google credentials and an active software license. The current implementation uses authorization requests valid for 10 minutes and identity tokens with a 30-day expiry; these values may evolve as the implementation is hardened.

Never share device codes with anyone who did not start the sign-in directly on your PC. If the website shows a request you did not initiate, select Deny.

Sign out and change account

Sign out should call POST /api/desktop/revoke, remove local credentials, clear in-memory auth and leave business data intact. Switching Google accounts must map the new identity to its own local workspace, without merging two users' invoices, products or finances.

Pricing, entitlements & renewals

All prices are USD. The fees, taxes, currency conversion and payment methods shown at live checkout will depend on the final payment provider and applicable location. A lifetime license remains subject to fraud, refunds and software terms. “Lifetime” does not guarantee unlimited future major upgrades or an indefinite online service commitment unless explicitly promised in published terms.

Monthly plan

Automatic renewal is the proposed default, but subscription checkout, renewal webhooks, cancellation portal and cancellation-effective date have not been implemented or confirmed. Failed renewals should affect access only according to an explicit grace-period policy.

Current backend status

The initial app_licenses migration defines none, trial and lifetime, not monthly. A new migration, separate subscription records, provider IDs, renewals and audited state changes are required before the $2/month plan can go live. There is currently no working purchase button on this subdomain.

Free trial lifecycle

Intended policy: Start the 30-day period at the first successful activation of BizBrain Lite on an approved device—not on creation of a Moavia website account. This ensures that signing into the website alone does not consume software evaluation days.

• Trial is linked to the Moavia user and cannot be reset by reinstalling the app, clearing local data or switching PCs.
• Trial can include up to two business workspaces.
• Three registered PCs is the proposed upper limit, consistent with the other plans.
• At expiry, display a clear upgrade path and preserve the local business database.
• Restrictions on editing, exporting and reading expired-trial records need a documented final UX policy before enforcement ships.

A new server-side /api/license/trial handler implements this one-time activation rule; see the implementation guide below. Deployment verification is pending.

Device activation & security

Each license may register up to three active PCs. The intended design uses a device-owned cryptographic keypair. The public key is registered on the server and the private key remains protected locally; device signing proves possession without depending solely on a changeable MAC address or Windows username.

1. Device registration is requested after identity verification.
2. Server checks account license, current device count and key ownership.
3. An existing active device may continue; a fourth new device must be rejected or require removing an old registration.
4. Authenticated self-service device listing and revocation now have website APIs and an account page; production deployment and native enrollment remain to be validated.
5. Revocation should take effect upon the next verified online or lease renewal check, subject to any bounded offline period.

Offline usage & verification

BizBrain Lite is intended to support local business work with unreliable internet connections. First-time identity verification, device enrollment and initial license activation require network connectivity.

Proposed signed offline lease

• License server issues a short, digitally signed, device-bound permission with user ID, plan, expiry and server-issued validity.
• The desktop app verifies its signature with an embedded public verification key; a local clock setting or editable JSON file is not enough.
• A seven-day offline lease is a design proposal, not currently implemented policy.
• After offline permission expires, the desktop app asks for online verification. A successful login alone cannot mint a new lease.
• Revocation cannot be enforced instantly against an intentionally disconnected PC; short leases bound this risk.

Manual clock rollback, VM snapshot restoration and altered local data need explicit test coverage. No unlimited offline bypass should be shipped.

Payments, verification & refunds

Lemon Squeezy is an option under consideration, not an activated billing processor. This site currently has no verified checkout, invoice-generation integration or automatic subscription renewal service.

Required payment verification flow

1. Signed-in user chooses Monthly or Lifetime.
2. Backend creates a priced checkout associated with the correct Moavia user and requested license plan.
3. The payment provider processes the purchase and sends a signed server-to-server webhook.
4. Backend verifies signature, event ID, transaction status, currency, price, product, account mapping and replay/idempotency.
5. D1 records a verified payment and updates the license atomically.
6. Desktop refreshes its license from the server and displays the actual entitlement.

The success redirect or a screenshot of a payment is not proof of entitlement. Refund, chargeback, failed renewal and cancellation events need auditable state transitions and idempotent handlers. No card details or Google passwords belong in the desktop database.

Local storage, backups & privacy

The intended separation is straightforward: business activity is stored locally, while Moavia stores only service metadata required for accounts and licensing.

Being local-first is not the same as having an automatic backup. Regular encrypted local/external backups, restore tests and clear ownership/migration workflows are required. Do not assume Cloudflare D1 contains a backup of your invoices. Visit Moavia Privacy Policy for the currently published policy, and ensure it is updated before any new telemetry or payments launch.

Developer integration reference

Identity origin: https://moavia.dev. These APIs are hosted by the main Moavia Worker, not by the public BizBrain Lite subdomain.

Desktop authentication currently uses 10-minute requests, minimum 5-second polling and 30-day tokens. Desktop Bearer tokens are identity credentials, not signed offline licenses and not proof of paid features.

POST https://moavia.dev/api/desktop/start
Content-Type: application/json

{"app_id":"bizbrain_lite","code_challenge":"<S256>"}

Implementation source is maintained in the xooja/moavia.dev repository: src/desktop-auth.js, src/worker.js and integrations/bizbrain_lite/moavia_google_login.py. Those are useful for integration, but production readiness requires live testing and security hardening, including throttling.

Admin & license management

The independent main Moavia admin service at admin.moavia.dev is intended to manage users, licenses, registered PCs, promo codes, payment records and audit events. BizBrain Lite's website is a public product and documentation site—it is not an admin dashboard.

• Admins must require authorization, audit writes, and least-privilege controls before granting or revoking entitlements.
• Account users should eventually see their own plan, next renewal and device list without receiving admin rights.
• Manual account status must not falsely represent an unverified card payment as paid.
• The separate Linkdger Oracle infrastructure and lladmin.moavia.dev are out of scope.

The current status and availability of individual admin operations must be checked against the actually deployed build.

Troubleshooting

Cannot connect to Moavia

Check connectivity to https://moavia.dev, system TLS trust and your firewall. Never disable certificate validation.

Code rejected or request expired

Start a fresh desktop authorization session and enter the exact eight digits shown inside BizBrain Lite. Requests expire after about ten minutes in the current implementation.

Sign-in worked but software remains locked

Authentication is not a license. The license verification service may not be deployed yet, or there may be no eligible entitlement for the account.

New computer cannot activate

Three active registered PCs is the planned limit. Self-service device management is not yet live; do not try to defeat registration by copying private credentials between machines.

Monthly upgrade not available

Checkout, subscription schema and renewal webhooks are still pending. Do not pay through unofficial links.

Business data missing after changing account

Check that the correct verified Moavia identity is matched with the correct local business workspace. Switching accounts must not automatically combine or delete workspaces.

Need help?

Visit Moavia Developer. A product-specific support email and SLA have not been confirmed; never send passwords, complete bearer tokens or private device keys to support.

Trial, promo and device API — implementation guide

Source code is implemented; production deployment and database migration require verification. User controls are at Moavia Plans & Licensing. Google sign-in still runs on moavia.dev, and all paid checkout buttons remain unavailable pending real payment verification.

Production prerequisites

1. Ensure existing 0002_bizbrain_licensing.sql and 0006_desktop_auth.sql are applied to the same moavia-auth-db.
2. Apply additive migration 0007_license_device_challenges.sql.
3. Deploy the main Moavia Worker with /api/license/* routed through the Worker.
4. Verify live login, trial activation, promo redemption, three-device maximum and device revocation before release.

API endpoints

Authorization and request examples

Desktop clients send Authorization: Bearer <desktop-token>. Website calls use the existing moavia_session cookie, with same-origin checks on writes. The desktop token verifies identity but is not a signed offline license.

POST https://moavia.dev/api/license/trial
Authorization: Bearer <desktop-token>
Content-Type: application/json

{}

POST https://moavia.dev/api/license/promo
Authorization: Bearer <desktop-token>
Content-Type: application/json

{"code":"YOUR-PROMO-CODE"}

GET https://moavia.dev/api/license/status
Authorization: Bearer <desktop-token>

For device enrollment, call /api/license/device/challenge, sign the exact returned challenge text with a device-owned ECDSA P-256 private key using SHA-256, and POST the challenge_id, URL-safe base64-encoded raw signature, and JSON-stringified P-256 public JWK to /api/license/device/register. The server verifies the signature and consumes the challenge. The private key must remain in protected OS storage. Device session signing for every API call and signed offline leases are still pending.

Trial, promo & device activation API (new)

Implementation: Source code committed on the main Moavia Worker. Requires migrations 0002, 0006, 0007 and 0008 in the production D1 database. It is not confirmed live until deployed and tested.

Users can manage their own plan, trial and promo codes at Moavia Plans & Licensing. This page uses the existing signed Moavia browser session and same-origin requests. Desktop clients use a verified Authorization: Bearer <desktop_token> header from the completed Google device authorization flow.

Example — redeem a promo

POST https://moavia.dev/api/license/promo
Authorization: Bearer <desktop_token>
Content-Type: application/json

{"code":"YOUR-MOAVIA-PROMO"}

Example — device enrollment

Generate an ECDSA P-256 keypair locally; retain the private key in Windows secure key storage. Request a new challenge, sign the exact UTF-8 challenge string using ECDSA SHA-256, then send the challenge ID, base64url signature and public JWK serialized as JSON with device_name and platform. Never transmit the private key. Register only after an eligible license is active.

POST https://moavia.dev/api/license/device/register
Authorization: Bearer <desktop_token>
Content-Type: application/json

{
  "challenge_id":"<UUID from challenge>",
  "signature":"<base64url ECDSA-SHA256>",
  "public_key":"<JSON-encoded EC P-256 public JWK>",
  "device_name":"Office PC",
  "platform":"Windows"
}

The server accepts only valid, one-time device proofs and refuses a fourth active PC. Revoking a device does not erase local business data. The current Device Registration API does not issue a complete offline license lease. Do not let the Desktop UI treat login or registration alone as paid access.

Important availability notes

• Trial: The current website's explicit Start Trial action starts the 30-day timer. It is not automatically delayed until after device registration.
• Promo: Migration 0008_atomic_promo_redemption.sql adds database triggers that atomically reject reuse, over-capacity, expired or user-ineligible redemptions.
• Monthly: The current schema does not support monthly plan values. Checkout buttons stay disabled until a verified billing integration is ready.
• Offline: Signed lease issuance, renewal and device possession verification on later requests are future work. Never manufacture local entitlement data.
• Security: Add production Cloudflare rate limiting, monitoring, and a migration check before enabling the APIs for public users.

Release checklist & roadmap

All functionality advertised as planned must be validated and updated before the public release. A documentation status is never a substitute for a tested release.