lanlan / dev / recipes

Twelve workflows. Real client work.

Each recipe is a real situation a developer runs into when shipping a website — the prompt you'd give your agent, the tools it chains, and what you end up with. Same fictional client (Maya, photographer) the whole way down so you can read it as one project.

+ If you're shipping your own product or an in-house site, every recipe still works — you're just both sides of the handoff. Skip the invite the client step.

Need to install Lanlan first? Two lines of config →

Hand off a finished site to a client.

The site's done. The client should own it — the analytics, the form submissions, the Stripe, the domain. You want out of the loop without abandoning them.

the prompt

Invite my client maya@plumage.studio to the photographer site as a collaborator. Once she confirms, transfer ownership to her. I'll stay on as a collaborator for one week then drop off entirely.

tools

sharing(invite) → client confirms via email → sharing(transfer) → sharing(remove)

What you end up with. Your client owns the site. They get the form submissions, the analytics dashboard, the Stripe revenue, the domain renewal notices. You can stay as a collaborator if they want help, or leave entirely.

+ Or your client can manage collaborators themselves from the dashboard once they own the site.

Import an existing site and rebuild it.

Your client has an old Squarespace, Wix, or hand-built site they hate. You want their content as the starting point, not their layout.

the prompt

Pull everything from https://plumage-old.example.com — images, fonts, copy, structure. Build a new site at plumage-photography that uses that content but with a clean editorial layout. Same brand colors as the original.

tools

import_site → analyze_site → design_consultation(import) → update_files_batch

What you end up with. A new site with the old site's content and brand DNA, in a layout you actually picked. The original site is untouched until you're ready to switch DNS.

Add a contact form that emails the client.

The site needs a contact form. The submissions go to your client, not you. No Mailchimp, Formspree, or Netlify Forms in the picture.

the prompt

Add a contact form to the about page with name, email, and message fields. Submissions should email maya@plumage.studio.

tools

form(create, notify_email) → patch_file (drop <form> in HTML)

What you end up with. A real <form> on the page. Submissions stream into the dashboard and email your client directly. Spam protection on by default. No third-party services in the loop.

+ Or your client can create forms, edit notify-email recipients, and read submissions themselves from the dashboard.

Take Stripe payments on the client's account.

Your client wants to sell something — workshop tickets, prints, a digital download. The money lands in their Stripe, not yours, not a connected-account routed through us.

the prompt

Wire Stripe to the photographer site. Connect Maya's Stripe account directly. Add a "Book a session" button that creates a checkout for $250.

tools

connector(stripe) → patch_file (checkout button) → live_data (revenue counter)

What you end up with. Real payments to your client's real Stripe account. Their tax docs, their dashboard, their fees. You're not a payment middleman. The client owns the relationship with Stripe directly.

+ Or your client can connect Stripe and view payment summaries themselves from the dashboard.

Roll back a bad deploy.

Something shipped wrong. The homepage is broken, the copy is off, an image is the wrong file. You need the previous version back, fast.

the prompt

Show me the last 5 deploys for plumage-photography. Restore the one from before this morning's edit.

tools

snapshots(list) → snapshots(restore, deploy_id)

What you end up with. The previous version of the entire site is live again, in seconds. Every deploy is auto-snapshotted, so this works for any point in the site's history.

+ Or your client can browse deploy history and click Restore from the dashboard. No agent required.

Set up a custom domain (with SSL).

You're done with the .lanlan.site subdomain. The site needs to live at the real domain.

the prompt — buy through us

Check if plumagephotography.com is available. If yes, register it for the photographer site.

the prompt — client already owns it

Maya already owns plumagephotography.com. Connect it to the site and walk me through the DNS records I need to add.

tools (path A)

check_domain → register_domain (auto-connects, SSL provisions)

tools (path B)

set_custom_domain → dns_records (read) (SSL provisions automatically)

What you end up with. The site lives at the real domain with HTTPS. The registration is in your client's name. The renewal goes to them, not to you.

+ Or your client can buy domains, connect existing ones, and manage DNS themselves from the dashboard.

Add SEO and llms.txt so the site is discoverable.

Search engines and AI agents need a sitemap, robots.txt, and now llms.txt. You don't want to hand-author any of this.

the prompt

Regenerate the SEO files for plumage-photography — sitemap, robots, and llms.txt. Then verify the page-level meta tags are populated on every page.

tools

generate_seo (sitemap + robots + llms.txt) → verify_site

What you end up with. The site is properly indexed by Google, Bing, and the agentic-search clients (Perplexity, ChatGPT search) that read llms.txt. The verifier catches the meta-tag gaps you'd otherwise miss.

+ Or your client can hit Regenerate from the dashboard's SEO panel. Same files, no agent needed.

Add a blog the client can edit.

Your client wants to add posts after the handoff. You don't want them editing HTML files. You don't want to install Contentful or Sanity for a 5-post blog.

the prompt

Add a blog to plumage-photography. The client should be able to add posts from the dashboard — title, body, hero image, publish date. Render them at /blog with a simple list and per-post page.

tools

collection(create with schema) → update_files_batch (index + post template)

What you end up with. A blog the client can update from the dashboard like a CMS. New posts appear at /blog automatically. No code edits required after handoff.

+ Once the schema is set up, your client adds and edits posts entirely from the dashboard. That's the point.

Publish a draft for client review without it going live.

You finished a redesign. You want the client to see it before the world does. You don't want to deploy a staging subdomain.

the prompt

Set the new homepage to draft. Generate a 3-day preview link I can text to Maya.

tools

page_settings(set_status: draft) → page_settings(preview, ttl_hours: 72)

What you end up with. A signed URL that works for three days and shows the draft to anyone with the link. The public page is unchanged. No staging environment, no subdomain bookkeeping.

+ Or you can flip drafts and generate preview links yourself from the dashboard's page-settings panel.

Make the site installable as a phone app (PWA).

Your client wants their site to live on their phone home screen and open without browser chrome. Most platforms charge $50/mo for this. You can ship it in one tool call.

the prompt

Enable PWA install for plumage-photography. Make the icon the brand mark.

tools

page_settings(set_pwa, enabled: true) → add_image_from_url (icon, 512×512)

What you end up with. Your client visits the site on their phone, taps "Add to Home Screen," and the site installs as an app. Tap the icon, the site opens full-screen. No App Store, no review queue, no developer account.

+ Or your client can toggle PWA install themselves from the dashboard's page settings.

Migrate the design while keeping the content.

Your client's content is fine. The site looks dated. You want to redesign without retyping anything.

the prompt

Run the full design consultation on plumage-photography. Use https://www.areaofwork.com as a visual reference. Keep all the existing content — just retheme.

tools

design_consultation(team) → capture_reference → analyze_site → update_files_batch

What you end up with. Same headlines, same images, same copy — completely different visual language. The brand brief is now the source of truth. Every future edit (yours or the client's) reads from it.

Password-protect a page or the whole site.

You're staging the site privately. Or one page is for an internal audience only. You don't want a login flow — just a password on a door.

the prompt — whole site

Put the whole plumage-photography site behind the password "preview42" while we finalize.

the prompt — one page

Set just /pricing to require a password the client can share with their VIPs.

tools

page_settings(set_site_password) or page_settings(set_page_password)

What you end up with. Anyone hitting the URL sees a branded password prompt. Pass the password and the page renders. No user accounts, no login flow, no third-party auth.

+ Or your client can set or clear page passwords themselves from the dashboard.

Twelve recipes. One install away.

If your agent speaks MCP, you can run any of these tonight.

Install Lanlan Read the architecture