Security and data handling

The application is hosted on Vercel. Data is stored in Supabase — managed Postgres for records, Supabase Storage for files a person uploads, and Supabase Auth for sign-in.

Both are US-based companies, and both are independently audited to SOC 2 Type II. Neither is a bespoke arrangement built for us — they are the same platforms a great many companies run production on, so a reviewer who has cleared either before has already cleared most of this section.

Processing may occur in the United States and in other countries where they or our other providers operate.

Access to production data inside Functioning Labs is limited to the people who operate the service, and every account that can reach it is protected by multi-factor authentication. Database rows a person owns are separated by row-level security in Postgres, not by a filter in application code, so a query written wrongly returns nothing rather than somebody else’s workspace.

A browser that has seen the site once will not make a plaintext request to it again. Connections to the database, to Stripe, to our email provider and to the AI gateway are TLS as well.

Buying coverage does not involve sending us a roster. We mint a block of single-use codes and you hand them out through your own channel — a packet, a mail merge, a graduation folder.

Each person redeems their code on whatever email address they choose, which for most people is a personal one they will still have after the program ends. We learn that a code was redeemed and by which account; we never learn which name on your roster it belonged to, because you never gave us the roster.

The account created that way is the person’s own. It is not provisioned by you, not administered by you, and it outlives the coverage window: when the window ends the extra capacity stops, and their workspace, documents and history remain theirs.

Outcomes carry a suppression threshold. Until at least 5 people have redeemed, the outcome line is withheld and says so, rather than printing a number that a small group could be reasoned backwards from. The figure is also self-reported: a person records their own landing, so it under-counts, and it should not be read against your headcount.

The one per-person fact the buyer can see is whether a code has been redeemed, and only because they issued the codes one per person and hold that mapping themselves.

Deletion is the individual’s to ask for, and they do not need your permission or ours. From their settings a covered person can also export everything in their account as a file. A deletion request is subject only to records we are required to keep, such as billing history.

A funding organization cannot delete somebody’s account, because it does not own it. Ending or exhausting a block removes the extra capacity and nothing else.

Hey Vitae uses AI for resume feedback, job analysis, interview preparation and practice interviews. A feature sends the prompt and the limited context it needs to the model serving it, through the Vercel AI Gateway or directly to the provider.

We do not use private workspace content to train AI models, and we do not sell personal information. That commitment is in the Terms of Service and the Privacy Policy, not only on this page. Each provider processes what it receives under its own terms; we name them above so a reviewer can check those directly rather than take a summary of them from us.