Privacy Notice — almwell.io

Effective: 2026-05-04 Last updated: 2026-09-25

This Notice covers what almwell.io does — and does not — collect, and what we do with it. It covers the marketing site and the Almwell app (accounts, home records, and payments).

Change log. 2026-07-11 — added the PostHog product-analytics and Google Ads conversion-measurement disclosures. 2026-09-05 — added the payment-data disclosures in §3, §4, §6, and §7 to match the paid products described in the Terms of Service, §4; named the address, coordinate, and home-record fields we store in §3; and added the §6 entries for Google Places, the Google Solar API, Rentcast, Anthropic, and Google Fonts. Those five were already running when that update was published. 2026-09-09 — added the §6 entries for Cloudflare (receipt file storage), Sentry (error monitoring), Open-Meteo (climate data), and Plaid (bank connections); corrected the Rentcast, Solar, and Anthropic entries to say we store and send whole payloads rather than a short list of fields; and corrected §7, which said cached property and solar lookups “expire” when nothing deletes them. Those four providers were also already running when they were listed. Listing them late is a miss against the fourth hard rule below, and we are recording it rather than quietly backdating it. 2026-09-09 (second update, same day) — review of that update found four more false statements, now corrected: Postmark is also our inbound mail provider and receives every receipt you forward, attachment included; Cloudflare R2 holds your inspection reports and system photos, not only your receipts; inspection-report PDFs go to Claude whole, on the same footing as receipts; and PostHog receives the amount you paid, the Stripe identifiers, the ZIP and budget you entered on the intake quiz, and the name of a bank you connect — the “no financial data” claim it replaced was wrong. 2026-09-10 — a third review pass found the Plaid entry false in the other direction: it said we did not have Plaid’s account-data feature enabled. We do — the code asks for it, pulls a year of transactions on connection, and re-pulls nightly. What is missing is the production credential, not the feature. §6 now says so, and §3, §4, and §7 carry the bank-transaction path that was disclosed nowhere. The same pass corrected §6’s description of where our server-side PostHog events come from: our controllers, our Stripe webhook endpoint, and the background job that finishes an assistant turn — not the receipts mailbox. 2026-09-10 (second update, same day) — a fourth pass found §7 silent about the one deletion we do run on a timer: an account that finished the intake quiz but never started checkout is deleted 14 days later, with no request from you. §7 now has a line for it. 2026-09-17 — a fifth pass found the 30-day server-log retention in §7 and §8 backed by nothing: the deploy caps each container’s log by size, 10 MB, and never by age. Both now say so. 2026-09-25 — collapsed the published contact addresses in §10 to one, hello@almwell.io; the Receipts inbound address is described in §3 as a product inbox rather than published as a contact address. Same date: the raw email behind a forwarded receipt is no longer deleted on a 30-day timer. The framework default deleted it whether or not you still had the receipt it produced, which contradicted §7’s promise to keep your data for the life of your account — the timer is off, and §7 now says what runs instead.

We have a small number of hard rules we treat as load-bearing — if any of them ever stop being true, we will say so on this page before that change ships:

• We do not sell your data. Not in the legal-definition sense. Not in the colloquial sense.
• We do not share your data with realtors, title companies, or any other marketing partner. Co-branded Snapshot relationships do not give partners access to who visited almwell.io. Running the site does require the service providers listed in §6, and each of them gets only what §6 says it gets.
• We do not run third-party ad-tech or behavioral advertising trackers on almwell.io, with one narrow, disclosed exception: Google Ads conversion measurement (see §3), which tells us whether our own Google ads lead to a purchase. It does not give Google — or anyone — access to who you are, and it is not an audience-sharing or data-sale arrangement.
• If we add a new data collection tool or share your data with a new service provider, this page will list it before that change ships.

1. Who we are

This site is operated by Ryan Clark, doing business as Almwell. Almwell is not yet incorporated; we will update this section when Almwell, Inc. is formed. Our contact address is in §10.

2. Scope

This Notice applies to almwell.io — Almwell’s marketing site and the Almwell app (accounts, home records, and payments).

3. What we collect

• Server access logs. When your browser requests a page from almwell.io, our hosting provider records the request URL, the timestamp, your IP address, the HTTP method and status code, response size, the referrer URL (if your browser sends one), and your User-Agent string. Standard web-server fields, nothing else.
• Account information. When you create an account, we collect your email address and (optionally) OAuth identity from Google or Apple. We use this to authenticate you and send transactional email (confirmation, notifications).
• Home record data. Information you enter about your home — its street address, city, state or region, and postal code, the latitude and longitude of that address, plus year built, square footage, system ages, past work, and priorities — is stored in your account and used to generate your priority plan. Producing that plan, and the cost estimates and suggested options in the app, sends the relevant home record details to Anthropic (see §6).
• Address lookup (Google Places). The address field on the home form uses Google’s Places autocomplete. Google’s Maps JavaScript loads in your browser and receives what you type into that field, character by character, so it can return suggestions. This happens as you type, on the form where you first enter a home and on the edit form for a home you have already saved. If that script fails to load, the field falls back to plain manual entry and Google receives nothing.
• Property, solar, and climate lookups. Once your home record has an address, we send that address — street, city, state or region, and postal code — to Rentcast to retrieve the public property record for it; we send the latitude and longitude to Google’s Solar API to estimate the roof’s sunlight and solar potential; and we send the same coordinates to Open-Meteo for last year’s daily temperatures at that point, which is how we describe your heating and cooling climate. If we do not yet have coordinates, Open-Meteo gets your postal code instead. All three are calls our server makes, not your browser. None of the three receives your name, email address, or account id. What comes back is stored on your home record, and the provider’s full response is kept in our own lookup cache. We re-query after 30 days; the older response is not deleted (see §7).
• Home analysis (Anthropic). Your priority plan, cost estimates, intake preview, suggested options, and the in-app assistant are generated by Claude, which is run by Anthropic. What we send is drawn from your home record and your intake answers: city, state or region, postal or ZIP code, year built, square footage, system ages and system facts, past work, budget, deadline, and the messages you write to the assistant. On that path we do not send Anthropic your street address, your latitude and longitude, your name, or your email address. The files you send us are the exception, and they are separate: receipts and home inspection reports both go to Claude whole — see the next two bullets.
• Receipts you email in. The app has a Receipts feature with its own inbound address, shown on the Receipts page inside your account. It is a product inbox, not a contact address, and mail sent there is processed automatically rather than read as correspondence. Mail sent there reaches the app through Postmark, our inbound mail provider (see §6). We store each attachment in a format we read — PDF, JPEG, PNG, GIF, or WebP — in Cloudflare R2 (see §6), along with the sending address and the subject line. We go by the format the message declares for each attachment, not by inspecting the file. An attachment declared as any other format (HEIC, for example) is kept only inside the stored original message described next; it produces no receipt. A file whose declared format is one we read produces a receipt even if the bytes are something else — a HEIC photo sent to us labelled as a JPEG makes a receipt. We also store the complete original message exactly as it arrived — body text, all headers, and every attachment, including file types the Receipts feature does not read. That copy is written when the message arrives, before anything is parsed, so a message that carries no receipt at all is still stored even though nothing is extracted from it and no one reads it. We keep that copy for the life of your account, and nothing deletes it on a timer — see §7. We run automated text extraction over each of those readable attachments to read the vendor, date, total, and line items, so the spend lands against the right home system; that step sends the attachment itself to Anthropic (see §6). The file goes to Claude exactly as you sent it, so whatever is printed on it goes with it — a service address, your name, or location data embedded in a phone photo. We keep both the file and the extracted fields on your home record. We attach the receipt to your home record only when the sending address matches a confirmed Almwell account and our email provider reports a passing DKIM check for the sending domain. Two things stop the text extraction: an attachment we cannot attribute that way is stored but is not linked to any home record and is not read, and once more than ten attachments have arrived for your account within an hour, the rest of that hour is stored and attributed but still not read. You can delete any receipt from the Receipts page. You can also upload the same files directly there, which skips email entirely — an uploaded file goes to Anthropic for the same extraction. See §6 for the providers in that path and §7 for retention.
• Inspection reports and system photos. You can attach a home inspection report (PDF) to your home record, and a photo to any system on it. Both are stored as files in Cloudflare R2 (see §6). The inspection report is also sent to Claude whole, exactly as you uploaded it, so we can read system ages and specs out of it. A home inspection report normally prints the property’s street address on its first page and often the owner’s name, and all of that goes with the file. System photos are stored and shown back to you; they are not sent to Claude. Retention for both is in §7.
• Product analytics (PostHog). We run PostHog on almwell.io pages to measure the signup funnel and how the app is used. PostHog captures page views and named product events (for example landing_view, signup_started, account_created). PostHog also automatically records interaction telemetry on the pages you visit — clicks, scroll depth, and rageclicks — to help us improve the site. Session replay: PostHog’s session-replay feature is disabled in our JavaScript configuration. We do not record page sessions. We configure PostHog with person_profiles: 'identified_only', which means anonymous visitors are not recorded as billable PostHog persons — their events are captured without a linked profile. Signed-in users are identified to PostHog by their Almwell user ID and their email address. Some events come from our server rather than your browser, and those carry more than a page name: a completed checkout sends the amount charged and the Stripe session id; finishing the intake quiz sends the ZIP code, budget, and deadline you entered; connecting a bank sends that institution’s name. What you paid and the budget you told us are financial information, and PostHog gets them — an earlier version of this page said otherwise, which was wrong. PostHog does not receive your street address, your latitude and longitude, or the contents of any file you upload. See §6 for the provider entry.
• Advertising conversion measurement. We run Google’s conversion tag (gtag.js, part of Google Ads) on almwell.io so we can tell whether clicks on our own Google ads lead to a purchase. The tag sets Google advertising cookies in your browser (for example _gcl_au and _gcl_aw) and sends Google the pages you visit on almwell.io along with an ad-click identifier when you arrived from one of our ads. We use it only to measure our own ad campaigns. See §6 for the provider entry.
• Payment data. When you buy a Home Priority Plan or a Home Membership, checkout happens on Stripe’s hosted page. You give Stripe your card details; Stripe gives us back a customer reference. What we store on your account row is: a Stripe customer id, a subscription id, the subscription’s status, price id, amount, billing interval, the current period end date, and the timestamps of your checkout and payment. We never receive or store your full card number, CVC, or bank credentials.
• Bank connections (Plaid). The plan page has a Bank accounts section that connects a bank through Plaid (see §6). Opening that page loads Plaid’s script and tells Plaid your IP address and User-Agent whether or not you connect anything. If you connect a bank, your bank credentials go to Plaid, not to us — but the transactions do come to us: the last 12 months at connection and a fresh pull each night, each one kept as its date, amount, merchant, and category alongside Plaid’s full response. We also send the connected institution’s name to PostHog (see the PostHog bullet above). Nobody can connect a bank today — the production Plaid keys are not deployed, so the request fails and we hold no transaction data for anyone. This bullet describes what the shipped code does the moment those keys are added, disclosed now rather than then.
• Inbound contact email. If you email us at the address in §10, we receive your email content, your address, and any attachments you send. Porkbun forwards that mail to a personal mailbox we read (see §6). The Receipts inbound address described above is different: Porkbun forwards it on to Postmark, which accepts the message and posts it into the app — so both providers handle the receipt file attached to it (see §6).

We do not collect: your phone number, card numbers or bank credentials (those go to Stripe, never to us), or device fingerprints. Nowhere on almwell.io do we ask you for a card number. If one is printed on a receipt you send us, it arrives inside that file; the fields we read off a receipt are the vendor, date, total, and line items, and a card number is not one of them. Beyond the cookies set by PostHog and the Google Ads tag (described above), we set only the cookies needed to run the site itself (such as a sign-in session cookie).

4. How we use it

• To serve the site, debug it, and protect it from abuse (server logs).
• To authenticate you and communicate with you about your account (email, account data).
• To store and display your home record and priority plan (home record data).
• To find your address as you type it, and to look up the public property record and solar potential for it (Google Places, Rentcast, Google Solar).
• To do the automated reading and drafting inside the product — pulling fields out of receipts and inspection reports, and generating your priority plan, cost estimates, intake preview, suggested options, and assistant replies. This runs on Anthropic’s Claude models (see §6).
• To store the receipts you email in or upload, read their vendor, date, and amount, and attach them to your home record (receipts).
• To measure and improve the signup funnel and product experience (PostHog analytics).
• To measure whether our own Google ads lead to a purchase (Google Ads conversion tag).
• To take payment, deliver what you bought, renew or cancel a subscription, and issue refunds (payment data).
• To show and categorise the spend from a bank you connect against the right home system (Plaid transactions).
• To answer your email when you write to us (inbound contact email).

We do not use any of the above to build a behavioral profile for advertising, to sell to third parties, or to train models on your personal data.

5. What we do not do

• We do not sell your data — under the CCPA/CPRA “sale” definition, under the colloquial definition, or under any future definition that is reasonable on its face. If you are a California resident, you have nothing to opt out of, because we are not selling.
• We do not share your data with realtors, title companies, brokerages, lenders, insurers, or any third-party marketing partner. Co-branded Snapshot programs do not give partners access to almwell.io visitor data.
• We do not run Google Analytics, Meta Pixel, or any cross-site behavioral advertising tracker. We run PostHog (disclosed in §3) for first-party product analytics, and the Google Ads conversion tag (disclosed in §3) for measuring our own ad campaigns. Neither is an audience-sharing or cross-site tracking arrangement.
• We do not set tracking cookies beyond the PostHog and Google Ads cookies disclosed in §3, and we set no other cookies except those required to operate the site (such as sign-in sessions).
• We do not sell, rent, license, or otherwise transfer your data as part of a marketing or research agreement.

6. Service providers

We use a limited set of third-party services to run the site. Each receives only what is needed for its function, under a written contract or standard provider terms that limit use to providing the service:

• Hosting: Hetzner Online GmbH. The Rails app runs on a single Hetzner box and receives the server access logs described in §3 as part of normal operation.
• DNS and email forwarding: Porkbun, LLC. Porkbun resolves almwell.io DNS and handles all inbound almwell.io mail. It forwards the contact address in §10 to a personal mailbox we read, and forwards the Receipts inbound address described in §3 on to Postmark. A receipt you forward passes through Porkbun’s relay first, so Porkbun handles that message and the file attached to it.
• Transactional and inbound email: Postmark (ActiveCampaign, Inc.). Postmark does two jobs for us. Outbound: it delivers account confirmation and notification emails, so we send it your email address and the content of those messages. Inbound: Postmark is also the mail provider for the Receipts inbound address described in §3. Mail forwarded there is delivered to Postmark (inbound domain pm.almwell.io, MX → inbound.postmarkapp.com), and Postmark posts the whole message into the app together with its own authentication results. That means Postmark holds every receipt file you forward, whatever is printed on it, along with your sending address and the subject line. The app attaches a receipt to a home record only when Postmark reports a passing DKIM check for the sending domain and the full sending address matches a confirmed Almwell account; the app does not verify the signature itself. It does not receive anything you type into the app itself.
• Product analytics: PostHog, Inc. Two separate paths reach PostHog. The JavaScript snippet loads on almwell.io pages in production and captures page-view, funnel, and interaction events (for example landing_view, signup_started, account_created; plus autocapture of clicks, rageclicks, and scroll — input field contents are masked). Our server sends a second stream directly from the app, with your browser uninvolved: from the controllers that handle your requests, from our Stripe webhook endpoint, which Stripe calls directly, and from a background job — the one that works through an assistant turn after your request has already finished, which sends the chat thread and home ids and how many suggestions the assistant wrote, and none of what either of you typed. Those server events carry the properties named in §3: the amount charged and the Stripe session id when a checkout completes, the ZIP code, budget, and deadline from the intake quiz, and the institution name of a bank you connect. PostHog’s session-replay feature is disabled in our JavaScript snippet. We do not record page sessions. For anonymous visitors, no person profile is created (identified_only mode). For signed-in users, PostHog receives their Almwell user ID and email address for identity resolution. PostHog processes this data under its DPA. It does not get your street address, your coordinates, or any file you upload — no receipt, inspection report, or system photo.
• Address autocomplete: Google LLC. The Google Maps JavaScript API (Places library) loads in your browser on the home form and receives the characters you type into the address field so it can return suggestions. Google processes this under the Google Maps Platform terms. It receives no other field on that form and no account identifier from us.
• Property records: Rentcast. We send Rentcast your home’s street address, city, state or region, and postal code as a single query string. We store Rentcast’s entire response, not a selected subset: we read year built, square footage, lot size, bedrooms, bathrooms, property type, and last sale date out of it and show you those, and we keep the full payload — including fields we do not use, such as owner and tax history, when Rentcast returns them. Rentcast receives no name, no email address, and no account id.
• Solar potential: Google LLC. We send the latitude and longitude of your home from our server to the Google Solar API. We read the roof and sunlight estimates out of the reply and store the entire response, including the parts we do not display. That request carries the coordinates and nothing else — no street address, name, email address, or account id.
• AI generation: Anthropic, PBC. Claude generates your priority plan, cost estimates, intake preview, suggested options, and assistant replies, and reads the receipts and home inspection reports you send us. Anthropic receives the fields named in §3, plus those files themselves. On the generated-content path — plan, estimates, preview, options, assistant — it does not receive your street address, your coordinates, your name, or your email address; the most specific location we send is your city, state or region, and postal code. The assistant is switched on for every Almwell account — there is no per-account setting that turns it off. A message you send it never travels alone: each request carries that message, up to eight earlier turns of the same conversation, a snapshot of your home record (city, region, year built, square footage, and your system and fact entries), and the names of the priorities already on that home. That first request is not the end of it. The assistant can ask us for more of your home record mid-answer, and whatever it asks for goes to Anthropic in the next request of the same conversation. It can ask for four things today: your priorities in full, including the sentence in your own words that we captured each one from; your projects — their titles, status, timing, where each one came from, its rank, the priority it is linked to, and which project is waiting on which; your systems and facts in full, including where we got each value and how sure we are of it; and your spending — stored receipt rows for that home (vendor, amount, date, and system tag) and your per-system spend totals. Assume the whole of what you have entered about your home is reachable this way, not only the snapshot in the first request. §3’s limits on what PostHog receives describe PostHog only; they do not describe Anthropic. The two file paths are different. We upload a receipt and an inspection report byte-for-byte, so anything printed on either one reaches Anthropic: a service address or your name on a contractor invoice, the property’s street address and often the owner’s name on the first page of an inspection report, and any location data a phone camera embedded in an image. We do not read those fields off the file or store them, but we cannot strip them from it. Under Anthropic’s commercial terms, what we send the API and what it returns are not used to train Anthropic’s models.
• Web fonts: Google LLC. Ten pages load two typefaces (Playfair Display and Newsreader) from Google Fonts: four marketing pages, the blog index and each blog article, the learn index and each learn article, the intake quiz, and the legal pages (this Notice and the Terms). Your browser fetches them from fonts.googleapis.com and fonts.gstatic.com, which tells Google your IP address, your User-Agent string, and which page asked for the font — so on a blog or learn article, that is a signal about what you were reading. No account data, no home record data, and no cookie of ours goes with that request. The signed-in app does not load these fonts.
• File storage: Cloudflare, Inc. Every file on your home record is stored in Cloudflare R2 (bucket almwell-receipts), not on our application server, so it survives a restart. That is all three kinds: receipts you upload or forward, home inspection reports, and the photos you attach to a system — plus the raw email behind a forwarded receipt. Cloudflare holds each file as it is, including whatever is printed or embedded in it, which for an inspection report means the property’s street address. It also sees the request metadata any storage provider sees. It does not get the structured fields on your home record, your account details, or the values we read out of a file.
• Error and performance monitoring: Functional Software, Inc. (Sentry). In production only, Sentry receives the details of unhandled exceptions and a 10% sample of performance traces: the stack trace, the request path and method, and the log and outbound-HTTP breadcrumbs leading up to the event. We do not enable Sentry’s personally-identifiable-information capture, so it does not receive your account identity by default. An exception raised while handling your data can still carry fragments of that data in its message or breadcrumbs.
• Climate data: Open-Meteo (Open-Meteo.com, Zurich, Switzerland). To describe your home’s heating and cooling climate we send Open-Meteo the latitude and longitude of your home, from our server, and ask for last year’s daily temperatures for that point. If we do not have coordinates, we send your postal code instead so Open-Meteo can return coordinates for it. It receives no street address, name, email address, or account id. This is Open-Meteo’s free tier, which needs no account, so we have no contract with them beyond their published terms.
• Bank connections: Plaid Inc. The Bank accounts section of your plan page loads Plaid’s Link script from cdn.plaid.com whenever you open that page, which tells Plaid your IP address, your User-Agent string, and that you were on that page — before you press anything. If you then choose to connect a bank, you enter your bank credentials on Plaid’s own screen; those never reach us. Plaid’s account-data product is enabled in our code, not switched off: we ask Plaid for its transactions product, and a successful connection pulls the last 12 months of that account’s transactions and re-pulls them every night. Each one is written to our own database — date, amount, merchant, Plaid’s category, and Plaid’s entire response for that transaction. What stops this today is a missing credential, not a disabled feature. The production Plaid keys (PLAID_CLIENT_ID and PLAID_SECRET_PRODUCTION) are not deployed, so the connection request fails before Plaid is ever contacted; no bank has been connected on almwell.io and we hold no transaction data for anyone. Deploying those two keys is the only thing between that page and a live transaction feed, so we are describing the path now rather than on the day it opens. This entry, the §3 bullet, and the §7 line all change before that ships.
• Payments: Stripe, Inc. Stripe runs the hosted checkout page, stores your card, charges it on the schedule in the Terms §5, and emails your receipts. Stripe receives your email address and the card details you enter on its page; we receive back only the identifiers listed in §3. Stripe processes this data as an independent controller under its own privacy policy and as our processor under its services agreement. We do not send Stripe your home record data.
• Authentication (OAuth): Google LLC and Apple Inc. If you choose “Sign in with Google” or “Sign in with Apple,” the respective provider authenticates you and returns an identity token. We store only the provider name, your provider-assigned user ID, and your email address from that token. Neither Google nor Apple receives your home record data.
• Advertising conversion measurement: Google LLC. The Google Ads conversion tag (gtag.js) loads on almwell.io pages, sets the advertising cookies described in §3, and receives page-visit and ad-click data so we can measure whether our Google ads result in purchases. Google processes this data under its Google Ads terms. The tag itself sends Google no name, no email address, and nothing you enter into the product. Google does receive data from us through three other paths, each with its own entry above: Places autocomplete, the Solar API, and Google Fonts.

If we add or change a service provider in a way that affects what is collected, we will update this list before that change ships.

7. Retention

• Server logs: kept by size, not by age. Our app and the proxy in front of it each write their log to a file on the Hetzner box that Docker caps at 10 MB per container. When a file fills, Docker starts it over and the older lines are gone, and a container’s log goes with it when a later deploy removes the container. There is no time-based retention: a line can be gone within hours on a busy day or still be there after 30 days on a quiet one. Nothing is archived.
• Account and home record data: retained for the life of your account. Deleted within 30 days of a verified deletion request.
• Unfinished intake accounts: if you finish the intake quiz and never start checkout, the account row we made for you — your email address and the quiz answers (ZIP code, budget, deadline) — is deleted automatically 14 days after the quiz, with no request from you. It is the only account or home record we delete on a timer — the four bullets below that say Nothing here is deleted on a timer are true, and this bullet is the exception to them. Server logs, in the first bullet above, expire by size rather than on a timer and are not account data. It stops applying the moment you start checkout or a home record exists on the account; from then on the line above governs.
• Uploaded files: receipts, inspection reports, and system photos stay in Cloudflare R2 for the life of your account, along with the raw email behind a forwarded receipt. Nothing here is deleted on a timer. They go when your account data goes, under the deletion request described in §8.
• Property and solar lookups: the records we cache from Rentcast and the Google Solar API are keyed to your address or coordinates. After 30 days we treat the cached record as stale and re-query the provider, and the new response overwrites the old one in that row. We also keep a permanent, append-only copy of every Rentcast response, so a re-query never erases what a previous one returned. Nothing here is deleted on a timer. These records go when your account data goes, under the deletion request described in §8.
• PostHog analytics events: retained per PostHog’s default retention policy. We do not control PostHog’s retention independently.
• Payment records: subscription and charge identifiers are retained for as long as we are required to keep financial records (at least seven years for tax purposes), even after you close your account. Stripe retains its own transaction records under its policy.
• Bank transactions (Plaid): there are none — no bank has ever been connected (see §6). If one is connected, the transactions we pull stay on your account for its life. Nothing here is deleted on a timer. Disconnecting that bank in the app removes its transactions right then, and everything left goes when your account data goes, under the deletion request described in §8.
• Inbound contact email: retained for as long as needed to keep a record of the conversation, then deleted on request.
• Receipts: stored with your home record and kept for the life of your account, unless you delete them sooner from the Receipts page. Deleted within 30 days of a verified deletion request.
• Raw inbound receipts mail: the complete original message described in §3 is kept for the life of your account. Nothing here is deleted on a timer. Action Mailbox, the framework that receives that mail, ships with a timer of its own that deletes every delivered message 30 days after it is processed, and we have turned that timer off. We turned it off because it matched neither this page nor the code: it deleted the stored message whether or not you still had the receipt that message produced, and where a receipt did still point back at the message, the deletion crashed on that link instead of completing. Nothing reschedules it and nothing else sweeps it, so the message goes when your account data goes, under the deletion request described in §8.
• Data sent to Anthropic: retained by Anthropic under its own commercial terms and published retention policy. We do not control that retention independently and cannot delete it on your behalf. Deleting a receipt, document, or plan from Almwell removes our copy.

8. Your rights

• Access. Email us at the address in §10 and we will tell you what we have on you.
• Deletion. Email us at the address in §10 and we will delete your account and home record data within 30 days. Payment records we are legally required to keep are the one exception — see §7. Server access logs are not deleted on request; they expire when the fixed-size log fills or the container is removed, which may be before or after your account data goes. PostHog analytics events are subject to PostHog’s own data deletion process.
• Correction. If something we have is wrong, email us at the address in §10 or update it in your account settings.
• No sale opt-out is needed — see §5.

9. Other defaults you should know

• Children. almwell.io is not directed to children under 13, and we do not knowingly collect data from them. If we discover that we have, we will delete it.
• Security. We use industry-standard encryption in transit (HTTPS). No site is perfectly secure; if we have a breach that affects you, we will notify you and the appropriate authorities as required by law.
• International. Almwell operates from the U.S. and the site is hosted in the U.S. If you visit the site from outside the U.S., your data is processed in the U.S. By using the site, you understand and consent to that.
• Changes. We will update this Notice when something material changes — for example, adding an analytics tool, a service provider that processes personal data, or a covered service. Updates take effect on publish; the “Last updated” date at the top of the page is authoritative.

10. Contact

One address covers everything you would write to us about — privacy questions, access and deletion requests, and general mail:

• Almwell: hello@almwell.io

The Receipts inbound address in §3 is not a contact address. It is a product inbox: mail sent there is processed automatically, and anything that is not a readable receipt attachment is stored with the message (§3) but is never read or answered. Send account, privacy, and legal mail to the address above.

— End of Privacy Notice —