Privacy Policy

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's legal name, entity type, state of formation, and business address are not stated in this draft and must be inserted before launch: [PLACEHOLDER — operator legal entity name], [PLACEHOLDER — state of formation and entity type], [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 is a marketplace. Its purpose is to connect a shipper with an independent hauler. HaulHand does not transport cargo, take possession of cargo, operate a vehicle, 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.

We are not a motor carrier and we are not an insurer. HaulHand's regulatory classification, including whether any part of its activity falls under federal or state freight-broker requirements, is under review and is addressed in the Terms. This policy does not assert a conclusion on that 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:

• Authentication is not built. Nobody can create an account, sign in, or reach the application. The only accounts that exist are development fixtures on an engineer's machine.
• No load has been posted, no bid placed, no booking made, and no card charged through the product.
• The only things a visitor can submit are the waitlist form and the hauler application form. Both are described in section 5.
• Nothing a visitor submits is written to the HaulHand database.

Everything described in section 6 is software that exists and has been tested but that no member of the public has been able to reach.

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 third party 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.

Neither form records your IP address, and neither sets a cookie.

5.2 The load builder on the public site

The public “post a load” pages let you fill in cargo details and see whether they would be accepted. That 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 Server and network logs

This application writes no request log of its own and sets no cookie on its public pages. A hosting provider or network provider will keep its own connection and request logs, which ordinarily include IP addresses. No hosting provider has been selected: [PLACEHOLDER — hosting and CDN provider, what its logs contain, how long it keeps them, and any cookie it sets].

6. Information the platform is built to collect when accounts open

The following describes software that is built but unreachable. None of it has collected anything from a member of the public. It is set out here so that this document is complete and so counsel can review it before, rather than after, the first real user arrives.

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.

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. Once it is open for bids, the whole row — including the pickup and drop-off addresses, the cargo description and the notes — can be read by any signed-in hauler whose profile lists that category of hauling and that pickup state, and by administrators. Shippers should not put information in a load posting that they would not show to those haulers. 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. Raw event payloads sent by the processor to our webhook are stored as received.

Payment is authorized when a booking is made and charged when delivery is confirmed.

6.5 Records of what you agreed to

When you accept the terms during onboarding, the platform records which document you accepted, its version, the time, and — as evidence that the acceptance happened and came from you — the IP address and browser user-agent string of that request. This is the only place in the software where an IP address is written to the database. 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. There is no email or text-message sending code in this application. HaulHand sends no marketing email and no marketing texts, and has no mechanism to do so.

6.8 Built, but with nothing writing to it

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:

• Messages between booking parties. In-booking messaging is not built.
• 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.
• Rate-limit counters. A counter keyed partly by IP address is written and tested, but no form or endpoint calls it, so no IP address is recorded there. See section 10.

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.

Two things must be true before any of that becomes a description of reality rather than of code, and counsel should treat both as conditions: the scheduled execution of the deletion job must be configured in the production deployment, which it is not today, and a notice and consent flow for location collection must exist, which it does not. Until then this section describes an unused table.

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. Exactly one place in this software writes an IP address: the record of your acceptance of the terms during onboarding, described in section 6.5, where it is stored alongside the browser user-agent string as evidence of the acceptance. Because nobody can create an account yet, no such record exists for any member of the public. A rate-limit counter that would incorporate an IP address is written but is not called by anything. No IP address is used for analytics, profiling, or advertising, because none of those exist here.

Cookies. This application sets no cookie on its public pages. A signed-in session will use a session cookie once authentication is built; the only cookie the code sets today is a development sign-in cookie that exists only on an engineer's machine and is refused outright in a production build. Stripe's card field sets its own cookies when it loads, and it loads only on the checkout page inside the application, which no member of the public can reach. Whether a hosting provider or CDN sets its own cookie is part of the placeholder in section 5.3.

11. Who information is disclosed to

11.1 Other people using the marketplace

Once the marketplace is open, information is shown to other participants as described in section 6.3: haulers matching a load's category and pickup state can read that load in full, a shipper can read the bids on their own load, and the two parties to a booking can read the booking. Participants must not use another party's information for anything other than the haul it relates to.

11.2 Service providers

Two service providers are in use or intended:

• 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 database, and the private file storage that the unbuilt upload feature would use. Supabase is also the intended authentication provider.

The waitlist and hauler application webhook described in section 5.1 is a third recipient and is the one that receives data today. It is unnamed in this draft and must be named before launch.

No other third party receives personal information. There is no email provider, no text-message provider, no mapping or geocoding provider, no identity-verification provider, and no advertising or analytics vendor integrated with this application. Hosting is not yet chosen. Data locations, sub-processor terms, and data processing agreements require confirmation before launch: [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. No automatic retention schedule is implemented today, so rather than promise periods that no code enforces, this section says what the software actually does.

• Waitlist and application submissions. Held by the receiving service, not by us. Retention is part of the placeholder in section 5.1.
• 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.
• 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 the only retention rule the codebase enforces at all, and it currently has nothing to enforce it against.
• 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 privacy@haulhand.io and say what you want. 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].

Because nobody has an account, there is at present almost nothing to request. If you submitted a waitlist or application form and want it removed, say so at that address and we will remove it from the receiving service.

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 privacy@haulhand.io 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: privacy@haulhand.io. 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].