EARLY-STAGE PROJECT · IN DEVELOPMENT

Privacy & contact

Impossible Hires is an early-stage project run by Nikema Prophet.

Registering your interest

The talent and hiring forms send your details privately to Nikema for founder follow-up about Impossible Hires. Submitting registers your interest only. It does not create an account, publish a profile, guarantee a match, or authorize sharing your details or exchanging contact details.

Before you submit, form answers stay in page memory. After a confirmed submission, the service stores them as described below. Closing and reopening the form preserves its answers and receipt in the current page; reloading clears that local state. A downloaded copy stays on your device, under your control. If receipt is uncertain, keep the same submission key and retry rather than starting a new submission.

PostHog receives categorical form activity, such as opening a form or confirming a submission. The interest dialog, including its fields and receipt, is excluded from replay and automatic interaction capture as described below.

The fictional profile and introduction demos

Demo profiles, companies and opportunities are invented. The profile editor and introduction simulation keep entries and choices only in page memory. The demo does not save a profile or send an introduction, and reloading or leaving clears its state. Page activity and diagnostics can still be collected by PostHog as described below. Please use invented details and leave out contact details or confidential information. External media is linked only; it is not automatically fetched, embedded or uploaded.

tiun integration and employer-pilot sandbox

The public homepage initializes tiun’s live integration so the installation can be verified. This loads resources from tiun and sends technical request information, such as your IP address and browser details, to its services. tiun may use cookies or similar technologies and recognize an existing tiun session. Loading the integration does not open checkout or take a payment. Live employer sign-in and payment collection remain closed.

The local employer-pilot rehearsal uses tiun for email sign-in and hosted sandbox checkout. Opening that local page loads tiun’s integration; signing in or using checkout sends account and test-payment information to tiun and its payment providers. Sandbox payments are simulated, but an email address you provide and technical request information can still be real personal data. Use an email account you control and test card details.

tiun manages the checkout account, sign-in session and test-purchase records. Its services may use cookies or similar technologies under tiun’s privacy policy. Our page does not receive your full payment-card number or card security code. We can receive account identifiers, email and purchase information through tiun’s verification service and business dashboard.

We use a short-lived sign-in proof to verify your account with tiun and check whether that account is assigned to the fictional employer and has purchased the exact pilot reference. The local rehearsal keeps the assigned sandbox account ID in restricted configuration. Account and purchase responses are processed for the check; the application does not save them as billing records in Neon or log sign-in proofs. Your own verified account ID can be displayed to you for rehearsal setup.

We keep that configured account ID while the rehearsal assignment is needed and remove it when the assignment is retired. Signing out does not delete tiun’s account or purchase records. Their retention and any legal recordkeeping obligations are governed by tiun’s policy; the 90-day interest-submission cleanup below does not apply to tiun records. Contact us about information we hold and use tiun’s privacy contact for requests concerning its account or transaction data.

Payment never authorizes access to candidate profiles, contact exchange or marketing. Live billing is not enabled in this implementation. Before it opens, we will update this notice for the actual billing records, purposes, recipients and retention arrangements. See our terms of service for the current sandbox scope.

Hosting and service providers

The public site uses Cloudflare Workers to serve the website and API, Cloudflare Hyperdrive to connect to the database, and Neon to store database records. The former Vercel project and its deployments have been retired. The provider serving a deployment processes the technical requests needed to operate it. Hyperdrive query caching is disabled. We do not add advertising trackers to the public site. tiun’s hosted services have their own data practices described above.

Our Cloudflare deployment has application request logs and traces disabled. Browser diagnostics sent to PostHog are separate from these Cloudflare logs. This does not mean that providers keep no internal, security, support or recovery records. Provider retention and backup practices are separate from deletion in our live database. See Cloudflare’s privacy policy, Neon’s privacy policy and Vercel’s privacy policy.

Private founder sign-in

The private founder dashboard uses GitHub sign-in and permits only Nikema’s designated GitHub account. Visitors do not need a GitHub account to use the public site. Founder authentication stores an account identifier, name and email, session information and temporary sign-in state in Neon. The application does not retain GitHub access or refresh tokens, or session IP addresses and user-agent strings. GitHub also processes sign-in under its privacy statement.

Founder sessions expire after one hour. Scheduled auth cleanup removes expired sessions and temporary sign-in state on successful daily runs; delays or backlogs can extend storage after expiry. The founder’s account identity remains until dashboard access is removed. These controls do not promise deletion of every provider-held copy.

Cloudflare Web Analytics

Public pages use Cloudflare Web Analytics to measure visits, page views and performance. The private founder pages and employer-pilot page do not load this analytics script. Cloudflare Web Analytics does not use cookies or local storage to track visitors. See Cloudflare’s Web Analytics documentation.

PostHog analytics and diagnostics

We use PostHog to understand which parts of Impossible Hires people use and to find and fix problems. When configured for a deployment, it loads on the homepage, fictional demos and employer-pilot page, including categorical interest-form events. It does not initialize on private founder pages, founder-demo pages or API/authentication routes. This can include local and preview deployments. The standalone legal pages do not load the PostHog app integration. Cloudflare’s exclusions above do not apply to PostHog.

PostHog collects page views and interactions such as clicks and form submissions, together with page URLs, referring pages, timestamps, browser and device information, and visitor and session identifiers. Interaction data can include element text and attributes. PostHog also processes the technical requests needed to receive this data, including the IP address used to connect to its service.

We send events for opening interest forms, previewing drafts and confirming submissions; starting pilot checkout and verifying purchase status. These events describe the action and relevant categories or status, rather than including form answers. After successful pilot sign-in, we associate activity with that account’s identifier. Signing out resets the browser analytics identity; it does not delete previously collected events.

PostHog also receives unhandled browser errors and failed asynchronous operations, which can include error messages, stack traces and page context. We send operational logs when a submission is confirmed, a pilot purchase is checked. These include relevant status information and the application environment. Diagnostics and automatically captured page content can contain information displayed on the page or included in an error, so please do not enter confidential or sensitive information in demos.

We have enabled session replay in PostHog to help understand usability problems and investigate errors. Replay can reconstruct page content and interactions, including clicks and scrolling. We block the whole interest dialog, including its fields, errors and receipt, from replay and automatic interaction capture. Explicit categorical form events still occur. Replay console recording and network headers and bodies are disabled; replay network entries are excluded. Inputs are masked, but other public-page text is not necessarily masked. See PostHog’s replay privacy controls.

PostHog browser storage and privacy requests

Unlike Cloudflare Web Analytics, PostHog uses first-party cookies and browser local storage to recognize returning browsers, and session storage for session-related information. Its default analytics cookie has a 365-day expiry and can be renewed during use. Local storage can remain until cleared. These identifiers are separate from your local form draft. See PostHog’s browser storage documentation.

The current app starts PostHog when configured; it does not provide an analytics consent banner or an in-site opt-out control. Browser privacy tools can block requests to PostHog, and browser settings let you clear site cookies and storage. Clearing storage does not delete information already received by PostHog or prevent new collection on a later visit. The current integration does not enable PostHog’s Do Not Track setting.

Our PostHog session replay retention setting is 30 days. This setting applies to new recordings; recordings captured under an earlier setting keep their original retention period. Expiry does not mean immediate deletion, and recordings may remain available briefly afterward. See PostHog’s recording retention documentation.

PostHog holds analytics, session recordings and diagnostic records separately from our Neon database. The 30-day replay setting does not set retention for analytics events or diagnostic logs; their retention depends on the applicable PostHog settings and service terms. The 90-day intake cleanup does not delete PostHog records. Contact hello@impossiblehires.com to ask about or request deletion of information we hold in PostHog. We may need information to locate the relevant browser or account records. For information about the provider, see PostHog’s privacy policy.

Contact the founder

For questions or requests about information you have shared directly with us, email hello@impossiblehires.com. Emailing us is separate from the interest forms and shares your message and address with us through SuperMailOS, our email host. SuperMailOS processes message content, attachments, sender and recipient addresses, and delivery information to provide the email service. See SuperMailOS’s privacy policy.

What a submission contains

Both forms ask for your name and email. The talent form also asks for a work link, your personal contribution and the work you want next. The hiring form asks for your team, project scope, compensation, autonomy and working conditions. Please do not include sensitive personal information or confidential material.

With your unchecked-by-default permission, Nikema uses these details to review your interest and contact you about Impossible Hires. The service stores them privately in Neon through its Cloudflare-hosted API and Hyperdrive connection, together with submission time, permission version, review status and a submission key/content hash used to reconcile retries. Submitting registers interest only: it does not create an account, publish a profile, guarantee a match or authorize sharing your details. Founder follow-up does not include marketing consent. Private profile sharing requires your separate approval of the exact profile, named recipient and opportunity. Permission to exchange contact details is requested separately.

Private profile sharing

Nikema can prepare a private text profile for your review. We store the exact profile, your name and verification email, the named recipient and their verification email and organization, the opportunity, an expiration date and a version identifier. Registering interest does not approve this sharing. You must review and approve that exact version and scope before the recipient can access it. Any revision requires a new review.

Nikema manually emails a one-use verification link to the recorded address and records that it was sent. This process relies on Nikema sending to the correct address; it is not independent identity verification. Keep your link private and do not forward it. Links expire within 24 hours; verified browser sessions last up to one hour and cannot outlast the profile's access period. We store hashes of credentials rather than raw access tokens, together with delivery, approval and permission timestamps. These private pages do not use our application analytics or session replay.

Both people must separately agree before the app displays their verified email addresses to each other. You can withdraw contact permission for future display. The person whose profile is shared or Nikema can revoke profile access. Access ends at the stated expiry, no later than 30 days after preparation. Revocation prevents subsequent access requests; it cannot recall information someone has already viewed or copied.

Sharing records, approvals, credential hashes and contact permissions become eligible for deletion seven days after expiry or revocation, whichever comes first, and are removed by the next successful daily sharing cleanup. Scheduling, outages or backlog can delay removal. Verification messages, replies and drafts in our SuperMailOS mailbox, including Trash copies, become eligible for removal on the same date and are removed during the next successful daily operator review. Those emails contain verification links, not profile text. We do not promise a provider-internal backup-erasure date or deletion of recipients' copies. Earlier deletion requests cover relevant sharing records as well as interest submissions and follow the recovery-reconciliation process below.

Retention and deletion

Submissions become eligible for deletion 90 days after submission and are removed on the next successful daily cleanup run. This is not a promise of deletion at the exact 90-day instant: scheduling, outages or a backlog can delay removal. Existing cleanup removes the whole submission, including its retry key and content hash, rather than keep a profile archive.

The service uses keyed hashes of your email and request IP address for abuse limits; it does not store raw IP addresses in the intake tables. These short-lived counters become eligible for cleanup after 24 hours and are removed by the next successful cleanup run. Deleting a submission on request does not immediately remove those separate counters. Hosting providers may process technical request information.

You can request earlier deletion at hello@impossiblehires.com. We may need to verify the request before removing the relevant records. Deleted information may remain in provider recovery history until that history expires. A database restore window describes self-service recovery, not a deadline for physical erasure from all provider systems. A restored database must remain unavailable until expired information and verified deletion requests have been reconciled. Separate branches, exports and other copies require separate handling. Email messages and downloaded copies are separate from the intake database.

To prevent a database restore from undoing a verified deletion, Nikema keeps separate, restricted request records in a private 1Password vault. Each record contains affected submission identifiers and verification, completion and recovery-reconciliation dates, rather than your profile or request message. Each completed record is scheduled for deletion seven days after the later of completion and expiry or reconciliation of known application copies that could undo the deletion. The current application restore window is six hours. Deleted 1Password items remain recoverable for a further 30 days. This schedule is separate from the submission's 90-day cleanup.

We remove associated request emails, replies and attachments from our SuperMailOS mailbox, including any Trash copies, on the same scheduled date as the restricted request record. SuperMailOS’s published policy does not specify a fixed recovery or backup-erasure period for individual deleted messages. Deleting a message from our mailbox does not establish immediate erasure from every provider system. If request messages are restored, we remove those copies again. Recovered application data stays unavailable until applicable expirations and verified deletion requests are reconciled. If another application copy or restore is involved, its reconciliation date is recorded before the request is closed.