Who is responsible

The responsible contact for this website is AI Engineering - Christian Rickert. Privacy questions can be sent to projects@ai-engineering.dev.

What data is collected through public forms

The contact form and pricing estimator submit project-request data into the internal lead pipeline. Depending on the form, this includes your name, email address, company or team name, project summary, optional notes, budget signal, timeline signal, consent choice, optional marketing opt-in, and basic attribution context such as the current page, referrer, and optional campaign parameter.

Files and supporting material

Some public intake flows can also request supporting files or attachments. When that path is used, the uploaded file is stored in Firebase Cloud Storage and linked to the corresponding project-request record so the delivery side can review the same context that was supplied in the form. Attachments are treated as operational project-request data, not as marketing data.

How estimator drafts are handled in the browser

The estimator stores draft answers and an anonymous estimate-session identifier in browser local storage so progress can survive refreshes and users can return to the same estimate without losing work. This local storage is functional and tied to the estimator experience.

Firebase services currently used

The current website and invited customer-access flows use Firebase Authentication, Firestore, Cloud Functions, Cloud Storage, and App Check. Optional analytics and site-performance measurement can also use Google Analytics and Firebase Performance Monitoring, but only after consent and only when those services are configured for the current deployment.

Consent-managed analytics

Optional usage analytics and performance monitoring remain disabled by default. The website shows an analytics-consent banner and records the user's consent choice in browser local storage. If consent is granted, the site can load Google Analytics where configured and can report Core Web Vitals measurements through Firebase Performance Monitoring for operational quality monitoring. If consent is denied, those optional analytics and telemetry pathways are not enabled.

Authentication and session handling

Invited customer-portal users authenticate through Firebase Authentication. Depending on the route and device, that can involve Google, Apple, email-link, or email/password sign-in. The browser-side Firebase session is persisted locally so invited users can return to the same portal workspace without signing in again on every refresh.

Internal ERM access uses Firebase sign-in as the first step as well, but the internal route does not rely on the browser Firebase state alone. After a successful ERM sign-in, the web app exchanges the Firebase ID token for an HTTP-only ERM session cookie so server-rendered internal routes can enforce operator access without exposing that session token to client-side JavaScript.

App Check and abuse protection

Supported public forms, attachment-upload flows, and customer-portal actions can request a Firebase App Check token before the request is sent. Where App Check is configured, this helps distinguish legitimate browser traffic from automated abuse and is used as an operational abuse control rather than a marketing identifier. In local emulator mode, or in deployments where no App Check site key is configured yet, that token path may be inactive.

Firebase-backed processing

Public project-request submissions are processed through the Firebase-backed application stack used by this ecosystem, including server-side actions, Cloud Functions, and Firestore records that support lead review and follow-up. Customer-portal users who are explicitly invited into a project workspace also use project-scoped Firestore reads, callable Functions, and controlled Storage downloads tied to that invited account.

Why the data is used

Request data is used to respond to project inquiries, qualify fit, prepare estimates, manage delivery follow-up, and maintain an auditable lead history inside the internal ERM. Optional marketing opt-in is used only for follow-up communications the visitor explicitly agreed to receive.

Retention and minimization

Lead and portal data is kept only as long as it is needed for project qualification, delivery operations, compliance, or auditability. The current implementation is structured to keep public visitors on the smallest necessary data path: optional analytics and performance telemetry are consent gated, while core project-request data is limited to the fields needed to respond and scope work responsibly. Session and abuse-protection mechanics are also separated by purpose: marketing analytics require consent, while authentication, session handling, and App Check exist to make the application function safely.

Your choices

You can decline analytics, avoid submitting optional notes or marketing consent, and contact the studio directly by email instead of using public forms. Requests regarding stored lead or portal data can be sent to projects@ai-engineering.dev.