Privacy Policy

Need to access, correct, or delete your data? See how to make a privacy request.

1. Scope of this document

This policy describes how the operator of haulhand.io and the HaulHand marketplace (“HaulHand,” “we,” or “us”) handles personal information. It covers this website and the marketplace software behind it.

It does not govern how a shipper or a hauler handles information outside HaulHand. Those are separate businesses with their own obligations.

Two kinds of statement appear below and they are kept apart on purpose. Statements about what the software does today are written in the present tense. Statements about what it is built to do, but does not do yet, are labelled as such. Where a section says a thing is not collected, that means no code writes it — not that we intend to stop.

2. Who is responsible

The operator of this Platform is HaulHand LLC, a Montana limited liability company. Its business postal address is not stated in this draft and must be inserted before launch: [PLACEHOLDER — business postal address].

Whether the operator is a “controller,” “business,” or equivalent under any particular state or foreign privacy statute is a legal conclusion this draft does not reach: [PLACEHOLDER — statutory role and which regimes apply, per counsel].

3. What HaulHand is, and is not

HaulHand provides marketplace software and does not physically perform the haul or operate the vehicle. Its purpose is to connect a shipper with an independent hauler. HaulHand does not take physical possession of cargo, employ a hauler, or insure a load. When a shipper accepts a bid, the transportation contract is between the shipper and the hauler; HaulHand is not a party to it.

HaulHand does not insure loads or offer coverage. HaulHand's regulatory classification — including any broker, carrier, freight-forwarder, or state requirements — has not been cleared for public transactions. Public loads and transactions remain closed. The Terms address that review; this policy does not assert a conclusion on the classification question.

4. What the service actually does today

This section exists because the rest of the document does not make sense without it. As of the date above:

• Public hauler signup, email-link authentication, and the signed-in application are available. The anonymous signup request stores only a short-lived confirmation intent; it creates no account and no Terms acceptance. Explicit email-link confirmation creates a new hauler account when the address is still new, records the current Terms acceptance, verifies the email, and creates the session together. If an account already exists, confirmation signs into it without changing its profile or roles. Public shipper signup is waitlisted.
• Load posting, bidding, booking, card authorization, delivery, disputes, cancellation, capture, and payout workflows are built. Load posting is available through the explicit local development test mode and refused for normal public sessions while the launch review remains open. No production booking or payment has been completed as of the date above.
• A visitor can submit a hauler signup intent, confirm it through an email link, request a sign-in link, join the waitlist, submit the optional hauler route survey, or use the unstored public cargo-details checker. During isolated local tests, signed-in fixture users can submit the marketplace records described in section 6 when their role and the record's state permit it.
• Signup intents and confirmed accounts, waitlist submissions, hauler applications, and the signed-in marketplace write to the HaulHand database. The public load preview is the exception: it validates without saving what was typed.

Section 6 describes the information the account system stores and the marketplace workflows are built to store during testing and after their public launch gate opens.

5. Information collected today

5.1 The waitlist and hauler application forms

The waitlist form collects an email address, whether you ship or haul, your state, the kinds of hauling you need, and — all optional — a note about the load, a pickup area, a drop-off area, how often you move something, when you next need something moved, how you arrange hauling today, and what you find hardest about it.

The hauler application form collects an email address, phone number, business name, home state, years of experience, truck and trailer description, the kinds of hauling you take, how far you run, the lanes you already run, and — optional — whether you take backhauls, whether you have spare capacity, where you currently find work, what frustrates you, and a free-text note.

Where these go. A submission is written to the HaulHand database, together with the time of submission. No separate webhook or forwarding recipient receives it. Waitlist signups are stored in a waitlist_signups table and hauler applications in a hauler_applications table; both are readable only by HaulHand's own server, and a signed-in user of the site — shipper, hauler or otherwise — cannot read either table.

A deployment may additionally be configured to forward a copy of each submission to an address of its own choosing. No such address is configured today, and if one is added before launch the service receiving it must be identified here: [PLACEHOLDER — name of any service receiving forwarded waitlist or hauler application submissions, its retention, and its contract]. If the database cannot be reached, the form tells you it did not record your details rather than reporting success.

One record is kept per email address. Submitting either form again with the same address updates the answers already held rather than adding a second record, so the most recent answers are what is stored. The date of your first submission is kept.

The submission rows do not contain your IP address, and neither form sets a cookie. A separate rate-limit record uses the request address as part of its key, as described in section 10.

5.2 The cargo-details checker on the public site

The public checker pages let you fill in category-specific cargo details and see whether they pass those fields' rules. They do not collect the route, dates, or price needed for a complete load. The check runs on our server and the result is returned to your browser. Nothing you type into it is stored, forwarded, or logged.

5.3 Public hauler signup intent

The signup form collects an email address, full name, optional phone number, and hauling business name. Before email confirmation, those details are stored only on a hashed, single-use confirmation-token row with a fixed hauler purpose and a 15-minute expiry. No account, role, hauling profile, survey conversion, Terms record, or session is created by the anonymous submission.

If the address already belongs to an active account, the submitted name, phone, and business name are not stored or applied; the link is an ordinary sign-in link. A deactivated address receives no link and no signup-intent row. The public response is the same in every case so the form does not disclose who has an account.

5.4 Server and network logs

This application writes no general request log of its own and sets no HaulHand cookie on its public marketing pages. The application is hosted by Vercel, and Cloudflare supplies DNS only. Those providers keep their own operational records under their own policies; the exact fields and retention still need to be documented: [PLACEHOLDER — hosting and CDN provider, what its logs contain, how long it keeps them, and any cookie it sets].

6. Information stored by accounts and marketplace workflows

The account portions below are deployed for public haulers. The load, booking, and payment portions are currently exercised through isolated local development tests and are ready to store these fields once the public shipper launch gate opens.

6.1 Account and profile

Email address, full name, phone number, and the account's role or roles. The profile also carries the times an account was deactivated or suspended, if either happens, and the time email control was first confirmed. A public hauler account receives only the fixed hauler role.

6.2 Hauler business information

Business name, MC number, USDOT number, subscription plan, the kinds of hauling and the states served, whether onboarding was completed, a document review status, the identifier of the hauler's payout account with our payment processor and whether that processor has enabled payouts to it, and two figures used only to build a rate estimate — the truck's fuel economy and an assumed fuel price. The fuel figures are a calculator input. They are never added to a booking.

6.3 Loads, bids, and bookings

A load carries the category of cargo, a structured cargo description that varies by category, pickup and drop-off street addresses, states, counties and coordinates, an estimated mileage typed by the shipper, pickup and delivery windows, a budget, and free-text notes. A bid carries the amount, the equipment offered, an optional message, and an expiry. A booking carries the two parties, the accepted bid, the status, the times it moved through each stage, a deadhead mileage figure, and, if it is cancelled, who cancelled it and why.

Who can see a load. A load in draft is visible only to the shipper who wrote it. On the load board, eligible haulers receive a cargo summary, city or county and state, pickup and delivery windows, and estimated miles. The board withholds street addresses, coordinates, the shipper's identifier, the full cargo record, budget, and notes. The shipper sees their own full posting. The winning hauler receives the addresses and counterparty contact details through the booking. A bid amount is visible to the hauler who made it and the shipper who received it, not to competing haulers.

6.4 Payment records

For each booking the platform records the amounts involved in integer cents, the state of the authorization, the times it was authorized, captured or voided, and the identifiers our payment processor returns: the payment intent, the charge, the refund, and the transfer. It also records a key that makes a retried payment safe to replay; that key contains the processor's identifier for the payment method used. Failure codes and processor error messages are stored so a failed payment can be explained and retried. Verified processor events are stored only after card-related fields and subtrees have been removed; a database constraint rejects an event that still contains them.

At booking, the built flow asks the shipper's card issuer to authorize the disclosed total. A card authorization is temporary and can expire or be released before delivery. It is not a completed charge or a guarantee of payment. If it expires or capture fails, another payment step is required. If the authorization remains valid, Stripe is asked to capture after delivery — when the shipper confirms it or, if the shipper does not respond or open a dispute, after the disclosed response window. Payout begins only after successful capture.

6.5 Records of what you agreed to

When you choose “Accept Terms and sign in” on the email-link confirmation, or agree to the displayed version while adding hauling to a signed-in account, the platform records the current Terms version, the time, and the IP address and browser user-agent string of that acceptance request. Email confirmation creates that record and the session in one database transaction; authenticated start-hauling creates it with the hauling role or profile change in one transaction. The separate shipper and hauler onboarding acceptances record the same evidence fields for their own material. Public-endpoint rate-limit records also include the caller address in their key. See section 10.

6.6 Operational audit records

Every significant action records who did it, what kind of actor they were, which record it affected, what it changed from and to, the time, and structured detail about the change — identifiers, statuses, amounts, and categorised reasons. These records deliberately store facts about an action rather than its contents: where a dispute submission is recorded, the audit row notes that text and an attachment were present, not what they said. Section 13 explains why these records cannot be deleted.

6.7 Notifications

The platform creates in-app notification records naming the recipient, the kind of event, the load, bid or booking it concerns, and whether it has been read. A scheduled worker sends a small set of operational notices through Resend: account-review decisions and terminal payment-failure notices after retries are exhausted. Bid, booking-stage, and conversation notifications remain in the application only. HaulHand has no marketing-email or text-message workflow.

6.8 Bid and booking messages

HaulHand stores plain-text bid messages together with the sender, the exact bid, and the time sent. The shipper who owns the load and the hauler who made that exact bid can use the conversation while the bid remains open and its bidding window has not closed. If the shipper selects that bid, the selected bid's same thread continues as the booking conversation for those two parties while the booking remains active. An authorized HaulHand administrator can also read the records under the database access policy, although there is no administrator message-review screen today.

Messages are limited to 1,000 characters of plain text. The application refuses phone numbers, email addresses, and links in message text; after booking, the parties instead receive each other's separately saved booking contact details. Sent messages cannot be edited or deleted through the ordinary product. Message attachments, file sharing, typing indicators, presence, automatic replies, live delivery, email, text-message, and push delivery are not enabled.

The product limits a conversation to 100 messages, each sender to 30 messages in a rolling hour, and the displayed history to the latest 50. Those are abuse and display bounds, not a retention or deletion schedule. Do not use a conversation for credentials, payment-card details, health information, an emergency report, or anything requiring immediate attention.

6.9 Schema present, but no product writer

Several tables exist in the database with no code that writes to them. They represent planned features, and nothing has ever been stored in them. They are listed rather than omitted so that the inventory in this document matches the schema counsel may be shown:

• The older general message table. The current bid and booking conversation does not write to this historical table or its attachment field; it uses the bounded bid-message records described in section 6.8.
• Reviews and ratings. Not built. No rating of any shipper or hauler exists.
• Documents and file uploads. See section 9.
• Location events. See section 8.

7. Payment card information

Card numbers never reach our servers. The card field on the checkout page is an iframe served by Stripe from Stripe's own domain. The card number, expiry date and security code are typed into Stripe's page, not ours, and our code cannot read them. Stripe returns an opaque identifier for the payment method, and that identifier is the only payment field sent to our server.

No card number, security code, expiry date, card brand or last four digits is stored in our database, appears in our logs, or passes through our servers. There is no column for any of them. What we store are Stripe's identifiers, the amounts, and the statuses described in section 6.4.

Stripe collects and processes the card details directly. Its handling of them is governed by Stripe's own terms and privacy policy. Bank account details a hauler provides to receive payouts are likewise collected by Stripe during its onboarding, on Stripe's pages; we store the identifier of the resulting account and whether payouts to it are enabled, and nothing else about it.

8. Location information

HaulHand does not collect location from anyone's device. There is no code that records a position, and no position has ever been stored. The features some marketplaces offer for following a shipment along its route do not exist here.

The database has a table for booking-scoped location events, and a deletion routine for them was written and registered before anything that could write one. If the feature is built, each recorded position would carry a booking identifier, a latitude and longitude, an accuracy figure, the time it was recorded, and a deletion deadline stored on the record itself. A registered job deletes every record whose deadline has passed. A retention setting exists in the platform's administrative settings with a default of 90 days; nothing reads that setting yet, because nothing yet creates a record for it to apply to.

The deletion job is registered and scheduled in the production deployment. A location writer and a notice and consent flow still do not exist. Until they do, this section describes an unused table and an active deletion guard with no rows to process.

9. Documents and dispute attachments

File upload is not built. There is no way to upload an insurance certificate, an operating-authority record, an identity document, or dispute evidence, and no file has been uploaded. The database table that would hold document metadata has no code writing to it.

The storage buckets are configured in advance and are private: anonymous access is denied, and access rules restrict a file to its owner, to an administrator, and — for a file deliberately placed in a booking-scoped path — to the other party to that booking while the booking is active.

No retention or deletion schedule for uploaded documents has been decided. [PLACEHOLDER — retention schedule for identity documents, insurance certificates and dispute evidence, per counsel] must be settled before the upload feature is enabled, not after.

Storing a document, or marking one reviewed, is not a representation that it is genuine, current, adequate, or applicable to a particular haul. No document review process is running today.

10. IP addresses, cookies, analytics, and advertising

There is no analytics on this site. No analytics product, no tag manager, no advertising pixel, no session recorder, and no third-party tracker of any kind is loaded on any page. The site's fonts are packaged with the site itself and are not fetched from a third party when you visit.

IP addresses. The record of your Terms acceptance stores the email-confirmation or authenticated start-hauling request address and browser user-agent as evidence of the acceptance. The waitlist, hauler application, and public load preview also use the request address in a short-lived rate-limit key. Sign-in and signup-link requests instead put a versioned SHA-256-derived request-address bucket in that rate-limit key, not the raw address. The bucket is deterministic for the same address and design version, so HaulHand treats it as pseudonymous personal information rather than anonymous data. Those controls limit submission volume; they are not used for analytics, profiling, or advertising.

Authentication email limits. A sign-in or signup-link request also creates a short-lived per-email rate-limit bucket. The key stores a versioned SHA-256-derived value made from the normalized email address, not the email address text. Because that value is deterministic for the same address during this design version, HaulHand treats it as pseudonymous personal information rather than anonymous data. Its active rate-limit window is one hour; section 13 describes deletion after the window closes.

Transition from the previous limiter. The application version in use before this policy update placed the normalized email text and raw request address in its authentication rate-limit keys. Deploying the new version does not rewrite an existing closed or active row. Those legacy rows stop affecting requests when their one-hour windows close. The daily rate-limit purge removes at most 5,000 closed rows per run, so a backlog can require more than one successful run. HaulHand treats the transition as complete only after a post-window run reports that no rows remain, rather than claiming the older values disappear at deployment time.

Cookies. This application sets no HaulHand cookie on its public marketing pages. Completing email-link sign-in sets an HTTP-only session cookie with SameSite=Lax; it is Secure in production and carries a random token rather than a user identifier. Stripe's embedded card field may set its own cookies when the checkout page loads. Provider-cookie details remain part of the placeholder in section 5.4.

11. Who information is disclosed to

11.1 Other people using the marketplace

Information is shown to other participants as described in section 6.3: eligible haulers see the redacted load-board view, a shipper can read the bids on their own load, and the two parties to a booking can read the booking and each other's booking contact details. The shipper and hauler attached to one exact bid can read the plain-text messages in that bid's conversation; other bidders cannot read it. Participants must not use another party's information for anything other than the haul it relates to.

11.2 Service providers

Four service providers are currently part of the deployed service:

• Stripe — payments and payouts, including the connected accounts that haulers are paid through. Stripe collects card details directly, as described in section 7, and collects the identity and bank details it requires to enable a payout account.
• Supabase — the PostgreSQL database, and the private file storage that the unbuilt upload feature would use.
• Vercel — application hosting and scheduled jobs.
• Resend — email-link authentication messages and the operational notices described in section 6.7.

Waitlist and hauler-application submissions are written directly to the HaulHand database. No forwarding recipient is configured today.

Cloudflare supplies DNS only. There is no text-message provider, mapping or geocoding provider, identity-verification provider, or advertising or analytics vendor integrated with this application. Data locations, sub-processor terms, and data processing agreements require confirmation before live loads are accepted: [PLACEHOLDER — sub-processor list, data regions, and executed data processing agreements].

11.3 Legal and safety

We may disclose information where reasonably necessary to comply with a subpoena, court order, warrant, or other binding legal process; to meet a tax or regulatory obligation; to protect someone from imminent harm; to investigate fraud or a security incident; to enforce our agreements; or to establish, exercise or defend legal claims. Where lawful and practical we will seek appropriately narrow process and tell the affected user.

Information may also be disclosed in connection with a financing, merger, acquisition, reorganisation, or sale of the business, subject to confidentiality protection and any notice the law requires.

12. No sale of personal information, and no targeted advertising

HaulHand does not sell personal information, does not disclose it for cross-context behavioural advertising, and does no advertising at all. There is no advertising or analytics code in this application. If that ever changes, this policy and any opt-out mechanism the law requires must be in place before the change takes effect, not after.

13. Retention and deletion

We intend to keep personal information only as long as it is needed for the purpose it was collected for, for the transaction it relates to, for security, for an active claim, or to meet a legal obligation. There is no comprehensive automatic retention schedule today. Three narrow deletion jobs exist for expired or revoked authentication credentials, location rows, and expired rate-limit windows; rather than promise periods the rest of the code does not enforce, this section says what the software actually does.

• Waitlist and application submissions. Stored in the HaulHand database. There is no automatic deletion schedule for them.
• Accounts. A profile is deactivated rather than hard-deleted. Nothing deletes a profile automatically.
• Bookings and payment records. Kept. There is no automatic deletion. The financial snapshot taken when a bid is accepted is protected by the database against being changed or deleted, and payment, capture, refund, payout and processor-event records are kept for reconciliation, tax, and legal obligations.
• Bid conversation messages. Stored with the sender, bid, and time sent. There is no automatic deletion schedule for messages. They cannot be edited or deleted through the ordinary product, and the message-count, sender-rate, duplicate, and display bounds described in section 6.8 are not retention periods.
• Audit records. The audit table refuses deletion and modification at the database level. A trigger rejects any attempt to update, delete, or truncate a row. This is deliberate and it is a real limit on what a deletion request can achieve: a record that you took an action can survive the deletion of the thing you acted on. Counsel should treat this as a design constraint to be assessed, not a setting to be changed — it is the integrity property the audit trail exists for.
• Records of what you agreed to. Kept, including the IP address and user-agent recorded as evidence. Nothing expires them.
• Location. None exists. The deadline-based deletion described in section 8 is scheduled, but it currently has nothing to enforce it against.
• Sign-in links and sessions. Expired single-use link records and expired or revoked session records are deleted by a daily scheduled job. A used link stops authenticating immediately and stays only until its expiry cleanup. A signup link's temporary full name, optional phone number, and business name are scrubbed immediately when that link or a sibling link is consumed. An unused link stops working at its 15-minute expiry. The daily job is scheduled for 03:23 UTC, so an expired row becomes eligible for removal at the next successful run rather than disappearing at the instant of expiry. Each run deletes at most 500 expired link records and at most 500 expired or revoked session records. If a run reports that more rows remain, later successful runs are required; HaulHand does not promise which eligible row a particular run will remove. Production scheduled-job delivery and the reported backlog remain operational checks. An expired or revoked session stops authenticating before its row is cleaned up.
• Rate-limit records. Closed windows are deleted by a daily scheduled job at 03:43 UTC. The active window is one hour for each public endpoint and authentication-email bucket described in section 10. A closed row is removed on a later successful purge run, not at the instant its window closes; production scheduled-job delivery remains an operational check.
• Documents. None exists, and no schedule is decided.

A retention schedule covering transaction and tax records, identity and insurance documents, dispute evidence, consent records, support correspondence, and backups must be approved and implemented before launch: [PLACEHOLDER — approved retention schedule, including backup cycles].

14. Your choices, and how to ask

Which privacy statute applies to HaulHand, and therefore which rights you have as a matter of law, is a question for counsel and is not answered here. This draft does not claim compliance with, or exemption from, any particular regime.

Independent of that question, we intend to honour requests to: confirm whether we hold information about you; give you a copy of it; correct it; delete it, subject to the audit constraint in section 13 and to records we must keep; and withdraw a consent you gave, going forward. We will not treat you worse for asking.

Send a request to haulhandllc@gmail.com and say what you want. For deletion, use Request deletion by email. Do not send a password or identity document in your first message. This starts a request; it does not automatically delete records. We may ask for enough information to be confident you are who you say you are, and no more than that. We may refuse or narrow a request where an exception applies — fraud prevention, security, another person's rights, completing a transaction, a legal claim, or a record the law requires us to keep — and we will say which. Response times, appeal rights, and any state-specific procedure are for counsel to set: [PLACEHOLDER — response deadlines, appeal process, and any required state-specific rights language].

If you created an account or submitted a waitlist or application form and want to make a request, use that address. Any deletion remains subject to the record constraints and unresolved retention rules in section 13.

15. Security

The database denies access by default and grants it through explicit per-table rules based on ownership, role, or being a party to a booking. Financial tables are not reachable by a signed-in user's own credentials at all and are written only by trusted server-side code. Credentials that bypass those rules are confined to server, webhook, and scheduled-job code. Audit and accepted-price records are protected against modification by database triggers. Payment operations use uniqueness and replay-protection controls to prevent a duplicate charge. File storage buckets are private and deny anonymous access. The processor webhook verifies the processor's signature and refuses anything unsigned.

These are specific technical controls, not a guarantee, and no system is perfectly secure. Production secret handling, staff access procedures, encryption settings, log retention, backups, incident response, and recovery testing are not yet established: [PLACEHOLDER — production security procedures and incident response plan]. If an incident occurs that requires notification under applicable law, we will give the notices that law requires.

16. Children

HaulHand is for adults and businesses and is not directed to anyone under 18. We do not knowingly collect information from a child. If you believe a child has submitted information through one of our forms, tell us at haulhandllc@gmail.com and we will have it removed.

17. Where information is processed

HaulHand is being built for use within the United States, starting in Montana, Idaho, and Utah. That does not by itself establish where each provider processes or stores data. Provider regions, backup locations, and support access must be confirmed and documented before launch: [PLACEHOLDER — processing and storage regions for each provider]. Do not read this draft as a representation that information stays in any particular state or country.

18. Changes to this policy

An updated policy will carry its own date. If a change is material we will give notice through the site or by contacting you, and will seek consent where the law requires it. We will not repurpose information already collected for a materially different use without the notice or consent the law requires.

19. Contact

Privacy questions and requests: haulhandllc@gmail.com. Before launch this section must carry the operator's legal name and postal address from section 2, and any additional contact or appeal channel counsel requires: [PLACEHOLDER — legal name, postal address, appeal channel].