Privacy policy

Who runs Solvency

Solvency (solvency.dev) is operated by Roy Dhanda. Questions about this policy or your data: [email protected].

What is collected, and why

Reading the site

Nothing that identifies you. Pages are static files served by Cloudflare. Cloudflare Web Analytics records aggregate page views (page URL, referrer, browser type, country) without cookies, without fingerprinting and without storing IP addresses against visits. Cloudflare's own network logs, which may include your IP address, are governed by Cloudflare's privacy policy.

On the Build Composer, cookieless product analytics may also record coarse interactions: opening the planner; adding a role; making a first edit that leaves a valid quote; saving, duplicating, restoring or choosing a baseline version; the export format; role count; whether any custom rate is present; an unlisted-link draft's expiry and export setting; an alert draft's trigger type; and a directional response to the $19/month price question. These events include the page path. They do not include plan or harness names, model selections, token counts, entered prices or thresholds, downloaded file contents, account details or email addresses.

Your light/dark theme choice is stored in your browser's local storage and never sent anywhere. If you start account sign-in from the Build Composer, one valid canonical draft may be held in that tab's session storage so an OAuth redirect does not discard it. That temporary copy is limited to 64 KiB, expires after 30 minutes, is removed when read or discarded, and is not uploaded until you explicitly choose an account save action.

Fonts are served from solvency.dev itself; no font request goes to a third party.

Creating an account

The calculator's custom scenarios require a free account. Sign-in is handled by Clerk, which stores:

• your email address;
• your name and avatar if you sign in with Google or GitHub, as provided by that service;
• a session cookie so you stay signed in;
• sign-in timestamps and IP addresses, for account security.
• the page and account feature that prompted sign-up, so Solvency can understand which free or planned feature was useful;
• the current scenario URL at sign-up and up to 20 scenario URLs you choose to save.

When you sign in with Google or GitHub, Solvency asks only for your basic profile and email. It never sees your password, and it cannot read your repositories, mail or files.

Signup intent and scenario URLs are stored in Clerk's client-writable account metadata. They are used for product research and the free save-link feature; they are never trusted as authorization for a paid feature. Your email is used to sign you in and to tell you about material changes to Solvency's data or terms. It is not sold, rented or shared with advertisers. If a newsletter is introduced it will be opt-in.

Saving Build Composer account plans

When account plan storage is available and you explicitly choose “Save to account,” Solvency stores the canonical plan and immutable versions in Cloudflare D1 under your verified Clerk account ID. Stored plan data can include plan and harness names and versions, model and role choices, routing volume, token usage, success assumptions, harness costs, custom or contracted token rates, provenance choices, server-generated quote snapshots, and save timestamps. Custom and contract rates may be commercially sensitive; do not enter them unless you are comfortable storing them with this service.

This data is used only to let you list, reopen, compare, version and delete your own plans and to operate the account-plan service. It is not copied into product analytics, advertising profiles or Clerk's client-writable metadata. Account ownership comes from the verified Clerk session on every request.

If you create an unlisted link for an immutable account-plan version, D1 stores the plan and version reference, expiry choice, quote-export choice, creation time and a one-way SHA-256 hash of the link's bearer token. Solvency does not store the readable bearer token in D1. Because the bearer token is part of the URL, it can still appear in the recipient's browser history and in Cloudflare's ordinary request and security logs. Anyone who receives the link can view the selected plan and server-generated quote until the link expires or you revoke it; that can disclose internal harness names, usage assumptions and custom or contract rates contained in the selected version. The shared response does not include your Clerk account ID, email or other account profile data.

If you save alert settings, D1 stores the selected plan and version, trigger type, any threshold or comparison-baseline version, and timestamps. These settings are explicitly inactive: no monitoring job runs, no account email is stored with the setting and no message is delivered. The product will say separately if monitoring becomes active in the future.

During pre-launch product and pricing validation, Solvency uses seven closed first-party signal names in one server-selected signal version and the closed pro_19_monthly_190_annual_v1 price experiment. A signed-in browser can submit only a random event UUID and one of four names: planner started, valid quote created, export downloaded or Pro price interest. Browser-origin signals can be initiated or replayed by the user, so Solvency treats them only as untrusted, directional distinct-account signals—not as proof that an action occurred. The other three names—account plan saved, unlisted link created and inactive alert setting saved—are generated by the server only after the corresponding authenticated D1 operation succeeds.

For each signal row, D1 stores only the closed event name, server-selected signal version and price-experiment ID, a random event UUID used to make retries idempotent, your verified Clerk account ID, a server receipt timestamp and a 90-day expiry timestamp. It does not store the request body, page path, plan or harness names, model choices, token counts, prices, rates, thresholds, exported files or bearer URLs in these rows. During that 90-day window, D1 accepts at most one row per account, event name, signal version and price experiment, with a hard upper cap of 512 retained rows per account. The browser endpoint accepts exactly the UUID and allowed name and does not return submitted event fields.

For abuse prevention, D1 also keeps one rate-limit counter row per verified Clerk account ID. It contains only the current minute bucket and a capped request count; request contents are not logged in that row. The row is included when active account data is erased.

Solvency Pro billing

Solvency Pro is processed by Stripe on its hosted pages. Stripe processes the contact, billing address, billing email and payment method you enter there. Solvency does not receive or store your complete card number or card security code, no card data ever touches Solvency. A test checkout, when explicitly enabled in preview, uses Stripe test mode, does not create a real charge and is identified as a test before you open it.

For an enabled billing flow, Solvency sends Stripe the server-bound customer identifier, server-selected product price and billing cadence, quantity and checkout mode, fixed return URLs, and a short session expiry needed to create or manage the hosted session. D1 stores the resulting Stripe customer and subscription identifiers under your verified Clerk account ID, the allowlisted price identifier and quantity, currency and interval, subscription status, current-period end, cancellation setting, and the minimum event identifiers, timestamps and one-way payload hashes needed to reject replayed or conflicting webhook deliveries, never Stripe's raw webhook payload. To prevent overlapping payable checkout sessions, D1 also keeps one owner-linked checkout-attempt row containing a SHA-256 request hash, a random generation token, state, bounded expiry times, a nullable short reconciliation token and, only after successful Stripe Session creation and durable receipt, the Stripe Checkout Session ID. While a completed Session receipt is waiting for verified subscription authority, that row also stores the exact Stripe Subscription ID. Solvency does not store the raw browser idempotency key or hosted Checkout URL in that row. Browser-supplied customer IDs, price IDs, amounts and entitlement claims are not trusted. These records are used only to operate billing and determine server-side access.

Deleting your account removes these billing records along with the rest of your account data, except records Solvency or Stripe must keep to meet tax and accounting obligations. Those records are kept for up to 7 years after account deletion and used for no other purpose.

Shared scenario links

A calculator link encodes the scenario's settings (task tier, volume, retry model, cache rate, takeover cost) in the URL. It contains nothing about you. Anyone you send it to sees only those settings. This is separate from an account-plan unlisted link, which opens the immutable plan and quote described above.

Who processes data

Cookies

The site sets no cookies for reading. Signing in sets Clerk's session cookie, which is strictly necessary for the account to work. There are no advertising or cross-site tracking cookies, so no consent banner is shown.

Your rights

You can list and reopen your active Build Composer plans in the product and delete a plan there. Deleting a plan removes its active D1 plan record and cascades to all of its active versions, quote snapshots, unlisted-link records, inactive alert settings and operation-replay records; every affected unlisted link stops resolving. To see, correct, export or delete all account data, email [email protected] from the address on the account; the active account records, including Clerk, D1 plan, share, alert, billing-authority, product-intent and per-account rate-limit records, will be deleted within 30 days. Residents of the EU, UK, California and other jurisdictions with data-protection law have the rights those laws grant, including access, correction, deletion and portability; the same email address handles all of them.

Retention

Active account and saved-plan data is kept while the account or plan exists and is deleted as described above. Revoked unlisted-link records are deleted immediately from the active database; expired link settings and inactive alert settings remain with the plan until you remove them or delete the plan or account. Operation-replay records are authoritative for at most 24 hours; an expired row is ignored and is pruned on that account's next operation or when its plan or account is deleted. An owner-linked product-intent row expires after 90 days; it is ignored after expiry and is pruned on that account's next product-intent write or when the account is erased. If billing is enabled, D1 keeps the active customer and subscription authority while the account exists and keeps normalized webhook receipts for up to 90 days so replays and conflicting deliveries can be rejected. A checkout-attempt receipt is not replaced merely because its 32-minute Stripe Session expiry passes: it remains blocked through a three-minute grace, then requires strict retrieval and validation of the exact Session under an atomic reconciliation lease. Before 72 hours, an exact expired Session with no subscription permits a fresh generation. A Session with a subscription permits replacement only when an atomic check matches that exact subscription and customer to current canceled or incomplete_expired authority; otherwise the exact Subscription ID remains stored and blocked pending a matching verified terminal webhook. unpaid remains blocked. Open, completed-without-subscription or ambiguous results remain blocked with backoff. At 72 hours, receipts normally require manual review; one narrowly authorized exact-Session check is allowed only when current D1 authority already proves a terminal subscription for the owner's bound customer, and it replaces only if the retrieved non-null subscription matches that exact terminal row. Any mismatch or inconclusive aged result requires manual review. Stale creating attempts also require manual review. The row is removed when its billing customer or account is deleted. Cloudflare may retain encrypted disaster-recovery or provider backups for a limited period under its backup and deletion processes before they age out; those backups are not available in the product and are not used for another purpose. Stripe may retain transaction and payment records for the periods required by law and its fraud-prevention, tax and accounting obligations. Aggregate page-view and cookieless product-interaction analytics are kept indefinitely; they contain no account identifier or raw Build Composer inputs.

Children

Solvency is not directed at children under 16 and does not knowingly collect their data.

Changes

Material changes to this policy are dated at the top of this page and, for account holders, announced by email.