Companion brief — the build, end to end

How it's built

What the person on the other end of the prompt actually does, what a proposed engineering stack gets right and where it's thin, and a hands-on way to feel out what each feature would cost to run.

01 — The user's workflow

What does someone actually do to get a site out of this?

Input required: one sentence

Describe it

Chat, voice, or a screenshot upload — "artisan coffee roastery" is enough to start. Anything beyond that (a logo, hours, pricing, an existing brand voice) is optional and just makes the first draft closer to right; nothing is required upfront that isn't in the person's head already.

No input required

Review the AI-drafted version

A working page or app comes back in seconds — real content, not a wireframe. Anything treated as a factual claim (hours, prices, contact details) is flagged for confirmation rather than published silently.

Optional

Refine, if it's not already right

Ask for a change in chat ("make the hero bolder"), or click straight into the text and edit it by hand. Either path touches one section at a time — not a full regeneration.

One click

Publish

Domain, SSL, hosting, and a business email get provisioned automatically. The project stays open and editable — publishing isn't a finish line, it's a checkpoint.

How much does someone actually need to type? One sentence, minimum. Everything else the product would like to know — hours, pricing, a logo, a tone — is asked for as an optional add or a post-generation confirmation, never a blocking form. The whole pitch is zero setup.

What about existing branding? Two paths, both optional: pick a curated starting point from the design-token library, or upload real brand guidelines — a logo, a palette, a style PDF — and the draft is built to match them instead of overwriting them. Someone with a brand already shouldn't have to fight the generator to keep it.

What actually gets delivered

A real, functional site or app

Not a static template — booking tools, dashboards, and quote calculators generate as working, database-backed features when the idea calls for one.

Live infrastructure, not just files

Domain, SSL certificate, hosting, and a business email address, auto-provisioned — nothing to configure separately.

An editable project, not a finished object

Every generated page stays open for chat-edits or direct hand-editing — the deliverable is a living project, not a one-time export.

A visible cost, not a mystery bill

Credits tracked against the plan tier as they're spent — the thing Lovable's users say they don't get.

02 — Engineering stack

The stack I'd pick, layer by layer

Not a reaction to anyone else's list — this is where I'd start, reasoned from what the product actually has to do: generate real UI/UX from a brief, let someone reshape it visually, and stay cheap enough to run at volume.

Frontend Next.js (App Router) + shadcn/ui + TypeScript Foundational

Fast to build in, well-supported, and shadcn ships accessible components you own outright (copy-in, not a runtime dependency) instead of a locked-in design system — matters once the product needs its own visual identity on top. Right call for a small team moving fast.

Design system / theming Versioned design-token library — AI selects and remixes, never invents raw CSS Design this first

This is where "sameness at scale" either gets solved or doesn't. A curated library of palette pairs, type pairings, and spacing/radius scales — the same idea the research brief's own category engine uses — means the AI is choosing and combining from something already good, not inventing colors from scratch and hoping they pass contrast. Brand intake feeds this layer directly: someone picks a curated starting point, or uploads their own guidelines (logo, palette, fonts) and the token set gets built to match instead of overwritten. Every generated site inherits a baseline of taste for free, and the pre-publish accessibility check becomes a formality instead of a rescue.

Visual editor (UI/UX) Click-to-select + inline edit + properties panel, built on the section-slot model Design this first

Chat-based edits cover content changes. They don't cover "move this," "make this section bigger," "swap this layout variant" — real UI/UX editing needs a visual surface, not just a text box. I'd build it directly on shadcn/ui and the same structured section data the AI generates — click to select a section, edit text inline, adjust structured properties (variant, spacing, color) in a panel — rather than adopting a third-party page-builder framework and inheriting its data model and UX instead of owning mine.

Database + Auth Supabase — Postgres, Auth, RLS for role/portal isolation Foundational

Enforcing internal/customer/operator isolation at the database layer via RLS is stronger than checking roles only in application code. I'd still validate roles in server actions too — RLS policies get harder to reason about as they multiply, and I don't want it to be the only line of defense.

CRUD Direct against Supabase — client + server actions/route handlers, no separate API layer Decide deliberately

Right-sized for now — a hand-rolled REST/GraphQL layer in front of the database would just be a proxy nobody needs yet. The bet I'm making explicit: this only works while this Next.js app is the sole client. The day a mobile app, a partner integration, or a public API shows up, that's a real retrofit, not a config change — I'd treat that as a Phase-0 simplification, not a permanent architecture, and say so out loud.

Background / scheduled jobs A Node/TypeScript worker (or a managed queue — pg_cron, Trigger.dev, Inngest) Decide deliberately

Pulling long-running/scheduled work out of the request-response cycle is right — serverless functions aren't built for polling loops. I'd default to keeping it in TypeScript rather than standing up a second language and deploy pipeline, unless something concrete needs Python specifically (a library only Python has, real existing depth on the team). One runtime to operate is worth protecting until there's a real reason not to.

Realtime Supabase Realtime — dashboards, notifications Foundational

Already on Postgres, so this rides the existing infrastructure instead of standing up a separate pub/sub or websocket service. Minimal-additional-infra is the right bias at this stage.

AI / LLM orchestration A dedicated layer — the plan-then-fill pipeline, queuing, retries, streaming Design this first

This is the actual product, so it doesn't get left implicit. I'd decide up front where model calls live — a Next.js server action is fine for a single quick call, but a multi-step generation (plan → fill, per the architecture above) needs somewhere that can queue, retry, and stream output back to the UI without tying up a request. Everything else in this stack exists to support this layer, not the other way around.

Overall call

The backend instincts here are sound on their own merits: Next.js/shadcn/TypeScript, Supabase for Postgres/Auth/RLS, no separate CRUD layer yet, Realtime on Supabase, one runtime for background work. What I'd add rather than assume: a design-token system and a visual editor, because together they're what stops every generated site from looking the same — and an explicit home for AI orchestration, because that's not an implementation detail, it's the product.

03 — Try it yourself

Build a flow, watch the cost add up

Drag feature cards into the box below — now including design token selection and brand-kit intake, not just content generation. Each one reveals the cheapest reasonable model for that step and its estimated cost per generation — assumed token counts, illustrative only, same spirit as the research brief.

Drag a card here to add it to the flow

Estimated cost per generation, this flow $0.0000