Lovable vs v0

Create a one-page site in Lovable for {{product}}, aimed at {{audience}} — an agency page where the work does the talking and the contact form actually submits.

Page order:
1. Hero — a two-line claim built from {{product}}'s specialty (what they make, who wins from it), with a thin strip of 5 client names underneath.
2. Featured case — one project at full width: large image area, client name, the problem in one sentence, the result as a number.
3. More work — 4 additional projects in a 2-up grid, each with title, category tag, and a single result stat.
4. Capabilities — an accordion of 4 service groups; each opens to a 2–3 sentence description plus 3 deliverable bullets.
5. Process — 3 phases (shape / build / ship — rename to fit {{product}}'s discipline) with a week-range and an outcome per phase.
6. Studio — a 2-sentence manifesto beside a team grid (photo placeholder, name, role) for up to 6 people.
7. Contact — a working form (name, email, budget range select, message) with inline validation; store submissions in Lovable's database and send an email notification on submit. Beside the form, a direct email address and a response-time promise.

Visual direction:
{{style}}

Palette: {{palette}}
Typography: {{type}}
Motion: {{motion}}

Rhythm and responsive behavior:
- Keep section spacing on one scale: 96px desktop, 56px mobile; accordion rows use 20px internal padding.
- On phones the featured case stacks image-over-text, the team grid drops to 2 columns, and the budget select becomes a full-width control.

The primary call to action is "{{cta}}" — a button in the hero and the label on the contact form's submit. When the page works in preview, deploy it and give me the live URL.

Before handing it back, verify: the form rejects an empty email and writes a row to the database; all 5 work entries show a stat; the accordion opens one panel at a time; nothing overflows at 390px; the deployed URL loads.

Build a landing page for {{product}}, aimed at {{audience}}. Generate it in v0 as a Next.js page assembled from separate components with Tailwind and shadcn/ui — one component per section (Nav, Hero, WorkGrid, Capabilities, Process, Manifesto, ContactFooter) — so any section can be regenerated on its own later.

Sections, top to bottom:
1. Nav — wordmark left; links to Work, Capabilities, Process, Contact; a small availability note on the right.
2. Hero — one oversized positioning line naming what {{product}} does and for whom, plus a one-sentence subline naming the specialty. No stock imagery.
3. WorkGrid — 6 selected projects in an asymmetric 2-column grid alternating tall and wide cards; each card carries project name, client type, one outcome metric, and a hover reveal with a one-line summary.
4. Capabilities — 5 services as full-width rows: index number, service name, 10–14 word description.
5. Process — 4 numbered steps in a horizontal band, each with a label and two lines on what the client receives.
6. Manifesto — a 3-sentence belief statement set large, then a compact team row (name, role) for up to 5 people.
7. ContactFooter — the email address at display size, studio location, social links.

Visual direction:
{{style}}

Palette: {{palette}}
Typography: {{type}}
Motion: {{motion}}

Spacing and responsive rules:
- Vertical padding py-24 desktop / py-14 mobile; internal grid gaps step between gap-4 and gap-8, nothing arbitrary.
- Below md, WorkGrid collapses to one column and hover reveals become permanent captions; Process stacks vertically along a left rule.

Derive the hero line and all card copy from {{product}} — name the specialty concretely; "we craft digital experiences" is banned. The primary call to action is "{{cta}}", shown as a Nav button and repeated above ContactFooter.

After building, check that: each section is its own component file; WorkGrid renders exactly 6 cards, each with a visible metric; the hero wraps to no more than 3 lines at 1280px; at 375px there is no horizontal scroll; "{{cta}}" appears exactly twice on the page.

Add JWT-based authentication to this app using Supabase Auth, covering the client, the database, and the edge functions.

Flows: email and password signup with a confirmation step, sign in, a magic link option, password reset, and sign out. On signup, insert a row into a profiles table keyed to the new user id.

Route protection: redirect signed-out visitors from any authenticated route to /login with a return-to parameter, and send signed-in users away from /login. Keep the session in the Supabase client so a refresh does not log anyone out, and refresh tokens silently instead of bouncing to login when the access token expires.

Database: enable row level security on every user-owned table and write policies against auth.uid(), leaving no table with policies disabled.

Edge functions: each function reads the Authorization header, verifies the JWT through the Supabase client, and returns 401 with a JSON error body when it is missing or invalid. No function may fall back to the service role for user-scoped reads.

UI states: a loading gate while the session restores so protected pages never flash before redirect, inline errors for wrong credentials, and a resend link on the confirmation notice.

Acceptance: an expired session on a protected page recovers without a visible logout, calling an edge function with no header returns 401 not 500, password reset works end to end from the email link, and querying another user's rows from the browser console returns nothing.

Add JWT authentication to an existing Next.js App Router project without pulling in a full auth provider. Route handlers: app/api/auth/login/route.ts verifies credentials against a users table in {{database}} using bcrypt comparison, then signs a short-lived access token and a longer refresh token with the jose library, both delivered as httpOnly, secure, sameSite strict cookies, never returned in the JSON body or stored in localStorage. app/api/auth/refresh/route.ts rotates the pair, and app/api/auth/logout/route.ts clears both cookies. Protection: middleware.ts guards everything under /dashboard and /api/protected, verifying signature and expiry, redirecting browsers to /login with a from query param for post-login return, and answering API calls with a JSON 401 instead of an HTML redirect. Secrets: read JWT_SECRET from env, and if it is missing show a plain configuration notice in the preview instead of crashing. UI: a /login page using shadcn/ui Form with inline field errors from server-side zod validation, a generic invalid credentials message that never reveals whether the email exists, and a disabled submit state while the request is in flight. Edge cases: an expired access token with a valid refresh token rotates silently on the next request, a tampered token clears both cookies and forces login, and the payload carries only the user id, no email or role claims. Acceptance: in the v0 preview, logging in lands on /dashboard, an incognito visit to /dashboard bounces to /login, and logout revokes access immediately.