The form on the contact page collects a name, an email address, an optional company, and a message. Submitting it posts those four fields to a route on this site. That route is the only place this site accepts data from a visitor.

The route attempts to record the submission as a file on the server that handled the request. Whether it can depends on that server: where the filesystem is writable the file is written, and where it is not — which is the ordinary case for this kind of hosting — the write fails, the route returns an error to the form, and nothing is kept.

Only if that write succeeded does the route go on to attempt email — a notification to the mailbox this site is configured to use, with the address you entered set as the reply-to, and a confirmation to that same address. If no mail credentials are configured for the deployment, no email is sent and the recorded file is the only copy. This page cannot tell you which of those happened to your message; it can only tell you what the code attempts.

The submission is not written to a user database, and it is not sold, published, or used for anything except reading it and replying. Beyond the mail provider that carries the notification, it is passed to no one — with one exception visible in the code: a development-only path can post the submission to a webhook address instead of sending mail, and it stays off unless a deployment both enables it and runs in development mode.

Every page loads Google Analytics. The script is fetched from googletagmanager.com when a page opens, so Google receives that request — your IP address, your browser, and the fact that you are on this site — before this page has asked you anything. It does not receive which page: this site sends a referrer policy that gives a cross-origin request the site address and not the path.

What follows that request depends on how the site is configured. On the deployment you are reading this on, nothing does. The page configures Google Analytics with page-view reporting switched off, so no analytics event is sent; and no cookie is set, by Google or by this site, in any answer to the banner. That was checked against the live site with analytics consent already granted: one request to googletagmanager.com, no measurement call, and no cookies at all. A deployment configured differently could send events and set Google's cookies, so this paragraph describes what the code does rather than promising what every future build will do.

The banner shown on a first visit records your choice in this browser's local storage. Accepting additionally hands the Google tag already on the page a consent update saying analytics storage is permitted; on this deployment that update goes no further than the browser, because nothing is being measured for it to apply to. Declining records the choice locally and hands the tag nothing at all — it withdraws nothing, because nothing was granted in the first place. Either way the script loads independently of the banner: it is requested as soon as the page opens, before you are asked, and your answer does not gate it.

Apart from Google Analytics, this codebase loads no third-party scripts. There is no advertising on the site, and no embedded content from anywhere else.