Remove friction from sign-up

Paste into any coding agent: Claude Code, Cursor, Codex, Copilot, Windsurf or Cline.

# Remove friction from sign-up

Every extra field and confusing error on the sign-up form of the production site loses launch visitors who were ready to try it. Make sign-up as short as it can be, clear when something is wrong, and quick to get through on a phone, without weakening security.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Weaken password storage or skip verification for actions that need it.
- Add a sign-in provider without asking.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. Measure the form

List every field, step, check and redirect between the sign-up button and the first screen of the product, on desktop and phone. Note required fields that could wait, password rules shown only after failing, and verification that blocks access.

### 2. Fewer fields

Ask only for what is needed to create the account (often just email, or a social sign-in). Move name, company, role and preferences to later, inside the product. Use the right input types and autocomplete attributes so phones fill them.

### 3. Faster options

If the auth setup supports it, propose adding a social sign-in (Google, GitHub for developer tools) or a magic link, for me to approve. Show password rules up front, accept long passphrases, and allow password managers to fill and paste.

### 4. Errors and verification

Validate inline, next to the field, in plain words, and keep what the user typed. Let users into the product before email verification where it is safe, with a reminder, rather than a hard wall.

## Done means

- [ ] Sign-up asks only for what account creation needs.
- [ ] Inputs use the right types and autocomplete attributes.
- [ ] Password rules are shown up front and password managers work.
- [ ] Errors are inline and keep input; verification does not block the first visit where it is safe.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.