Privacy Policy

1. Information We Collect

HOAcrew collects information you provide directly to us, including your name, email address, phone number, organization details, and payment information when you create an account or use our platform. For vendors, we also collect business documentation, insurance certificates, and compliance records. When you build a request for proposals we collect the community address you enter, the boundary you confirm or draw, and the service requirements you specify.

We also collect a small amount of technical information automatically — described precisely in sections 4, 5 and 6, including what we deliberately do not collect.

2. How We Use Your Information

We use collected information to provide, maintain, and improve our services, process transactions, send service notifications, verify vendor compliance, and facilitate communication between communities and vendors. We also use data to measure properties, assemble your request for proposals, and provide AI-assisted drafting. We do not sell personal information.

3. Cookies and Browser Storage

We set three first-party cookies and no advertising cookies. There is no advertising network and no data broker anywhere in this product, and nothing we set follows you to another site. Something we do not set is nonetheless stored on your device — by the map library that draws our satellite views. It has its own explanation in section 6, because it is the one item on this page we cannot remove.

• Your sign-in session — set when you log in, so the portal knows who you are. Strictly necessary; the product cannot work without it.
• Which door you came in by — remembers whether you identified yourself as a board member, a community manager or a vendor, so the site stops asking. It holds one of those three words and nothing else.
• Your portal sidebar preference — whether you collapsed the navigation.

Your browser also keeps some things on your own device so you do not lose work: unsaved drafts of a proposal, a company registration, or an enrollment form. Those stay in your browser and are sent to us only when you submit them. Clearing your browser's site data for hoacrew.com removes all of it, including the map library's identifier described in section 6.

Our traffic analytics does not use cookies at all. That is why you are not being asked to dismiss a cookie banner on this site. See section 4.

4. Traffic and Performance Analytics

We use Vercel Web Analytics and Vercel Speed Insights to understand how many people reach each page, which steps of a process they complete, and how quickly pages load. Both are cookieless: they do not store an identifier on your device, do not build a profile of you, and do not follow you to other sites.

What they receive is the page you viewed, the country your request came from, coarse device and browser information, page-performance timings, and — for the steps of the proposal-request flow — the name of the step you reached with a small set of pre-approved labels such as which services were selected, a bucketed acreage range, and whether property data was found automatically.

They also receive the referring web address when you arrive here by following a link from another site — how we know whether people found us through a search engine, a management-company directory or a colleague's email. The analytics script adds it after our own redaction step has already run, so this is one field we disclose rather than one we filter. Our admin console shows these as a list of referring sites — google.com, and so on — never as a list of people.

We want to be exact about that field rather than reassuring, because it is the only thing keeping the access token in an invoice or ballot link off it. The collector sends a referrer only when the link came from a different site; moving between pages on hoacrew.com sends none. That is a behavior we watched on the wire, not one our code enforces. The script that decides it is served by our hosting provider rather than shipped in our application, and the package we install does nothing but hand events to it, so there is no line in our source we could point you at. We tested it, we saw same-site links send no referrer, and we are telling you that is the basis for the sentence — a supplier's behavior we have verified, not a guarantee we implement.

What analytics never receives — enforced in code rather than by policy, with the single exception marked below:

• your address, your community's name, or its coordinates;
• your name, email address or phone number;
• any price, estimate, bid amount or vendor payout figure;
• any proposal, invoice, community or user identifier;
• any access token from a link we emailed you — invoice and ballot links carry a credential in the web address, and every address is stripped of it in your browser before any measurement is recorded. The referring-site field described above is the one exception to “enforced in code”: nothing we wrote filters it, and it stays clear of those tokens only because the collector does not send a referrer between pages of the same site — the observed behavior described in the paragraph above, not a filter of ours.

Event labels are restricted to a fixed list per event; anything not on that list is discarded in the browser before the measurement is sent.

5. Error Monitoring and Server Logs

We use Sentry to find and fix errors. When something breaks, Sentry receives the technical details of the failure: the error, the code path, the browser, and the address of the page it happened on — with access tokens and record identifiers stripped out of that address before it is sent. Where that stripping happens depends on where the error happened: in your browser for a failure in the page, and on our own servers for a failure there. The same rule is applied in both places, by the same code.

What an error report is allowed to carry, stated as a list rather than as a reassurance. Four things about the request survive into a report: the address of the page, stripped as described above; the part of that address after the question mark, which our error provider records a second time as a field of its own and which is cut down to the same short list of permitted parameters; whether the request was a send or a fetch; and, of the headers your browser attaches, exactly four — your browser's user-agent string, your preferred language, and the type and length of the content. Everything else about the request is discarded before the report leaves. That includes your cookies, the setting that would attach your IP address, the address of the page you came from, and the contents of the request itself — the part that carries the address or the coordinates you entered.

It is worth saying why that is a list of what may stay rather than a list of what must go. Twice, a field nobody had thought to name turned out to be carrying something it should not: the address of the page you came from was being sent in full, tokens from invoice and ballot links included, and the contents of the request were reaching error reports as well. A list of forbidden fields is a promise to have thought of every field, and that promise had already been broken twice — so the rule runs the other way round. Anything our error provider starts attaching in a future version is dropped unless someone deliberately adds it to the list and says how it is cleaned.

Session replay has been removed. Sentry used to record a masked reconstruction of the page for 10% of sessions and for 100% of sessions in which an error occurred. We switched it off entirely rather than keep it: those recordings carried the web addresses of the pages visited in a form our redaction could not reach, and they kept a recording identifier in your browser's storage. Error monitoring does not need any of that. No session recording of any kind runs on this site.

Server logs are forwarded to Sentry too. Our hosting provider has a log forwarder pointed at Sentry, which is why Sentry is named here as a processor of ordinary running-the-service records and not only of crashes. Two different things end up in those records: the automatic account our host keeps of what was requested and how it responded, and the lines our own software writes as it runs. We can close the first by construction and the second only by reading our own code, so the two are described separately below rather than covered by one sentence.

Every address and coordinate has been moved out of the web addresses your browser sends to us and into the body of the request instead. That is the half that is closed by construction: the automatic account records the web address, and a value that is no longer in the address cannot be written into it. That holds because of how the request is built, not because anyone remembers.

That move only helps if the place we moved them to is safe, and when it was made it was not: the body of a request was one of the things an error report still carried, so an address that had just stopped appearing in server logs would have started appearing in error reports instead. Both halves shipped together — the contents of the request are dropped from every error report, as listed above. We are describing the near-miss rather than only the outcome because the outcome on its own would read as a plan that worked first time.

The lines our own software writes are the other half, and we would rather be exact about them than reassuring, because the same promise stated flatly would really be a claim about our own thoroughness. What is certain is the move above: a stray line cannot put a value back into a web address that no longer contains it. What is observed rather than guaranteed is that no line of ours writes one out anyway. We have read that code three times looking, and found seven that did. Two were plain: one wrote the full street address on every property lookup, the other the email addresses a paid invoice's receipt had gone to. Four more had been missed by an ordinary text search — the coordinates of a mapped property, rounded but still precise enough to pin a single lot; a vendor's email address in a reminder job; an administrator's email address together with the free text they had typed when deleting a draft invoice; and the name of the community being mapped. The seventh is conditional rather than certain, which is why we are describing it that way: when one of the property-data companies we query refused a request, our code wrote that company's reply into the log, and the request we had sent it carries the coordinates being looked up. The commonest refusal from that company means “your request was malformed” — the kind of refusal that quotes the request back. We have not seen it happen; we were not willing to leave it standing on the strength of that, and that line now records only whether the request was refused and how. All seven record a count, a status, or nothing.

A check runs with our tests that reads our own source and refuses a new log line which prints a value into it, unless the value is of an obviously harmless kind — a count, a status code, an internal record reference. It exists because of how two of those seven were missed: the line opening the log statement and the line carrying the value were different lines, and a search that reads one line at a time has nothing to match. The check reads the shape of the code and not the contents of a variable, so it is a ratchet and not a proof — a value with an innocuous name would still pass it. We would rather say where that line falls than let “we removed them” be read as “they cannot recur”.

The check itself was then checked, and it had two gaps of its own, which we are recording here rather than quietly closing. It stopped reading a file partway through whenever that file contained a particular common pattern earlier on, so part of one file was never examined at all; and it watched five of the ways a program can write a line to the log, when there are about twenty. Both are fixed, and a second reading of the same code, done a different way, now has to agree with the first or the tests fail. We mention it because “a check runs” is worth exactly as much as the check, and the first thing worth telling you about ours is that its first version was not complete.

Two things about that forwarder we are not able to confirm from our own code, and would rather name than smooth over: exactly which streams of log it carries, and how much of each line survives Sentry's own filtering. Both are settings in an account dashboard rather than in our source. We have an open item to go and read them, and section 10 is where the answer will be recorded.

Where this runs. Error monitoring is switched off when the site is running on a developer's own machine. It is on for hoacrew.com, and it is also on for the preview copies of the site we deploy to test a change before releasing it — those are built exactly the way the live site is, so the same monitoring runs on them. If you would prefer your browser sent no error reports at all, browser privacy settings and content blockers stop them, and you can write to privacy@hoacrew.com and we will confirm the request.

6. Addresses, Property Mapping, and Mapbox

To map a community we send the address you enter to Google's geocoding service to turn it into coordinates, and we send those coordinates to property-data sources — public county and state parcel services, commercial parcel-data providers, and OpenStreetMap — to retrieve lot boundaries. Your browser loads satellite imagery from Mapbox to draw the map. These services see a location; they are not told who you are, what your account is, or what you are quoting. Mapbox additionally collects something on its own account, which is set out immediately below.

Boundary results are cached for up to 24 hours against rounded coordinates so that a repeated lookup for the same area does not query those sources again.

7. Service Providers

We share information between a community and a vendor only as far as the service they have contracted with each other for requires — that contract is theirs, and we pass what it needs and nothing else. Beyond that, these are every third party that processes data on our behalf, and what each one is for:

• Supabase — the database and authentication behind the platform.
• Vercel — hosting, plus the cookieless traffic and performance analytics in section 4. Vercel also forwards server logs to Sentry, as described in section 5.
• Stripe — payments. Card details go to Stripe directly and are never stored on our servers.
• Sentry — error monitoring, and the recipient of the forwarded server request logs in section 5. Not session replay, which has been removed.
• Resend — sending transactional email such as invoices, proposal notices and account links.
• Upstash — short-lived caching and rate limiting.
• Google, Mapbox, and property-data sources — the address and mapping services in section 6. Mapbox also collects the map-library telemetry described in that section, on its own behalf rather than ours.
• Google (Gemini) — AI-assisted drafting where you ask for it, on the text you submit for that purpose.

We do not sell personal information to third parties and we do not share it with advertisers. Aggregate, non-identifying figures may be used to describe platform activity.

8. Data Security

We implement industry-standard security measures including encryption in transit and at rest, role-based access controls enforced in the database itself, and regular security audits. Vendor compliance documents are stored in private, access-controlled storage buckets. Privileged changes — roles, vetting decisions, insurance status — are written to an audit log that cannot be edited or deleted after the fact.

9. Your Rights

You may request access to, correction of, or deletion of your personal data by contacting us at privacy@hoacrew.com. You may opt out of non-essential communications at any time. If you are in a jurisdiction with additional rights over automated measurement — the EU, the UK, or a US state with a comprehensive privacy law — write to the same address and we will act on the request.

10. Changes to This Policy

This page is rewritten as one current statement rather than added to, so what you are reading is what the product does today. When we add a tool that receives data, this page changes in the same release. A policy that is out of date the moment we deploy is not a policy. The same rule applies in the other direction: when we stop doing something, this page says so rather than quietly dropping the paragraph — which is why section 5 tells you session replay used to run.

Two things above are stated as unfinished rather than as done, and they are listed here so you can hold us to them: confirming which server logs our hosting provider forwards to our error provider and how much of each line survives its filtering (section 5), and switching off the map library's device-performance report (section 6). Neither is a protection we have claimed. When either changes, this section is where the change will be recorded.

11. Contact

For privacy-related inquiries, contact us at privacy@hoacrew.com.