What we collect, why, who else touches it, how long it is kept, and how to get it back or get rid of it.
Last updated 9 August 2026
codetest.dev is operated by Alberich Labs LLC, 418 Broadway, Ste N, Albany, NY 12207 (support@codetest.dev). "We" and "us" mean Alberich Labs LLC, the company you contract with and the party bound by the commitments below; "codetest.dev" is the service it operates and the domain your email and receipts come from.
Two groups have data here and our obligations differ. Customers sign up, create an organisation and run assessments; we determine how their account data is handled, and this policy is our commitment to them.
Candidates never sign up; they open a link a hiring team sent and write code. That team determines what is collected, for what purpose and for how long, and we operate the software that collects it on their instructions: the hiring organisation is the controller, and Alberich Labs LLC, operating codetest.dev, is the processor acting on its behalf. A candidate's question about their data therefore goes first to the team that invited them, and we act on that team's instructions.
From customers, at sign-up: name, email address, a hashed password and the organisation's name. If you subscribe, Stripe holds your payment details and we hold only the identifiers that let us query your subscription with Stripe.
From candidates, during an assessment: the name and email address the hiring team entered on the invite; the code written in the editor, captured as it is written; each submission and its results; and a record of activity on the assessment page, shown to the hiring team as context beside the work. Those activity signals are not itemised here, because publishing the list would set out how to avoid them.
Nothing else is captured about a candidate — no webcam, no screen recording, no keystroke capture, no lockdown browser, and nothing running on their machine outside the browser tab they opened.
We count page views with Vercel Web Analytics, to see how many people reach the site and how many go on to sign up. It is cookieless: no cookie is set, nothing is stored on your device, one visitor is told from another by a hash of the request that is discarded after 24 hours, and each recorded view holds only the page, the referring site, browser and device type, and the country and city of the request — not your name, your account or your IP address.
We use no advertising trackers and build no profile of you across other sites; the only cookies we set keep a signed-in customer signed in.
Customer data runs the account: signing you in, keeping your organisation's work separate from every other organisation's, billing you, and sending the messages the product owes you.
Candidate data runs the assessment the hiring team set and shows that team the result; code is captured as it is written so that nothing is lost if a machine fails mid-assessment. The activity record is context for the reviewer — it is not a score, and nothing in the product decides anything on its basis.
We do not sell data, and we do not use anyone's code or submissions to train models.
Retention of candidate code, submissions and activity records is set by the hiring organisation that invited the candidate, which decides what is collected and why. It may choose a period between 3 months and 24 months, at the end of which we delete those records permanently. Unless it chooses a period, we keep them indefinitely: there is no date on which they are deleted, and no scheduled job removes them; they are held until the organisation sets a period or asks us to delete them. Asking for a copy or for erasure works whichever applies, and is described under "Closing an account, and asking for your data" below.
Each candidate is shown the period that applies to them, by name, on the screen they accept before starting — including where the answer is indefinite — and that wording is recorded against their assessment, so a later change to the setting does not alter what they were told. Where a period is set, a scheduled job then deletes the code, the submissions and the activity records together; deletion is permanent and irreversible.
Data in a customer account is kept while the account is open. On closure everything identifying you — name, email address, avatar, password, two-factor credentials and every organisation membership — is destroyed immediately, not at the end of a window. What remains is an emptied record containing nothing that points to you, kept indefinitely so that the scorecards and sessions you wrote keep a valid author within your organisation's hiring record. See "Closing an account" below.
One record outlives a closed account besides the emptied one above, and it exists to stop a closed account being reopened for a second free trial. In place of the email address — not alongside it — we store a one-way cryptographic hash of it, with the date the trial was taken. There is nothing in that record to send a message to and nothing in it that names anyone, and it holds no other field. It is kept indefinitely, because an end date on it would just be the date the free trial could be claimed again.
Withdrawing or archiving an assessment stops the link working immediately; that hides the work, it is not deletion.
Alberich Labs LLC engages four companies to operate codetest.dev. Each processes data only to provide the service described below; none is given data for its own purposes.
The database — the system of record for everything the product stores — runs in the United States, in Amazon Web Services' us-east-2 region, operated by Neon. No storage region is selected for Vercel, Stripe or Resend; each handles the data described above on its own infrastructure and under its own terms. If your organisation requires a particular jurisdiction, ask before signing up: today the answer is the United States.
| Service | What we use it for | What it holds |
|---|---|---|
| Neon | Operates the Postgres database the product runs on. | Everything the product stores: accounts, organisations, assessments, candidate code, submissions and activity records. |
| Vercel | Hosts and serves the application, counts page views without cookies, and runs submitted code in an isolated sandbox at grading time. | Request logs; anonymous page-view records — page, referrer, browser and approximate location, with no cookie and no IP address stored; and the candidate's submitted code while it is being graded. |
| Stripe | Takes payment for subscriptions. Card details go to Stripe and never reach us. | Customer billing name, email and payment details. No candidate data. |
| Resend | Delivers the product's email — invites, password resets and account notices. | Recipient name and email address, and the contents of those messages. |
A customer can close their own account from Settings. Your name, email address, avatar, password and the identifier linking you to Stripe are destroyed, your organisation memberships and any two-factor credentials removed, and every signed-in device signed out immediately.
The emptied record itself is not destroyed: the account is anonymised, not removed. Scorecards and sessions you created stay with the organisation you created them for — your team's hiring record, not yours alone — and need an author to point at, so past work shows as written by a former member. Nothing in that record identifies you.
Separately, so that closing an account and opening a new one does not hand out a second free trial, we keep a one-way hash of the address in place of the address itself, with the date. Nothing in it names you and there is nothing in it to write to. If you close an account and later sign up from the same address you get the service in full, but without a new trial period; if that is wrong in your case — a reused or shared mailbox, for instance — write to support@codetest.dev and we will sort it out.
If you are the only owner of an organisation, closing would leave it with its data, its members and nobody able to administer it; transfer ownership or archive the organisation first.
Candidates have no account, by design, so their route is separate: the link on the screen shown at the end of an assessment, the one in the invite email, or /data-request directly. Use it to ask for a copy of your data or for its erasure; the request goes to the hiring team that invited you, whose decision it is under the roles above, and we carry out their instruction.
Consent and erasure are separate; neither replaces the other. Before an assessment begins a candidate is shown, and accepts, a notice setting out what is recorded, who sees it and how long it is kept, and that acceptance is recorded with its date and the version of the wording shown. Accepting waives no right to a copy or to erasure, and the route above stays open whether or not the assessment was finished; equally, that route is no substitute for being told beforehand.
If either route does not work for you, write to support@codetest.dev and a person will read it.
Passwords are stored hashed, never in readable form; traffic is encrypted in transit; every query is scoped to a single organisation, so one customer's data is not reachable from another's account; and an organisation can require two-factor authentication of all its members.
We hold no security certification and claim none. If a security review is part of your buying process, ask and we will tell you where things stand.
If this policy changes materially we will email customers before the change takes effect. The version a candidate was shown when they accepted an assessment is recorded against that assessment and is not rewritten by a later edit.