George Ramsay is the founder and current operator.
Early-access privacy notice
What information the product uses, and why.
This notice describes the current early-access Investing by The Assembly Method product. The product is still changing, so this page is intentionally limited to practices that can be supported by the current implementation.
Last updated August 25, 2026.
Assembly Method does not hold brokerage cash or securities.
Email the business contact for access, correction, deletion, or deactivation requests.
01
Who is responsible for this service?
Investing by The Assembly Method is operated by Assembly Method LLC, a Utah limited liability company. George Ramsay is the founder and current operator.
Privacy and account-data questions can be sent to George@TheAssemblyMethod.com.
02
What information is used?
The exact information depends on whether someone only joins early access or creates and configures an authenticated investing account.
- Early-access information: email address, an optional note about what makes investing difficult, bounded referral/source and campaign fields, submission timestamps, and confirmation-email delivery state.
- Authentication and profile information: account identity used by Supabase Auth, optional display/profile information, and the state needed to sign in and recover access.
- Investment preferences: settings such as risk tolerance, time horizon, notification cadence, account goals, dividend preferences, and position-level boundaries when those features are used.
- Brokerage connection and account information: Webull connection status, selected account metadata, portfolio or holdings information needed to review the connected account, and explicit per-account automation permissions.
- Protected Webull connection material: the current owner-testing bridge may collect a Webull OpenAPI App Key and App Secret through the authenticated product flow. Reusable Webull SDK token state may also be retained for the protected worker. The normal Webull username and password are not collected by this connection path.
- Operational records: service status, run summaries, audit events, timestamps, bounded error or delivery state, and related records used to operate, reconcile, and troubleshoot the service.
Do not send brokerage credentials through email, chat, or an early-access form. Protected brokerage connection material belongs only in the authenticated connection flow.
03
Why is the information used?
Current uses include:
- recording and responding to early-access interest;
- authenticating users and keeping owner-scoped product state separate;
- connecting and synchronizing the supported brokerage account;
- producing portfolio reviews, recommendations, explanations, and user-authorized automation;
- respecting risk, account, position, pause, and emergency-stop settings;
- sending requested or configured product communications;
- operating, securing, reconciling, debugging, and improving the early-access service.
Joining the early-access list by itself does not connect a brokerage account or authorize trading.
04
Which services are involved?
The current architecture relies on outside service providers to perform specific product functions. Those include:
- Supabase for browser authentication, owner-scoped application data, and the protected Vault path used by the current Webull OpenAPI connection.
- Webull as the supported brokerage and custodian for connected brokerage assets.
- Vercel for hosting the public web application.
- Google Cloud Run for the bounded early-access confirmation-email service.
Information may pass through these providers when needed to perform the associated function. This notice does not claim a security or compliance certification that has not been separately verified.
05
How are brokerage secrets handled?
Ordinary browser-readable tenant records are designed to use opaque references and account metadata rather than raw provider credentials or provider account identifiers.
For the current owner-testing bridge, Webull OpenAPI App Key/App Secret values and reusable SDK token state are kept behind a protected Supabase Vault route. Protected workers can resolve that material when needed for the owner-scoped brokerage connection. Authenticated browser roles do not receive decrypted Vault values.
This developer-key flow is an early bridge, not the intended general consumer onboarding model. The product roadmap calls for a more appropriate broad-user connection path before general multi-user rollout.
06
What becomes public?
The product publishes a separate public methodology and reproducibility surface. That transparency work is limited to reviewed methodology files, public-safe policy values, calculation examples, and evidence standards.
Private customer, account, brokerage, credential, and portfolio data is not published as part of the methodology transparency work.
07
How long is information kept?
The early-access product does not currently publish a fixed automated deletion schedule, and there is not yet a self-service privacy dashboard. Information is retained as needed to operate and evaluate the current service unless it is removed or the product's retention practices change.
During early access, requests for access, correction, deletion, or full deactivation are handled manually. Email George@TheAssemblyMethod.com with the email address associated with the account or early-access signup and the requested action.
Assembly Method will review the request against the current product state and confirm the action taken rather than promising a deletion timeline that the system does not yet automate.
08
How is information protected?
The current implementation uses owner-scoped database rules, protected service-role operations, explicit broker-permission controls, and a Vault-backed path for the current Webull OpenAPI secrets. Audit metadata is designed not to contain credential values.
No internet-connected system can promise absolute security. Users should keep their authentication and brokerage security controls current and report suspected unauthorized access promptly.
09
What happens when the product changes?
This notice should change when the product's material data practices change. The current version and last-updated date are published on this page.
Before a paid public plan or broader brokerage onboarding is launched, this notice should be reviewed again against the production data flows.