DEV Community: Lauri Lännenmäki

Remixing a template with an AI agent: from download to your own site in an hour

Lauri Lännenmäki — Thu, 22 Oct 2026 08:16:55 +0000

Originally published on no-code.supply.

TL;DR

You can turn a website template into your own site in about an hour with an AI coding agent. The hour is real only if you already have your copy and images ready. Writing them takes the rest of the day.
The steps: unzip and open it, let the agent read the AGENTS.md, swap the brand (name, colours, fonts), replace the copy, add one section, run the checks, deploy.
Do it in that order, and one step per prompt. Big "redesign everything" prompts are where it goes wrong.
I'm using Tender, a landing page for company cards, in the HTML edition, and turning it into a product that has nothing to do with cards. The same steps work for the React edition and for any other template I sell.
Prompts you can copy are below.

Why this works at all

I build these templates with Claude Code. (Here's how that went.) Because I built them that way, I also wrote them so that an agent can edit them without breaking them. That's the whole trick.

An agent is good at "change this, in the way this project already does things". It's bad at guessing what the rules of an unfamiliar project are. So every template ships with an AGENTS.md, a file that says where things live, which rules must not break and what "done" means. (What goes in one, and why.)

Your job in this walkthrough is small. Make sure the agent reads that file, give it clear steps, and check its work.

What you need

A template. I'm using the HTML edition of Tender. If you're not sure which edition to buy, here's how I'd choose. HTML is the easiest to start with.
An AI coding agent that can read and edit files in a folder. Claude Code, Cursor, Codex or Copilot's agent mode all do. I use Claude Code, so the prompts below are written for it, but nothing in them is specific to one tool.
A code editor to look at what changed. VS Code is fine.
Your content, ready. This is the part people skip. Your product's name, a short description of what it does, a sentence for each feature, your prices, your contact details, and the images or logos you want to use. Put it all in one text file.
A free account on a static host for the last step. Vercel, Netlify or GitHub Pages all work.

No Node, no terminal and no build step for the HTML edition. For the React edition you'd also need Node, and you'd run npm install and npm run dev.

Step 1: Download, unzip, open

After you buy, the download is a zip file from Polar's customer portal. Unzip it somewhere you'll find it again.

Tender is a landing page for a spend-management product: company cards for creative studios, with live budgets and receipts that match themselves. I picked it because its sections are the ones most product sites need (features, how it works, pricing, FAQ, a call to action), so it's a fair test of how far one template stretches. For this post I turned it into Larder, a made-up stock and ordering app for restaurant kitchens. No payment cards anywhere.

For Tender's HTML edition the folder looks like this:

index.html                the page, all the text in it
404.html, privacy.html
assets/css/tokens.css     colours, fonts, sizes. Start here to rebrand
assets/css/main.css       layout and section styles, in page order
assets/js/effects/        the card, the toasts, the calculator and the other demos
assets/fonts/             the included fonts, with their licences
assets/img/               favicon, social-share image
README.md, DESIGN.md, AGENTS.md

Double-click index.html. The site opens in your browser. That's the template, running, before you've done anything.

Now open the folder in your agent. In Claude Code that's cd into the folder and run claude. In Cursor it's File, Open Folder.

Tender as it comes out of the zip, opened straight from the folder.

Step 2: Let the agent read the AGENTS.md

This step takes thirty seconds and saves the most trouble.

Most agents read AGENTS.md on their own when they start. Don't rely on it. Ask, and make the agent tell you what it found. If it can't repeat the rules back, it didn't take them in.

Read AGENTS.md, README.md and DESIGN.md in this folder. Then tell me in
five bullets: what this site is, where the colours and fonts live, where
the copy lives, which rules must never break, and what has to be true
before you say a change is done. Don't edit anything yet.

For Tender, a good answer mentions things like these, all from its AGENTS.md:

There is no build step and there must never be one. The page has to keep working when index.html is opened from disk.
Colours and fonts live in assets/css/tokens.css, not in main.css.
The demos ship in their finished state. If you change a number a demo starts from, the HTML has to change with it.
No external requests: no CDNs, no Google Fonts, no analytics.
Exactly one <h1>, visible focus styles, and prefers-reduced-motion respected.

If the summary skips the build-step rule, say it once more in your own words. Without it, the first thing a helpful agent does is add a bundler.

Step 3: Swap the brand

Do the brand in three small passes, so you can look after each one.

Colours first. Tender's tokens.css starts with a block called "Brand, start here": a background, a primary colour, a secondary one, an accent and the text colour. Every translucent version of them (hairlines, shadows, glass) is mixed from those values, so changing five lines recolours most of the page.

Rebrand the colours. Primary: a deep plum, #3B1E3F. Secondary: butter,
#F2D38A. Accent: tomato, #E5482F. Background: a warm white, #F7F3EE.
Change them in the Brand block of assets/css/tokens.css, and update the
darker and paler versions below it to match. Then search the whole
folder for the old hex values and list every place they still appear.
Check that text in the accent colour still reaches 4.5:1 on the
background, and tell me the ratios you got.

That last search is the part that matters, because "most of the page" isn't all of it. Tender's README warns that a few brand values are typed out in the HTML pages, the web manifest and the favicon. In my run the search found more than the README lists: the footer's big wordmark, the small card inside the phone mock-up, the text on one of the feature tiles and the edge of the card were all green, written straight into main.css. Each was a line or two to change, and the page would have shipped with green bits on a plum brand without them.

The card needed its own decision. Tender's README says the card finishes are illustration, not brand colour, so they don't follow the tokens. That's on purpose: a metal card has its own shading. The agent restyled the green finish into a plum one, following the README's "Change the card design" recipe, and renamed the swatches in the card maker to match.

Then fonts. Swapping a font is more than changing a name. The file has to be in the folder, there has to be an @font-face rule, and the token has to point at it.

Replace the sans font with <your font>. I've put the .woff2
files in assets/fonts/. Add the @font-face rules in assets/css/fonts.css,
update --f-sans in tokens.css, and update the font preload
script in the head of every HTML page if file names changed. Put the
licences in assets/fonts/licenses/ and update CREDITS.md and fonts.json.
No Google Fonts links.

"Every HTML page" is there because of my run. The README says to update the preload script in index.html. The 404 and privacy pages have the same script, and they'd have kept asking for font files that no longer exist.

The "No Google Fonts links" line is not decoration. An agent's first instinct for a new font is a link to a font service. That breaks the no-external-requests rule and your privacy page.

Pick a font with the same proportions. A designed layout is fitted to its font: three-line headlines, buttons sized to their labels, numbers lined up in columns. Swap in a wider font and headlines wrap onto a fourth line; a narrower one leaves gaps. Tender is set in Onest, so I asked the agent to compare the self-hosted fonts I already had against it: the width of the headline and of a line of body text, and the height of a lowercase x.

Compare these fonts against Onest at the weights the page uses: the
width of the hero headline at 600, the width of a body sentence at 400,
and the x-height. Report each as a ratio to Onest, then tell me which is
closest but still looks clearly different.

Schibsted Grotesk came out within 1% on every measure: the headline 0.6% wider, body text 0.7% narrower, the same x-height. It looks clearly different, with sharper, more squared-off letters than Onest's rounded ones, but every line on the page breaks in the same place. For the monospace I used Geist Mono, which I already had.

Then the name. The product name is in the nav, the title tag, the footer, the 404 and privacy pages, the web manifest, the social-share tags, the card itself and the notifications.

The product is called "<your name>", not Tender. Find every place the
old name appears that a visitor or a search engine can see (all three
HTML pages, site.webmanifest, the meta tags, the structured data in the
head, alt text) and update it. Leave the window.Tender namespace in the
scripts alone. List the files you changed.

Two things from my run. First, don't let the agent find-and-replace the name across the whole folder. The scripts use it as their namespace (window.Tender), and renaming that is how you break every demo on the page at once. Second, the name isn't only in the HTML. The little "tender" label on each notification in the hero is written in toasts.js. Ask the agent to search the scripts for the name as visible text, not as code.

Open the page, refresh, look. If something is off, fix it now, before the copy goes in.

After the brand pass: plum, butter and tomato, Schibsted Grotesk, and the name Larder. At this point it's still a card product. That changes in the next step.

Step 4: Replace the copy, or the whole idea

This is the long step, and it's the one that decides whether you finish in an hour.

In the HTML edition most of the text is in index.html, one section after another, and each section starts with a banner comment that says "SECTION:" and the section's name, like Hero or Pricing, so you and the agent can search for it.

Work one section at a time. Paste your content file in, and tell the agent which part is for which section.

Here is my content (below). Rewrite the Hero section of index.html using
it. Keep the same HTML structure, classes and data attributes, and keep
headlines about the same length as the originals so they still fit the
layout. Change text only. Don't touch any other section.

<paste the hero copy>

Then the same for Features, How it works, Pricing, and so on.

Two honest warnings:

Length matters in a designed layout. Tender's headline is three short lines with a hand-drawn underline under one word. In my run the headline went from "Every card knows which job it's for" to "Stock that orders its own lemons". I kept the new lines about as long as the old ones (ten, ten and twelve characters), so the headline still breaks into three lines and the underline still sits under one word. Check it at phone width straight away.
Don't ask the agent to invent your content. It will, confidently, and it will sound like every other product. The template's copy is written in a specific voice. Yours should come from you. Use the agent to fit your words in, and to tidy them, not to produce them.

Some of Tender's copy isn't in the HTML, because it changes while you watch: the notifications in the hero, the receipts and approvals in the feature tiles, and the calculator's sentence. The README's "Edit the text" section lists which script holds each one. Give the agent that list, or it will rewrite the HTML and leave the old product's receipts playing on a loop.

Your currency is part of the copy. Tender is priced in euros. Larder is American, so in my run everything moved to dollars. Tender's AGENTS.md says amounts are formatted in four scripts, which need to change together, and the HTML has the same amounts typed out for when the page first loads.

Switch the site from euros to US dollars. AGENTS.md lists the four
scripts that format amounts: change the locale and currency in all four.
Then change every euro amount typed into index.html and the scripts.
Before you finish, look for anything that converts between currencies
and check it still makes sense.

The last sentence of that prompt is the one I added after my run. A plain swap of "€" for "$" left one feature tile wrong: it shows foreign spend converted into your home currency, so it listed "USD $860" being converted into dollars at the old euro rate. The fix was to make that row euros and give the tile dollar rates. It's the kind of mistake that looks fine at a glance, and that's exactly why it's worth asking for.

Some things a currency swap shouldn't touch. Tender talks about VAT, and an American product would talk about sales tax. That's a decision about your business, not a find-and-replace, so in the first pass the agent listed those places for me instead of changing them. They went later, with the rest of the old idea.

Changing what the product is. Most people stop at new words for the same kind of product. A template stretches further than that, if you know which parts are design and which parts are the demo product. In Tender, the card is everywhere: the hero, a "make a card" section, the phone screens, the freelancer tile and the fan of cards at the bottom. Larder doesn't sell cards, so all of it had to change.

Larder isn't a card product. It's stock and ordering software for
restaurant kitchens: counts from your phone, par levels per site,
supplier orders that write themselves, delivery notes checked against
the order. Go through the page section by section and list everything
that only makes sense for a card product: objects, demos, copy, legal
text, structured data. Don't change anything yet.

Ask for the list first. Mine had more on it than I expected, and seeing it whole is how you decide what to replace, what to delete and what to keep. Then I worked through it one section at a time, like the copy:

The hero card became a paper order. Tender's card sits on a stage that tilts with your cursor. AGENTS.md says the script only needs an element with the id heroCard, so the agent swapped the card for a supplier order docket with the same id. The tilt, the shadow and the entrance animation all carried over without touching the script.
The card maker was deleted. There was nothing to replace it with, and the README says a section can be cut safely. It can, on that page. The 404 and privacy pages have their own copy of the nav and footer, and both still linked to the deleted section. Search all the pages for links to anything you remove.
The demos got new data. Receipts became delivery notes, approvals became big orders, freelancer cards became prep labels that count down to their use-by date. Most of that is data in bento.js and the other effect scripts, so the HTML and the scripts change together.
The invisible parts. The legal text in the footer described an e-money licence. The structured data in the <head> still listed the old plan names, priced in euros, which the currency pass had missed because it wasn't on the page. The privacy page described card payments. None of it is visible at a glance, and all of it would have shipped.

The same template as stock and ordering software. The tilting card is now a supplier order, on the same stage, moved by the same script.

A word on where this copy came from. For a made-up product, I let the agent write it, which is exactly what I said not to do with your real site. It's placeholder for a demo. Yours should come from you.

Step 5: Add a section in the template's style

This is the test of whether your agent is following the project, or just writing HTML.

Tender's AGENTS.md has a recipe for it: start from the Features or Calculator section, open with the numbered rail ("(06) Venues"), use the shared heading and lead paragraph, build with the existing panels and tiles, and add the section to both navs. If you ask for a new section without mentioning any of that, the agent will often write something that looks fine in isolation and wrong next to everything else.

Add a section called "Venues" between Stories and Pricing, using the
recipe in AGENTS.md ("Adding a section in Tender's style"). Three tiles,
one per restaurant, each with its monthly spend, its budget and a bar.
Use the existing tokens, tiles and reveal attributes, no new colours and
no inline styles beyond the bar's width. Add it to both navs, and
renumber the rails and the phone menu after it.

The words doing the work are "use the recipe in AGENTS.md". You're pointing the agent at the file, rather than describing the design again from memory.

Tender numbers its sections, "(05)" for Stories, "(06)" for Pricing, and the phone menu repeats the numbers. A section in the middle means renumbering everything after it, and the recipe says so. That's why the prompt asks for it.

Check the result. The new section should be impossible to tell apart from the ones around it: same rail, same heading, same tiles, same reveal. If it isn't, ask the agent to compare it with the section it copied and list the differences.

The new Venues section. Built from the template's own tiles and tokens, plus a few lines of CSS for the grid and the bars.

Step 6: Replace the images

Tender has almost no image files. The card, the phone, the receipts and the logos are drawn in HTML and CSS, so they followed the rebrand on their own. The order docket that replaced the card is HTML too, which is why the same docket could also fill the fan of cards at the bottom of the page. What's left is the social-share image, the home-screen icon and the logos in the marquee.

The closing section. The fan of metal cards is now a fan of supplier orders, built from the same docket as the hero.

Most templates have more images than that, and the steps are the same:

Put your images in assets/img/, already resized. A hero image doesn't need to be 6000 pixels wide.
Ask the agent to use them, with proper width and height, real alt text, and loading="lazy" below the fold.

Replace the logos in the marquee with the SVG files in assets/img/logos/.
Follow the README's "Use your own logos and images", update the
marquee's aria-label to list the names, and don't link to any external
image host.

<one line per logo: file name and company name>

Also replace assets/img/og-image.png, the picture shown when someone shares your link.

Step 7: Check it

Every template I sell has the same definition of done: no console errors, no horizontal scroll from 360px to 1920px wide, visible keyboard focus, a complete page with reduced motion on, and one <h1>. Tender's AGENTS.md ends with a checklist of this kind, and it adds its own items, like the page still making sense with JavaScript off.

The point of that list is that you can hand it to the agent, and also check it yourself. Don't take "all done" as an answer.

Run through the "Before you finish" checklist in AGENTS.md and report
each item as pass or fail, with how you checked it. Open the page at 360,
390, 768 and 1440px wide and tell me if anything overflows or wraps
badly. Search the project for any http:// or https:// URL that loads a
resource and list them. Check that there's still exactly one h1.

Then do the parts an agent can't: open the site on your phone, tab through it with the keyboard, turn on reduced motion and reload, and run Lighthouse in Chrome DevTools. Don't compare your scores with the ones on the template's page. Compare them with the template you downloaded, before you changed anything.

The new hero at 360 pixels wide.

My remixed page had no console errors, made no requests to other servers, and didn't scroll sideways at any width from 360 to 1920 pixels. Lighthouse on mobile gave it 89 to 93 for performance, 96 for accessibility and 100 for best practices and SEO, the same as the untouched Tender on the same machine. (The 96 is Lighthouse catching the manifesto's words halfway through lighting up as you scroll. The untouched template gets the same note.)

Step 8: Deploy

The HTML edition is a folder of static files, so deploying it is the easy part.

Netlify or Vercel: drag the folder onto the dashboard, or connect a Git repository. No build command, and the publish directory is the folder with index.html in it.
GitHub Pages: push the folder to a repository and turn Pages on.

For the React edition the template is a Next.js static export. Run npm run build and publish the out folder, or import the repository into Vercel or Netlify with npm run build as the build command and out as the output directory.

When it's live, check three things the local version can't show you: your own domain works over HTTPS, the share image appears when you paste the link into a chat, and robots.txt and the sitemap point at the right address.

How long it actually takes

Here's the honest version. I timed my run with Claude Code. The agent's part took about twelve minutes: under two for the colours, the fonts and the name, under a minute for the dollars and the exchange-rate fix, under a minute for the Venues section, about seven for turning the card product into a stock app, and a minute or two for the checks. Lighthouse took longer than any single edit.

Twelve minutes is the agent's time, not yours. Your part is reading what it changed and looking at the page after every step, and that's the part I'd never skip.

The copy in my run was placeholder for a made-up product, which is why it was quick. Real copy is the step that isn't fast. If you have it ready, the whole thing fits in about an hour. If you don't, you're writing for most of a day, and the agent can't change that for you. It can only fit what you write into the layout.

I'd budget it like this: one hour for the template, and as long as you need for your own words.

What goes wrong, and how to steer it

These are the ones I see most.

The agent adds a build step. It wants a bundler, or a package.json, or a framework. Fix: the build-step rule is in AGENTS.md, so quote it back: "No build step. The page must open from disk."
It reaches for an external font, icon set or CDN script. Fix: "No external requests. Put it in assets/." Then check the files for URLs.
It renames things it shouldn't. A find-and-replace on the template's name also hits the code that uses it. Fix: say which files the name lives in, and that assets/js/ isn't one of them.
Your words are longer than the demo's. Headlines and wordmarks are sized for the demo text. Fix: check the page at phone width after every change, footer included.
It swaps symbols without reading what they mean. A currency, a time zone or a unit can be part of how a demo works. Fix: ask it to check anything that converts or calculates after the swap.
Deleting a section leaves links behind. The page you deleted it from is fine. The other pages, with their own nav and footer, still point at it. Fix: ask the agent to search every HTML file for links to what you removed.
It changes main.css when it should change tokens.css. The colours drift, and your next rebrand takes twice as long. Fix: say which file in the prompt.
It says it's done and it isn't. Fix: ask for the checklist item by item, with how it checked each one, and look at the page yourself.
The session gets long and the agent starts forgetting the rules. Fix: start a new session and have it read AGENTS.md again. It has no memory of yesterday, only the file.

FAQ

Do I need to know how to code?

Not to follow this. You do need to be able to open a folder in an editor and look at a browser. If you can describe a change clearly, the agent can make it. The HTML edition is the gentlest start because there's nothing to install.

Which agent should I use?

Whichever you already pay for. All the templates ship with an AGENTS.md, which most agents read, and the React edition also has a CLAUDE.md that points at it. I use Claude Code.

Will the agent break the template?

It can, and the AGENTS.md is there to make that less likely. Keep the original download next to your working copy, or put the folder in Git, so you can always compare and undo.

Can I use the template for a client?

Yes. The licence covers unlimited projects, your own and your clients', and you can charge for the sites you build and hand them over. What you can't do is resell or share the template itself, modified or not, as a template or starter. The license page has the full terms.

Wrap-up

Same template, same layout, same scripts. A different product, about twelve minutes of agent time later.

The shape of the process is simple: make the agent read the rules, change one thing at a time, and check the result yourself. The template does the design. The agent does the typing. You do the part that was always yours, which is deciding what the site says.

If you try it, I'd like to hear how long it took you. Tell me on X or at contact@no-code.supply.

Tender is the template I used here. Every other template works the same way, so pick one and start from its README.md.

How to make your website stand out: seven ideas you can steal

Lauri Lännenmäki — Thu, 22 Oct 2026 08:03:57 +0000

Originally published on no-code.supply.

TL;DR

The thing people remember about a website is rarely the font or the colour. It's one idea that only makes sense for that business.
The best place to find that idea is the thing you sell: its numbers, its materials, its paperwork, its hours, its process.
Seven examples from my own templates, one or two ideas each: lead with your one number, use odd, true numbers, borrow a format from print, let people use the product, show your working, let the photos carry the effect, draw the hard part.
Most of these cost nothing. The words and the numbers do most of the work. The fancy effect is the last ten per cent.
One test before you keep an idea: could it sit on a competitor's site? If yes, it's decoration.

The follow-up to "keep one thing that's only yours"

In the post about AI slop I said every site needs one thing nobody else has. A photo, a line, a tool, a number that's true.

That's easy to say and hard to do. So this post is the how.

I'm Lauri Lännenmäki, a design engineer, and I make website templates. Every template starts with a made-up business and one interaction people should remember. I pick that before any code exists. (More on how they're made.)

Below are seven of them, with what each one does and how you'd steal the idea for your own site. You don't need to buy anything, and you don't need to know what a shader is. Most of these work in plain HTML, in Framer, in Squarespace, wherever.

The rule: take it from the thing you sell

Here's the pattern across all seven. The memorable part isn't an effect that someone picked from a gallery. It comes from the business itself:

a bike shop leads with how much the bike weighs
a restaurant shows its fire's opening hours
a fund that writes long essays looks like a printed journal
a type foundry lets you type
a photographer's photos behave like film

None of those would make sense on anyone else's site. That's why they stick.

The swap test

Before you keep an idea, ask two questions:

Could it sit on a competitor's site, unchanged?
Could it sit on a site in a completely different industry?

A glowing gradient blob passes both. So does a bento grid. That's decoration. A seat map of your dining room fails both, and that's the one you want.

1. Lead with your one number (Vela)

Vela is a pre-order site for a city e-bike. The hero doesn't open with a slogan. It opens with 15.8 kg, set huge, and then one line: "The stairs just lost the argument."

Vela: the weight is the headline, and the paragraph says what it means.

The paragraph under it translates the number into a day: light enough to carry up four floors with a coffee in your other hand. A spec becomes a picture in your head.

Further down, the range gets the same treatment. Instead of "90 km range" in a table, the page pins a city and rides through it as you scroll, from 07:40 to 22:15. "One charge. Sunrise to last orders."

And when you pick a frame colour, the whole page repaints in it, not just the bike.

Steal this:

Find the one number that sums up why someone buys from you. Weight, time, price, distance, how many, how few.
Make it the biggest thing on the page.
Write the sentence under it that says what the number means in someone's day. "15.8 kg" is a spec. "Carry it up four floors with a coffee" is a reason.

2. Use odd, true numbers (Hearth)

Hearth is a tasting-menu restaurant in an old forge. There's a row of numbers about the fire:

0 gas lines in the building. Everything is cooked on wood, or not cooked at all.
11 m chimney, laid in 1893.
1.4 t of oak burned a month.
3 zones on the fire bed.

Hearth: four numbers nobody else could put on their site.

Compare that with the usual row of stats: 10x faster, 99.9% uptime, 500+ happy customers. Round numbers sound made up, because they usually are. Odd numbers sound measured. And a zero can say more than a big number.

The other detail I like: a status line at the top of the page that says when the fire is lit. "The fire is resting · lit tomorrow, 16:00." It's worked out from the opening days, in the restaurant's own time zone, so it's always right. It's opening hours, written as if the building were alive.

Steal this:

Write down ten true numbers about your business. Keep the ones only you could have. The year the building went up beats "est. 2019".
Turn your opening hours into a sentence that changes with the time of day. "Open now, until 18:00" is a start.

3. Borrow a format from print (Parallel)

Parallel is a venture fund that backs unfashionable infrastructure. Its headline is "The future is mostly plumbing." And the whole site is set like a printed quarterly.

Parallel: a fund website that reads like issue three of a journal.

The conventions come straight from paper:

an issue number and "filed from Pittsburgh & Rotterdam" under the header
a page number in the header that changes as you scroll: "p. 1, Front page", then "p. 2, The thesis"
a contents list with dotted leaders and page numbers
a drop cap, and footnotes that slide into the margin
figures with numbers, like "Fig. 1, Two partners, one direction". It labels the two hairlines across the page, which drift apart and back as you scroll and never touch.

Even the portfolio table plays along: "Gaps in the numbering are companies in stealth."

The format does a job before anyone reads a word. A fund that publishes long essays looks like it thinks in years, not quarters. You believe the essay a little more because of how it's set.

Steal this:

Think of a printed thing your customers already trust. A menu, a receipt, a field guide, a ticket, a spec sheet, a lab report, a recipe card.
Borrow three of its conventions, not all of them. Page numbers and a drop cap are enough to read as "journal". Twelve of them and it's a costume.

4. Let people use the product (Ferro Type)

Ferro Type is a type foundry. Most font sites show a pangram and a price. This one lets you play with the font before you're asked to buy it.

Ferro Type: every slider is a real axis in the font file.

The hero word reacts to your cursor. Each letter gets heavier the closer you are and wider depending on where you are.
The type tester has a slider for each axis in the font file, and a button that copies the CSS for whatever you've made.
The glyph inspector works with the arrow keys, "because we're not animals". Each glyph gets a note: "Flat apex, cut at 4°. A pointy one looked like it wanted to sell you something."

That last bit matters as much as the tester. The small copy is where a site gets its voice. Nobody reads a hero twice, but people do read the captions.

(The demo uses Roboto Flex, a free variable font from Google Fonts, standing in for the foundry's own. If you've never played with variable font axes, it's a good one to start with.)

Steal this:

What's the smallest piece of your product you can put on the page? A calculator, a sample, a before and after, a quiz, a sound.
Then write the small stuff, like tooltips, captions and empty states, in the voice of the person who made it.

5. Show your working (Datum)

Datum is a portfolio for a designer who also builds. There's an Inspect switch in the header (or press I). Turn it on and the page draws its own 12-column grid, the spacing between sections, the type specs, and a live measure of whatever's under your pointer. It reads all of that from the real layout, so it can't lie.

For someone who sells design and code, the site is the portfolio piece. Inspect mode just lets you check.

The rest of the page is honest in a quieter way:

Datum: prices on the page, and a week strip that shows how long each one takes.

Prices are on the page. A two-week sprint is a fixed €8,500.
Every project and service has a week strip: a row of cells split into design weeks and build weeks, on the same scale. You can see at a glance that one project took twelve weeks, and how much of that was building.
The contact section says when the next opening is (2 February 2027) and how fast you'll get a reply.

Steal this:

If you sell a service, show the process as a picture, not a paragraph. A row of boxes with weeks in them is enough.
Put a price on the page, even a "from" price. Nothing feels more confident than a number.
Say when you're next free. It answers the question people are too polite to ask.

6. Let the photos carry the effect (Halation)

Halation is a portfolio for a photographer who shoots in low light. Its effects all come from photography itself:

The hero photo fades in from the dark under a fine grain.
An "hours" viewer steps through twenty photos in the order of the clock. Each one dims to dark and the next develops back up, like a print in a tray.
The series pull each frame into focus as you scroll, next to a lens distance scale that turns as you go.

Halation: one photo, the name, and a caption with a place and a time.

Everything else stays out of the way: wide capitals for the name, small captions, no decoration. The interface is quiet so the photos can be loud.

And look at the caption: "Kaamos. Pallas Fell, 12:40. No sunrise." A place, a time, and one fact. It does more for the photo than "Winter landscape" ever could.

(Under the hood, the effects run as WebGPU shaders over the real images, with a plain CSS version of each for browsers that can't. I didn't write those shaders. I asked for the effect, and the agent built it.)

Steal this:

If your work is visual, find the effect in your own medium. Film develops, lenses focus, paint dries, wood gets sanded, a cake rises. That's a better animation than a fade-up that every site has.
Caption every image with where, when and one detail.
When the images are good, make the rest of the page quieter, not louder.

7. Draw the hard part (Good Dirt)

Good Dirt is a cracker brand that buys its grain from regenerative farms. It's the opposite of quiet: a yellow sunburst, illustrated boxes dropping into the hero, a headline that says "Crunch from the ground up."

But its best idea is a diagram.

Good Dirt: the why, drawn as a soil cross-section you dig through by scrolling.

"Regenerative farming" is the reason the brand exists, and it's hard to explain in a sentence. So the page doesn't try. It pins a cross-section of a field and digs 120 cm down as you scroll. Roots, fungi and worms grow in as you pass each layer. The chapters have names like "The underground internet" and "The night shift". No soil-science degree required.

The flavour cards do the voice trick from Ferro in a spec table:

Tastes like: sourdough, sea spray, Sunday
Pairs with: smoked salmon, cream cheese, a Tuesday
Crunch: 9 / 10

Two real facts, then a joke in the last slot. It reads like a label and sounds like a person.

Steal this:

Find the part of your story people nod along to without understanding. Turn it into a drawing they move through: layers, steps, a timeline, a map.
Write your product specs as a table, and let one line in each be human.

Where to look for your own idea

You're not making a bike, a forge or a type foundry. That's fine. Every business has the same places to dig:

Numbers. What you can measure: weight, hours, distance, years, batch numbers.
Paperwork. The documents your trade already has: menus, invoices, tickets, certificates, plans, receipts.
Tools and materials. What's on your desk or your workbench, and what it does: a lens, a fire, a ruler, dough.
Time. When you're open, when things happen, how long the work takes, what changes by season.
Process. The steps between "hello" and "done". People love seeing how something is made.
Words. The jargon of your trade, explained once, kindly.

Pick one of these and push it further than feels comfortable. One idea, done properly, beats five done halfway.

If you work with an AI agent, it's surprisingly good at the brainstorm, as long as you give it the facts:

Here's what my business does, who buys from me and why: [two or three
sentences]. List 20 things that only exist in my line of work: numbers I
could measure, documents and forms my trade uses, tools and materials,
things that happen at a particular time of day or year, and steps in how
the work gets done. For each, suggest one way it could appear on my
website. Skip anything that could appear on a website in another industry.

Most of the list will be meh. You're looking for the one that makes you go "oh, of course". Then, if you build with an agent, write it into your AGENTS.md as a rule, so the agent doesn't smooth it away on the next change.

What you don't need

Look back at the "steal this" lists. Almost nothing on them needs code:

a big number and a sentence about it
ten true numbers
three conventions from a printed thing
prices and dates
captions with a place and a time
a spec table with one joke in it

That's writing and layout. The pinned scroll scenes and the shaders are the last ten per cent. They're fun, and the templates have them because templates are a showcase. But a site with the right number in the headline and no animation will be remembered. A site with a WebGL blob and "Elevate your workflow" won't.

Do the cheap version first. Add motion only if it still needs it.

FAQ

What if my business is boring?

Then you're in good company. Parallel's headline is literally about plumbing. "Boring" usually means "nobody has explained it well yet", and that's an opening. The numbers and the paperwork are often where boring businesses are most interesting.

Do I need animation for a site to stand out?

No. Every idea above has a version that's just text and layout. Motion helps when it shows something real, like a photo developing or a field being dug. It hurts when it's there because the builder had it.

Won't one idea make the site feel gimmicky?

Only if it's not true. A seat map is a gimmick at a restaurant that doesn't take bookings. Keep the idea tied to something real about you, and keep the rest of the page plain, and it reads as character, not a trick.

Can I use a template and still stand out?

Yes, if you change the parts that carry the idea. Swap in your own number, your own captions, your own paperwork. If you keep the template's idea, you'll have someone else's idea. I wrote more about that in the slop post.

Wrap-up

The sites people remember aren't the ones with the most effects. They're the ones where you can tell who made it and what they sell in a few seconds, because the page is built out of that.

So look at what you sell. Find the number, the paper, the tool, the hour or the step that only you have. Put it on the page, and push it.

If you want to see these seven ideas working, every template has a live demo: Vela, Hearth, Parallel, Ferro Type, Datum, Halation and Good Dirt.

Is your website AI slop? How to tell, and how to fix it

Lauri Lännenmäki — Tue, 13 Oct 2026 18:57:55 +0000

Originally published on no-code.supply.

TL;DR

"AI slop" is what people call content that's cheap, generic and made in bulk. Websites get the label too, and people spot it in seconds.
Slop isn't about AI. It's about nobody making the decisions. Themes and templates made sites look the same long before AI did. AI just made it free and instant.
The tells fall into four groups: how it looks, what it says, what it claims and what nobody checked.
Dodging a list doesn't work either. Ban Inter and purple, and you get Instrument Serif and mono captions instead. The list keeps growing.
The fix isn't avoiding AI. It's making the calls AI can't make for you: your words, your photos, one thing that's only yours, and a check before you ship.
A template is where your site starts. Ship it as it came and it'll look like everyone else's. That includes mine.

👉 Browse the templates

Yes, I build templates with AI

I'm Lauri Lännenmäki, a design engineer. I've spent fifteen years designing and building for the web, and these days I build my website templates with an AI agent. (Here's how that went.)

So yeah, I have a stake in this. You should know that before you read on.

But this isn't a post about defending my templates. It's about how to spot slop when you see it, and how to make sure your own site isn't slop. Doesn't matter if you start from my template, someone else's, or a blank prompt.

Let's dig in!

What people mean by "AI slop"

Merriam-Webster made "slop" its word of the year for 2025: low-quality digital content, usually made in bulk with AI.

For websites, you know the one. You've seen it a thousand times. You can't tell who made it, or what they sell, until the third scroll. And by then you're not sure you believe a word of it.

But notice what people aren't complaining about. Nobody minds that AI was used. They mind that it shows.

The tells

Any one of these on its own is fine. It's when the whole page is made of them, and nobody chose any of them, that people notice. Pretty much instantly.

How it looks

A purple-to-blue gradient, with a glowing blob behind the headline.
A centred hero with a little pill badge above it: "✨ Now with AI".
Gradient text on the one word that matters.
One default sans-serif for everything, in one weight. The font isn't the problem. Nobody choosing it is.
A small uppercase caption above every single heading, usually in a mono font.
Three feature cards with an outline icon each. Then a bento grid. Then three more cards.
The same rounded corners and the same soft shadow on every box.

What it says

Headlines that could sell anything: "Elevate your workflow", "Unlock your potential", "Built for the future of work".
Adjectives instead of facts: seamless, powerful, stunning, next-level.
Every other sentence built the same way: "It's not just a tool. It's a movement."
Everything in threes. Fast. Simple. Powerful.
Emoji as bullet points.

What it claims

A wall of logos from companies that have never heard of you.
Testimonials from people who don't exist, with AI headshots.
A row of big round numbers: 10x faster, 99.9% uptime, 500+ integrations.
"Trusted by 10,000+ teams" on a site that launched last Tuesday.

What nobody checked

Light grey text on white that you have to squint at.
A layout that breaks on a phone, or scrolls sideways.
No visible focus when you press Tab, and menus you can't open with a keyboard.
Links that go to #, the template's name still in the footer, "Lorem ipsum" in the share preview.
A white screen for five seconds while 4 MB of animation loads.

The first three groups are about sameness. The last one is about care. Most slop has both.

Here's the whole set on one page. Sarah J., CEO at Company, sends her regards.

Slop bingo: one made-up page, all fourteen tells.

Slop is older than AI

I've seen hundreds, maybe thousands, of templates in my day. Before this shop, I made Framer templates by hand. And sameness was always there.

There was the era when every agency site opened with the same full-screen image slider. Then every startup drew its people in the same flat illustration style, the one with tiny heads and long, bendy arms. Then every SaaS page got the same dark hero with a glowing gradient in it.

None of that was AI. It was defaults: a popular theme, a UI kit, a template, shipped as it came.

Even the purple is a default. Back in 2020, Tailwind UI shipped its example buttons in indigo. That indigo got copied into a mountain of code, and the models learned from that code. In 2025, Tailwind's creator Adam Wathan apologised for it on X.

AI didn't invent sameness. It just made it free and instant.

A model that learned from millions of websites gives you something close to the average website, unless somebody tells it otherwise. And the average website is exactly what people have learned to scroll past.

The list keeps growing

Dan (@pizzaboy) recently posted a list of things AI has ruined for designers. Instrument Serif. Em dashes. Gradient text. Eyebrow captions and mono captions. Two-column heroes. Purple, twice. And numbers. Just... numbers.

(There isn't a single em dash in this post, by the way. Make of that what you will.)

It's a joke, but it's also kind of true. And look at that list again: most of it is good stuff. Instrument Serif is a lovely free typeface. Mono captions, two-column heroes and numbers are just normal design. Designers picked them because they worked. Then they got popular, then they ended up in the training data, and now they're what AI reaches for when it wants to look tasteful.

Anthropic, the company behind Claude, has a name for this: distributional convergence. Ask a model for a landing page with no guidance and it lands on the safe middle: Inter, purple gradients on white, barely any animation. Tell it to avoid those, and it drifts to the next popular thing instead. Their own example is Space Grotesk.

So here's the thing: you can't avoid your way out of slop. Ban Inter and purple, and you get Instrument Serif and mono captions. If you design by dodging a list, the list is still making the decisions.

And I'll be honest: by Dan's list, I'm guilty too. Nocturne, my template for an AI sleep coach of all things, is deep blue-black with indigo and violet, and every heading and number is set in Instrument Serif. My site, no-code.supply, uses small mono caps for its eyebrows and labels. Eight of my nineteen templates use a mono typeface somewhere.

I'm keeping all of it. Nocturne is a night sky: a moon, a starfield, and a breathing timer you press and hold. Deep blue and a quiet serif are what that feels like. That's a decision. Picking the same things because they're what "tasteful" looks like this year isn't.

Slop is what you get when nobody made the decisions

Every website is a long list of decisions. What to say first. What to leave out. Which typeface, which colour, which one thing people will remember.

A slop site is one where every one of those was left at the default. And it doesn't matter if the default came from a model, a theme or a UI kit.

Here's what making those decisions looks like in practice, from my own templates. The agent wrote the code. These calls were mine.

Ashlar is a real-estate template. Before it was built, I checked five other real-estate templates and listed what they all do: stat counters, testimonials, an FAQ, a grid of listing cards. Ashlar has none of them. I even dropped a good idea, a hero framed through a doorway, because one of the five already did it. The copy has rules too: never "luxury", "dream", "stunning" or "exclusive". In its own words, "Larch, unfinished" beats "stunning timber".
Cistern is a site for a home battery. One version was built around a water tank. It worked. It also looked childish, so out it went, and I started over: near-black, one champagne accent, and a lit graphite slab instead of a water tank.
Purple Sector is a web-performance studio dressed as a 1990s TV timing screen. It borrows the look of motorsport graphics and nothing else: no cars, no helmets, no real teams or drivers. Same rule as every template I've made: don't copy anything. Ever. The references set the mood. Everything on the page is made from scratch.

None of that is the agent's job. It'll happily build the water tank, the stat counters and the doorway. Saying no is the part only you can do.

A template is where your site starts

Now the uncomfortable part, for someone who sells templates.

Even when a template is full of good decisions, they're my decisions, made for a business that doesn't exist. Ship it as it came and you have someone else's site with your logo on it.

That's slop too. Not because AI built it, but because nobody made it yours.

So let's be clear about what a template is for.

What a template should handle for you: the structure, a layout that works on every screen, readable contrast, keyboard access, reduced motion, fast pages, clean code. The boring, correct stuff you shouldn't have to solve again.

What it can't handle for you: what you actually do, how you talk about it, your real photos, your real proof, and the one thing people will remember you by.

Ashlar is a good example. Its 21 house photos were generated with AI. The houses don't exist. They're in the demo so it looks finished, and the README says to replace them before launch and never to present them as real properties. A real-estate site with made-up houses on it isn't just slop. It's lying.

Five changes that make a template yours

1. Rewrite every word

Not tweak. Rewrite. The demo copy was written for a made-up business, and it reads like it.

Swap adjectives for facts. If a headline would work just as well on your competitor's site, it isn't done.

Before: "Elevate your brand with stunning, modern design."
After: "We build websites for physiotherapy clinics. Most go live in three weeks."

The second one isn't clever. It's just true and specific. That's what makes it yours.

2. Use real photos

Your team, your work, your place. A decent phone photo of something real beats a polished stock photo (or an AI image) of nothing. Every time.

Don't have them yet? Take them before you launch, not after.

3. Change one thing in the brand, properly

You don't need a full redesign. One colour or one typeface is enough to move it away from the demo. Change it where the template keeps its design tokens, so it follows everywhere, then check the contrast again.

4. Cut what you don't need

A template shows everything it can do. You don't need all of it.

No testimonials yet? Delete the section. Don't fake it. Three services, not six. A shorter site is easier to make yours.

5. Keep one thing that's only yours

One detail people remember: a photo, a line, a tool, a number that's true.

Every template I sell has a signature effect. Keep it, retune it (speed, colours, on or off), or swap it for something of your own. Just make sure there's something on the page nobody else has.

Check it before you ship

Slop is also what nobody checked. And honestly, checking is the easy part.

This isn't theory. The first build of Ashlar had more than 60 contrast failures. Sixty. Grey text a shade too light, on a page that looked great. Nobody catches all of those by eye. A checker finds every one in seconds.

Ten minutes before you launch:

Read every headline out loud. Could a competitor use it unchanged? Rewrite it.
Search for leftovers: the template's name, "lorem", "example.com" and links to #.
Make every claim true. Numbers, logos, quotes. If you can't back it up, it goes.
Open it on your phone and scroll the whole page. Nothing should move sideways.
Press Tab through the page. You should always see where you are.
Run Lighthouse in Chrome DevTools, and an accessibility checker like axe DevTools (a free browser extension). Fix contrast first.
Turn on "reduce motion" in your system settings and reload. The page should still look finished.
Send the link to a friend and ask what you do. If they can't say it in one sentence, the copy isn't done.
Run the reverse squint test. Paste a screenshot into a fresh AI chat and ask which AI app builder made it. If it can guess, so can your visitors. (A tip from the Robots on Payroll newsletter.)

Basic stuff, but someone has to do it.

Every template I sell goes through the same kind of list before it ships: no serious accessibility issues, readable contrast, works with a keyboard, respects reduced motion, no requests to third-party servers, no sideways scrolling from 360 to 1920 pixels wide. That covers the boring, correct part. The words, the claims and the leftovers are on you.

If you work with an AI agent, let it do the first pass. It doesn't get bored:

Review this site like a picky first-time visitor. List every headline
that could belong to any company, every claim I can't back up (numbers,
logos, quotes), every leftover placeholder (the template's name, lorem
ipsum, example.com, links to #), and every place where text contrast is
below WCAG AA. Don't fix anything yet. Give me the list, grouped.

Then you decide what to change. That last step is the whole point.

FAQ

Is everything made with AI slop?

No. Slop is generic, unchecked and made without care. Something can be built with AI and be none of those things. Something can be made by hand and be all of them.

Does Google penalise websites built with AI?

Not for being built with AI. Google's guidance is about whether content is useful to people. Using AI to churn out lots of pages without adding value can fall under its spam policy on scaled content abuse. A real business site with real content about what you do isn't that.

Can people tell a site was made with AI?

They can tell when it's generic. When it isn't, there's not much to tell.

I've seen this with my own templates. Nobody called them AI slop until I said they were built with AI. Before that, they were just templates.

Do I have to rewrite everything if I start from a template?

The words and the photos, yes. The structure, the code and the checks, no. That's the part you're paying for.

Are your templates AI slop?

Short answer: no. Long answer: this whole post. But you're the judge: every template has a live demo you can click through. Ship one without changing it, though, and yeah, your site will be.

Wrap-up

AI made the average website free. The way out is the same as it's always been: make the decisions, use real things, and check your work before you ship.

A good template, mine included, gets you through the boring, correct part fast. So you have time for the part only you can do.

If you want a starting point where that part is already done, the templates are here. Just don't ship them as they came.

If you read this far, thank you! 🙏

How to self-host Google Fonts (and why your site should)

Lauri Lännenmäki — Fri, 09 Oct 2026 10:40:42 +0000

Originally published on no-code.supply.

TL;DR

Google Fonts is free, but the usual way of using it makes every visitor's browser contact Google before your page can look right. You can skip that by hosting the font files yourself.
It takes four steps: download the woff2 files, write an @font-face rule for each, preload the one or two files your page needs first, and check that DevTools shows zero requests to Google.
The result: fewer connections, one less privacy question, and a site that doesn't break when someone else's server has a bad day.
It's the same on every project I build, and this site does exactly this.

Here's the whole thing in one block. The rest of the post explains each line.

@font-face {
  font-family: "Geist";
  font-style: normal;
  font-weight: 100 900;
  font-display: swap;
  src: url("/fonts/geist-normal-400-latin.woff2") format("woff2");
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6,
    U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

<link
  rel="preload"
  href="/fonts/geist-normal-400-latin.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>

👉 Skip to the step-by-step

Why bother

The normal Google Fonts setup is one line of HTML. You paste a <link> tag, and the font works. It's popular because it's so easy.

What that line does behind the scenes: your visitor's browser asks fonts.googleapis.com for a stylesheet, reads it, then asks fonts.gstatic.com for the actual font files. Two extra servers, both owned by someone else. Here's why I stopped doing that.

Privacy

Every request to Google's servers tells Google that this visitor, with this IP address, just opened your page. You didn't ask for that, and your visitor didn't agree to it.

In Europe this has already been a legal question. On 20 January 2022 a Munich court (LG München I) decided that a website owner who loaded Google Fonts from Google's servers had passed a visitor's IP address to Google without permission, and ordered a €100 payment. It was one ruling in one country, and I'm not a lawyer, so don't take this as legal advice. But the fix is so cheap that I'd rather not find out how the next case goes.

If you host the fonts yourself, there's nothing to ask about. The font comes from your own domain, like the rest of your page.

Speed

Loading from Google means your browser has to open new connections: look up the address of another server, set up a secure connection to it, and only then start the download. That's work your own server has already done by the time the page arrives.

There was an old argument for the shared setup: if every site uses Google's copy of Roboto, a visitor probably has it cached from another site already. That stopped being true. Modern browsers keep a separate cache for each website, so a font cached while visiting site A isn't reused on site B. Chrome, Firefox and Safari all do this now (Chrome since 2020). So the shared cache saves you nothing, and you still pay for the extra connection.

Self-hosting also lets you decide which files load first. More on that in a moment, because it's the part that made the biggest difference for me.

Reliability

If Google's servers are slow or blocked on someone's network, your text sits waiting, or falls back to a font you didn't pick.

Files on your own domain share your site's fate. If the page loads, the font loads.

Control

The font files stay the same until you change them. You pick the weights, the languages and the format. Nobody can change the stylesheet under you.

On this site it's also a written rule. The project's AGENTS.md says there are no third-party requests: no Google Fonts, no outside analytics, no embeds loaded on page view. (I wrote about those files in How to write an AGENTS.md your AI agent actually follows.) Fonts are the easiest of those to get right, so they were the first thing I fixed.

How to do it by hand

There are four steps. You can do it with no tools beyond a browser and a text editor.

1. Find out which files Google serves

Open the Google Fonts page for your family and copy the embed URL. For Geist it looks like this:

https://fonts.googleapis.com/css2?family=Geist:wght@400;500;600;700;800&display=swap

Open that URL directly in a browser tab. You'll see plain CSS: a list of @font-face rules, each with a src: url(https://fonts.gstatic.com/…woff2) line.

Two things to notice:

The files are woff2. That's the compressed font format every current browser supports. It's the only one you need. (Older formats like ttf or woff are for browsers from a decade ago.)
There are several rules per weight, each with a comment like /* latin */ or /* latin-ext */ and a unicode-range line. That's the subsetting I'll come back to.

Heads up: Google looks at who's asking and sends different CSS to different browsers. An old or unknown browser gets ttf files and no subsets. If you fetch the URL from a script, send a modern browser's User-Agent header, or you'll get the wrong thing.

2. Download the files

Save each woff2 file into your project, for example public/fonts/ in a Next.js project, or /fonts/ in a plain site. Give them names you can read, like geist-normal-400-latin.woff2.

Or use a tool. google-webfonts-helper lets you pick a family, weights and subsets and gives you the files plus the CSS. Fontsource packages the same fonts as npm packages, if you'd rather have them in node_modules:

npm install @fontsource-variable/geist

import "@fontsource-variable/geist";

The font's name in your CSS is then "Geist Variable", not "Geist".

3. Write the @font-face rules

Here's one rule, with what each line does:

@font-face {
  font-family: "Geist";
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url("/fonts/geist-normal-400-latin.woff2") format("woff2");
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6,
    U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

font-family: the name you'll use in the rest of your CSS (font-family: "Geist", sans-serif).
font-weight: which weight this file is for.
font-display: swap: show the text right away in a fallback font, then swap to the real one when it arrives. The other option is a blank space until the font loads, which is worse.
src: where the file is. It now points to your own domain, which is the whole point.
unicode-range: which characters this file covers. The browser only downloads the file if the page uses at least one of those characters.

That last one is the clever part of what Google does. The latin file covers English and most of Western Europe, including Finnish ä and ö (they sit at U+00C4/U+00E4 and U+00D6/U+00F6, inside the latin range). The latin-ext file covers things like Polish, Czech and Turkish letters. You write one rule for each, and a page in English only ever downloads the first.

Keep every subset you actually need. I keep latin and latin-ext and drop the rest (Cyrillic, for one) because this site doesn't use them.

4. Preload the files the page needs first

Here's the catch. A browser finds a font file only after it has downloaded your CSS and worked out which rules apply. By then it has already drawn the page in the fallback font. When the real font arrives, the text changes size slightly and everything below it jumps. That jump is what Google's tools call layout shift (CLS).

A preload link fixes it: it tells the browser about the file in the HTML, so the download starts right away, in parallel with the CSS.

<link
  rel="preload"
  href="/fonts/geist-normal-400-latin.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>

Two details that trip people up:

crossorigin is required, even for files on your own domain. Fonts are always fetched in a mode that needs it. Without the attribute the browser downloads the file twice, once for the preload and once for the real use, and the preload is wasted.
Only preload what's above the fold. Every preloaded file competes with your other resources. I preload two files and nothing else.

Here's the real example from this site. The homepage uses Geist for text and Geist Mono for small labels, so app/layout.tsx preloads the Latin file of each. The calls sit at the top of the root layout component, before it returns the page:

import { preload } from "react-dom";

export default function RootLayout({ children }: { children: ReactNode }) {
  preload("/fonts/geist-normal-400-latin.woff2", { as: "font", type: "font/woff2", crossOrigin: "anonymous" });
  preload("/fonts/geist-mono-normal-400-latin.woff2", { as: "font", type: "font/woff2", crossOrigin: "anonymous" });

  return (
    // <html>, <body> and the rest of the layout
  );
}

preload from react-dom is how a React 19 app adds a <link rel="preload"> to the page's head, and it works in a server component like this layout. The two files are the Latin ones from app/fonts.css. crossOrigin: "anonymous" is the same thing as the crossorigin attribute above.

Before I added these two lines, Lighthouse measured a layout shift of 0.104 on the homepage, caused by the font swap. After: 0.

The variable font shortcut

Geist is a variable font. One file holds every weight from thin to black, instead of one file per weight.

You can see it in my files. public/fonts/ has just four woff2 files in total: Geist and Geist Mono, each in latin and latin-ext. Together they're about 84 KB (29.3 and 16.5 KB for Geist, 23.1 and 14.7 KB for Geist Mono). The stylesheet still has a rule per weight (400, 500, 600, 700, 800 for Geist), but every rule points to the same file. The 400 in the file names is a leftover from how my script named them; each file holds the whole weight range.

If your font is variable, you can write one rule with a weight range instead. Google serves Geist with a range of 100 to 900:

@font-face {
  font-family: "Geist";
  font-weight: 100 900;
  src: url("/fonts/geist-normal-400-latin.woff2") format("woff2");
}

The saving is real when you use several weights. Five static weights are five downloads. One variable file is one. Check the Google Fonts page for your family: if it shows a weight slider, it's variable.

The fast way: a script

The first time I did this by hand it was slow and fiddly. After that I wrote a script, and you can have it: fetch-google-fonts.mjs. It needs Node 18 or newer. You give it the Google Fonts URL and an output folder:

node fetch-google-fonts.mjs \
  "https://fonts.googleapis.com/css2?family=Geist:wght@400;500;600;700;800&display=swap" \
  public/fonts --url-prefix=/fonts/ --css=app/fonts.css

Swap in the URL for your own family. --url-prefix is the path the browser will use for the files, and --css is where the stylesheet goes.

It does what the four steps above do:

Fetches the CSS URL, pretending to be a current Chrome so Google answers with woff2 and the subsets.
Reads each @font-face block and keeps the subsets I ask for (latin and latin-ext by default).
Downloads each font file once, even when several weights share it, and writes it into the output folder.
Writes a new stylesheet with the URLs pointing at my own folder instead of Google's. Weights that share one file are merged into a single rule with a range.
Fetches each family's licence text and saves it in public/fonts/licenses/.
Writes a fonts.json that lists each family, its files and its licence.

It's 99 lines of Node with no dependencies, so read it before you run it. If you'd rather not run anything, the manual steps above give the same result.

In Next.js: next/font/google

If you use Next.js there's a built-in route that does most of this for you: next/font/google.

import { Geist } from "next/font/google";

const geist = Geist({ subsets: ["latin"] });

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en" className={geist.className}>
      <body>{children}</body>
    </html>
  );
}

At build time Next.js downloads the font from Google and serves it from your own domain with the rest of your static assets, so your visitors' browsers never contact Google. It also preloads the subsets you list and adds a size-adjusted fallback font to reduce layout shift, both on by default. For a variable font like Geist you don't need to set a weight; for a static one you do.

It's a good choice, and if your site is Next.js and nothing else, use it. I still did my own for this site, for one reason: the templates come in plain HTML editions with no build step, so I wanted one method that works the same in every edition. Doing it by hand also keeps the files and the licence text visible in the repository, and gives me full control over what gets preloaded.

Don't forget the licence

Most Google Fonts use the SIL Open Font License (OFL). Geist does. Some use the Apache 2.0 licence instead, and a few (the Ubuntu fonts) use the Ubuntu Font Licence. Each family's folder in the google/fonts repository has its own licence file, which is the one to trust.

In plain words, the OFL lets you use, copy, embed and ship the font for free, including in commercial projects and bundled with your own software, and that covers self-hosting. What it asks in return:

You can't sell the font files by themselves.
Keep the copyright notice and the licence text with the font.
If you modify the font, the modified version stays under the OFL, and it can't use the font's Reserved Font Name if the licence names one.

So put the licence file next to the fonts. My public/fonts/licenses/ folder has geist-OFL.txt and geist-mono-OFL.txt, and a small fonts.json lists each family, its files and its licence. It takes almost no effort, and it saves a bad afternoon if someone ever asks.

How to check it worked

Don't trust that it worked. Look.

Open your site in Chrome and open DevTools (right-click, Inspect).
Go to the Network tab and tick Disable cache.
Type fonts in the filter box, or click the Font filter, and reload.
You should see only requests to your own domain, ending in .woff2.
Now filter for googleapis and then gstatic. Both should show zero requests.

Some things to check at the same time:

[ ] No request goes to fonts.googleapis.com or fonts.gstatic.com.
[ ] Each font file loads once. Twice means a missing crossorigin on the preload.
[ ] The preloaded files are the first font requests in the list.
[ ] Run Lighthouse and look at the layout shift number. It should be 0 or very close.
[ ] Search your code for fonts.googleapis.com. Old <link> tags and @import lines in CSS files hide in surprising places, and one forgotten line keeps the whole thing going.

FAQ

Is self-hosting Google Fonts allowed?

Yes. The fonts are open source, and the licences allow you to download them and serve them yourself. Google even offers a download button on every family's page. Keep the licence file with the fonts.

Is it faster?

Usually, yes, because there are no extra connections to set up, and you can preload the files you care about. Measure it on your own site: how much faster depends on where your server is and what else your page loads. I measured layout shift going from 0.104 to 0 here, but that came from the preload, not from self-hosting alone.

Do I need to update the files when Google updates a font?

No, nothing updates by itself. Your own copy stays exactly as you downloaded it. So ask yourself how often you really need a font updated, and whether you want it to change under a live design without you deciding. If you do want a new version, run the download again.

Should I use woff2 only?

Yes. Every current browser supports it, and it's the smallest format. You only need ttf or woff if you have to support very old browsers, which most sites don't.

Wrap-up

Self-hosting Google Fonts is a small job. You get a page that asks no one else for permission, loads in fewer steps, and has a font that stays put.

If you read this far, thank you. 🙏

Every no-code.supply template ships with its fonts self-hosted, files and licences included, so a template works the same with or without a connection to anyone else's server.

I used to be a Figma expert. Here's how I design now.

Lauri Lännenmäki — Tue, 06 Oct 2026 08:17:49 +0000

Originally published on no-code.supply.

TL;DR

I used to call myself a Figma expert. I still use it at my day job, but I don't design every state and every variant there anymore.
Figma has its own AI now. It works, but it feels slow and much weaker than Claude working in Figma through an MCP.
Figma was never the source of truth. Code is. Variants are simpler in code than in a design tool, where one button can grow to 1,100 variants.
I learned CSS properly so I could build anything I designed. It was all boxes anyway. Now the web expects shaders and three.js, and I don't want to learn all that.
And I don't have to. I'm no longer limited by my own abilities. Websites, apps, games, video ads: I describe it, an agent builds it.
My path there: ChatGPT and copy-paste, then Cursor, then Claude Code in the terminal, then MCPs for everything. Today the agent is Claude Opus 5.5.
Knowing how to code made the switch quicker for me. But if you've never coded, go straight to the agent and start building.

A bit of background

I'm Lauri Lännenmäki, a design engineer. I've spent fifteen years designing and building for the web, most of it somewhere between Figma, Framer and code.

I started using Figma when it came out. I had my own business back then, so nothing was stopping me from jumping over from Sketch. Over time I fell in love with it, mostly because of what it let me do: build design systems that developers actually implemented.

I knew the shortcuts, I built the component libraries, I set up the variables, the properties and the variants. If you'd asked me back then, I'd have said I was a Figma expert, and I'd have meant it.

This post is about why that changed. It's an opinion, not a review. Let's dig in!

I still use Figma, just differently

Let me be fair first. I still work in Figma. At my 9–5, if a client has design files somewhere, they're in Figma.

I just use it differently now. I don't design every state and every variant in Figma anymore. If I have to, I start there, and then I move to code.

Figma has its own agent now too. It has fixed things and made changes to my components when I didn't have the time, on the kind of tasks I knew would annoy me. It works. But, I dunno. It feels slow, and it feels much weaker than Claude working in Figma through an MCP. (More on MCPs below.)

The careful way feels slow now

You can use Figma in a lot of ways. You can rapid-fire everything, or you can take your time: name every layer, and set up all the variables, properties and variants properly.

I'm the second kind. And today, that work feels slow and a bit stupid, because I know all of it has to be done again in code. In code, I can just prompt what I want, and the variables, properties and variants are simply there.

So it's not that Figma got worse. The way I work moved somewhere else.

Figma was never the source of truth

Here's something I've believed for a long time, even back when I lived in Figma: designs should really be built in code. That's where they end up anyway.

Figma is a hi-fi picture of what a product could be. It's not the source of truth. It never has been, and it never will be.

I learned that the hard way. Once I started building my design systems myself, I quickly noticed I was keeping Figma up to date with the code, not the other way around. The code was the real thing. The Figma file was the copy I had to keep in sync.

The button with 1,100 variants

Variants show this best. And the usual offender is the button.

Give a button icons, sizes, states, colours and shapes, and it quickly turns into a sea of variants. I've worked on one that has 1,100 variants in Figma. Try editing that, and your MacBook starts to sound like it's about to take off.

In code, the same button is a handful of props:

<Button size="lg" variant="ghost" shape="pill" icon={<Arrow />}>
  Read more
</Button>

You read it top to bottom and you know exactly what it does. In a design tool, you get booleans that hide a layer, text properties that swap a string, and nested instances with their own overrides. It works, but it never felt quite right to me. It's code dressed up as a canvas.

So the move to code didn't feel like a loss. It felt like dropping the translation layer.

It was all boxes. Was.

I'm not a designer who can't code. I know how to code to a certain degree, and I used to be really good at CSS. I learned it on purpose, because I wanted to be able to build anything I designed. No handing a file over and hoping it comes back looking right.

And for a long time that was enough, because the web was all boxes. Flexbox, grid, a few transitions, and you could build pretty much anything that came out of a design tool.

That's not what people expect from a landing page or a marketing site anymore. Now it's shaders, WebGL, three.js, things that bend and refract and react to the cursor.

I'd never be able to build a three.js site by hand. No way. I wouldn't even try, because I wouldn't want to ship anything shitty. It's a whole other craft, and I'd rather spend my time on the ideas.

And now I don't have to

This is the part that still feels a bit unreal.

I envision something, I put it in a prompt, and the agent makes it happen. Then I get to sit back and marvel at the outcome.

Many of my own templates have effects I don't know how to build. Aurel has a raymarched WebGL serum drop in its hero that bulges toward your cursor. Tidewater opens with WebGL caustics, like light on the sea floor. I didn't write those shaders. I asked for an effect, and the agent decided how to build it. I never had to say "use WebGL" or explain how a shader works. Usually all I need to do is ask.

And it's not just websites. Here's some of what I've made with AI:

the first version of my Framer plugin, with nothing but ChatGPT
two iOS apps (not published)
thegoatdebate.io
TikTok video ads
a 3D shooting game, and a 2D one

For most of my career, what I could make was capped by what I could build myself. That cap is gone, and I still find that super fascinating.

My job didn't disappear. It moved. I still decide what something should look like, how it should feel, and whether it's good enough. I just don't need to know how to write a fragment shader to get there.

How I got here

It didn't happen overnight. Looking back, every step felt like a big leap at the time.

1. Chatting with ChatGPT

In the beginning I just chatted with ChatGPT. Then I started coding with it. The workflow was copy and paste: describe the problem, copy the answer into my editor, run it, copy the error back, repeat. Clunky, but it worked. That's how the first version of my Framer plugin got built.

2. Cursor

Then I moved to Cursor, and that felt like a giant leap forward. The AI was inside the editor, it could see my files, and it could make the change itself. No more ferrying code between two windows.

3. Claude Code in the terminal

Then I moved to Claude Code, in the terminal. And pretty quickly it started to feel very cool to not look at the code at all. Sometimes I still do, but mostly I don't. I describe the outcome, the agent does the work, and I review what it made: the page, the behaviour, the result. Not the diff.

4. MCPs

Then came MCPs, and I was mind-blown all over again.

An MCP (Model Context Protocol) server connects the agent to another tool, so it can read from it and act in it directly. One of my first was Figma Console MCP. I used it to debug and map out a massive design system I help build for a Finnish company.

For example, I had the agent find every gap and padding that used a hardcoded value and switch it to a variable. Then the same for colours. Doing that by hand means clicking through hundreds of components one layer at a time. I probably saved hundreds of hours of manual, annoying work with that one MCP.

Which is a little ironic for a post about leaving Figma: some of the most useful Figma work I've done lately, I did without clicking around in it myself.

5. An MCP or API for everything

Now I have an MCP or an API for pretty much everything I use:

Jira and Linear for tickets
GitHub for code
Polar and Stripe for payments
Supabase for databases
Figma, Framer, Paper and MagicPath for design
Google Search Console for search

The agent doesn't just write code anymore. It works across the same tools I do.

Why Claude Opus 5.5

I like trying things out. Besides ChatGPT and Cursor, I've used tools like Higgsfield for images and video, and ElevenLabs for voice. But for building, my agent is Claude Opus 5.5, running in Claude Code.

Opus 5.5 is just a beast. It understands me.

I'm on a Max plan, and I've learned to make it last for both my 9–5 and my own projects on the side. And I'd pick Claude anyway, because to me Anthropic always feels one step ahead of everyone else.

It helped that I could already code

I'll be honest about one thing: I had a head start.

I knew how to code, and I already knew my way around Node, git and the terminal long before AI showed up. So when the tools moved from a chat window to an editor to the terminal, I didn't have to learn a whole new world at each step. I was already living in it.

For a designer who has never coded, the same transition probably takes longer and feels less natural. You're learning the agent and the environment it runs in at the same time.

But that's no reason to wait. My advice: go straight to the agent and just build things. When you feel like you're onto something and you want some version control, ask for help. Learn the basics of git, and ask the agent to teach you. You don't have to get fancy with it.

Everybody is a builder now

For most of my career, designers were limited by others. You designed something, and then you waited for a developer to build it, and hoped it came back looking right.

That's over. Designers are no longer limited by developers. Everybody is a builder now.

And "build" doesn't just mean websites anymore. If you can describe it, you can make it:

Websites, landing pages and marketing sites
Web apps, dashboards and internal tools
iOS and Android apps
Plugins for Framer and Figma, and browser extensions
Code components and whole design systems
3D scenes, shaders and generative art
Motion design, launch videos and video ads
Games, in 2D and 3D
Images, illustrations and brand assets
Music, sound effects and voice-overs
Physical products you design in 3D and send straight to a 3D printer
Automations and scripts for the boring parts of your job
Your own business: the shop, the checkout, the emails, the analytics

Ten years ago, each of those was its own career. Now it's a prompt away. You still need taste, and you still need to know what good looks like. But the skills that used to stand between an idea and the finished thing are no longer the bottleneck. Your ideas are.

Wrap-up

The distance between an idea and a working website just got very short, and for me that distance used to be most of the work. But I don't think design tools are dead.

For me, a design canvas is still the best place to see the big picture. Claude can make magnificent visual presentations of the bigger picture when I need one, but an endless canvas is useful as hell.

Same with the small stuff. Making a little tweak by hand in a canvas tool still beats trying to prompt my way to one exact detail. Although sending the agent a screenshot of the exact spot does the trick almost every time.

What I'm waiting for is the next step: just talking to my computer and seeing things happen in (almost) real time, pretty much like in the GPT-6 Astra launch video. That would be sick.

If you read this far, thank you! 🙏

And if you want to see what this way of working produces, the templates are here. Every one of them was built this way.

HTML vs React vs Framer: which website template edition should you buy?

Lauri Lännenmäki — Mon, 05 Oct 2026 10:14:55 +0000

Originally published on no-code.supply.

TL;DR

Every no-code.supply template comes as HTML and React. Three of them (Oda, Signal and Tender) also come as Framer.
HTML: plain files, no build step, goes on any host. The easiest edition to hand to an AI agent.
React: a Next.js project. Pick it if you'll keep building on the site, or you already live in React.
Framer: a remix link. Pick it if you or your client edit in Framer's visual editor, by hand or with Framer Agent. You get no source files.
Unsure? Get the Bundle (HTML + React) and decide later.

👉 Browse the templates

Why this post exists

I get the same question a lot: "Which edition should I buy?" The honest answer is that none of them is better. They're the same design, built for different ways of working.

So here's what's in each one, who it fits, and where it will annoy you. I make these templates, so I know the weak spots. Let's dig in!

The three editions at a glance

The design, the copy and the sections are the same in every edition. What changes is what you get to work with.

	HTML	React	Framer
What you download	A folder of static files	A Next.js project	A remix link
Build step	None	`npm install`, `npm run dev`	None, it's Framer
Where it runs	Any static host, or straight from disk	Vercel, Netlify or any static host	Framer hosting
You edit it in	Any code editor or AI agent	Any code editor or AI agent	Framer's visual editor, by hand or with Framer Agent
Source files	Yes	Yes	No, it stays a Framer project
Available for	Every template	Every template	Oda, Signal, Tender

HTML: just files

The HTML edition is plain HTML, CSS and JavaScript. Unzip it, double-click index.html, and the site opens. No accounts, no plugins, no framework.

In the zip: index.html, an assets folder with the CSS and JS, a 404.html, a privacy page and the usual extras (robots.txt, a web manifest). Plus a README.md, a DESIGN.md and an AGENTS.md.

It's for you if:

You want the least amount of moving parts. Edit a file, refresh the page.
You're putting it on a cheap or odd host: Netlify, Vercel, GitHub Pages, shared hosting, an S3 bucket.
You want your AI coding agent to do the editing. There's nothing to install and nothing to break, and the AGENTS.md tells it the rules.

The trade-offs:

No components or templating. If you add ten pages, you'll copy the header ten times.
No CMS. Content lives in the HTML.
Growing it into an app means switching to something else.

Every one of mine is built so it still works opened from disk, with no build step and no CDN. That's a rule, not an accident.

React: a project you can grow

The React edition is a Next.js 16 project with React 19, Tailwind 4 and Motion. It's set up as a static export. All the copy lives in one content file, so changing the words doesn't mean hunting through components.

You run npm install, then npm run dev, like any Next.js app. npm run check runs lint, typecheck and build in one go. It also ships with an AGENTS.md, a DESIGN.md and a README.md.

It's for you if:

You already work in React or Next.js and want to build on top of the design.
The site will grow: more pages, a CMS later, a form that talks to something, maybe an app section.
You want components, types and a linter catching mistakes.

The trade-offs:

You need Node and a terminal. That's a real hurdle if you've never used them.
A bit more to maintain: dependencies update, and sooner or later you'll run an upgrade.
For a five-section landing page that never changes, it's more machinery than you need. HTML does that job with less.

Framer: edit it visually, by hand or with Framer Agent

The Framer edition is the whole project, copied into your own Framer workspace through a remix link. That includes the pages, the CMS collections, the code components and the Framer Skills that teach Framer Agent how the site is built.

It's for you if:

You design in Framer and want to restyle things in the visual editor by hand, or ask Framer Agent to do it, not write code.
A client will edit the site themselves, and Framer's editor is what they know.
You want hosting, publishing and a CMS in one place.

The trade-offs:

No source files to hand to a code editor. The project stays inside Framer.
You depend on Framer's platform and its pricing for hosting.
Only three templates have one so far: Oda, Signal and Tender. You can buy it on its own, and it's also part of All-Access.

I come from Framer, so I'm fond of it. But "no code" has a flip side. If you want a developer to own the site, one of the code editions is a better start.

So which one?

Pick HTML if…

you want the simplest thing that works, anywhere
you'll edit it by hand or with an AI agent
the site is a landing page or a small brochure site

Pick React if…

you or your developer already use React
you expect the site to keep growing
you want components and a proper dev setup

Pick Framer if…

you or your client edit in Framer's visual editor, by hand or with Framer Agent
you want hosting and a CMS handled for you
you don't need the source files

A rough rule: HTML for the fewest surprises, React for the longest runway, Framer for the least code.

Bundle, bundle-all and All-Access

Bundle is HTML + React in one download. It makes sense when you're not sure yet. Prototype in HTML, move to React when the site outgrows it, or give a client the simple one and keep the other.
HTML + React + Framer is the same idea for the three templates that have all three. It's for studios and freelancers who deliver in different tools depending on the client.
All-Access is every template in every edition it comes in (HTML, React, and Framer where there is one), including the ones that arrive in later drops. It pays off if you'll use more than a couple of templates. It doesn't include Grit UI (the Framer UI kit) or the separately sold Framer code components.

If you only need one template for one site, one edition is plenty. Prices and what's included are on each template's page and on the All-Access page.

FAQ

Can I switch editions later?

Not by converting one into the other. They're separate builds of the same design. That's why the Bundle exists.

Is there any difference in design between editions?

No. The design, sections and copy are the same.

Do I need to know how to code?

Not for HTML, if you edit with an AI agent or just change text. React needs Node and a terminal. Framer needs neither.

Which edition is best with an AI coding agent?

HTML or React. Both ship with an AGENTS.md. HTML has nothing to install, so there's less that can go wrong. The Framer edition has its own Framer Skills for Framer's agent.

Do updates cost extra?

No. Updates to a template you own are free and show up in Polar's customer portal.

Wrap-up

If you're still stuck, start with HTML. It's the easiest to change your mind from, and you can always buy React later. The license and refunds pages spell out the details.

Thanks for reading! 🙏

Want to see the editions for yourself? Open any no-code.supply template and check what's included.

How to write an AGENTS.md your AI agent actually follows

Lauri Lännenmäki — Sun, 04 Oct 2026 19:26:16 +0000

Originally published on no-code.supply.

TL;DR

An AGENTS.md is a file that tells your AI coding agent how a project works and which rules it must not break.
Most of them get ignored because they're written like a wiki page. Write it like instructions for a new colleague on their first day.
What works: where things live, numbered rules with the reason next to them, one recipe for the most common task, and a checklist for when it's done.
What doesn't: vague advice ("write clean code"), things the agent can read from the code anyway, and docs nobody updates.
Every template I sell ships with one, and here's exactly how they're written.

👉 See the templates

Why I care about this file

I built 15 website templates with an AI coding agent, Claude Code, in about a week. (The whole story is here.) Two repositories, dozens of sessions, and the agent starting from zero every single time.

That's the thing people forget: your agent has no memory of yesterday. Every session, it opens the project like a new hire on day one. Whatever it knows about how your project works, it learns from what's written down. If nothing is written down, it guesses. And guessing is where the weird bugs come from.

Then there's the second reason. Every template I sell ships with an AGENTS.md, because most buyers won't edit a template by hand. They'll open it in Cursor or Claude Code and say "make the hero blue." That file is the difference between their assistant following the template's rules and their assistant quietly breaking them.

So I've written a lot of these by now. Let's dig in!

A quick caveat: this is how it works today

Everything in this post is how things work in October 2026. AI coding tools change every few months, and the rules have already changed more than once. A year ago, every tool wanted its own file. Now most of them read AGENTS.md, and even Claude Code reads it.

So take the file names and tool details with a pinch of salt. The thinking behind them should last longer: write down what the agent can't read from the code, and say why. That was good advice for onboarding human developers long before AI, and I don't see it going away.

What AGENTS.md is (and CLAUDE.md)

AGENTS.md is a plain markdown file in the root of a project. AI coding agents read it before they start working. It's an open convention, so one file works in most tools: Codex, Cursor, GitHub Copilot and others read it.

Claude Code has its own file, CLAUDE.md. You don't need two copies. My CLAUDE.md files have one line in them:

@AGENTS.md

That tells Claude Code to pull in AGENTS.md. One source of truth, every tool covered.

Note: Claude Code can now read AGENTS.md on its own, so a project with only an AGENTS.md works out of the box. But if there's also a CLAUDE.md in the project, Claude Code reads that one instead by default. So if you have both, keep the one-line import. (Claude Code docs)

You can also have more than one. My templates have an AGENTS.md per edition, one for the HTML version and one for the React version, because the rules are different. A plain HTML site that has to open from a double-clicked file has nothing in common with a Next.js build.

When there's more than one, the closest file wins. Agents read the AGENTS.md nearest to the file they're editing, so a subfolder's file can add to or override the root one. Put the rules that apply everywhere in the root file, and the rules for one part of the project next to that part. Claude Code works the same way with CLAUDE.md: a subfolder's file loads when Claude starts working in that folder.

What to put in it

Every AGENTS.md I write has the same five parts. Here they are, with real pieces from Oda, an architecture studio template.

1. What this is, in two sentences

Start with what the project is and the one constraint that shapes everything else.

## What this is
A static, dependency-free landing page for an architecture studio:
`index.html` + CSS + classic JS. There is no build step and there must
never be one. The page must keep working when `index.html` is opened
directly from disk.

That last sentence does a lot of work. Without it, the first thing a helpful agent does is add a bundler.

2. Where things live

A map. Not every file, just the ones the agent needs to find to do its job, and where a change should go.

## Where things live
- Copy and structure: `index.html`, one SECTION banner comment per
  section (Hero, Studio, Work, Process …).
- Design tokens: `assets/css/tokens.css`. Change values here, not in `main.css`.
- Shared helpers: `assets/js/kit.js` + `assets/css/kit.css` (vendored —
  don't edit; call `kit.*` helpers instead of re-implementing).

See the pattern? Each line says where something is and what to do with it. "Change values here, not there." "Don't edit, call these instead." That's the part that changes the agent's behaviour.

3. Rules that must not break

This is the heart of the file. Short, numbered, and each one with its reason.

## Rules that must not break
1. No external requests: no CDNs, Google Fonts, analytics or remote images.
2. Classic scripts with `defer` only. Never `type="module"` or `import`:
   they fail over `file://`.
3. Respect `prefers-reduced-motion`: new animations need a static
   equivalent.
6. Exactly one `<h1>`; keep headings ordered, landmarks, the skip link
   and `:focus-visible` styles.
8. Use existing tokens. If you need a new one, add it to `tokens.css`
   with a comment. Text in the accent colour uses `--timber-ink` (large)
   or `--timber-deep` (small), never `--timber`, which fails contrast.

Two things make these rules stick:

The reason. "Never type="module"" alone looks like a style preference, and an agent will happily trade a style preference for something it thinks is better. "They fail over file://" is a fact it can't argue with.
Numbers. A numbered list is easy to point at. "You broke rule 2" is a much shorter conversation than explaining it again.

Rule 8 is my favourite kind of rule. It's oddly specific, and that's the point. The accent colour looks great, but it fails contrast on small text. Nothing in the code tells you that. Without the rule, the next agent would happily use it for a caption.

4. A recipe for the most common task

Think about what people will ask for most. For a template, it's "add a section." So the file shows exactly how a section is built in this template, with a snippet to copy:

## Adding a section in the template's style
Copy the Materials or People section as a starting point:

- Header: the ruled `.sec-head` with `(NN) Name`, a subtitle and the
  next free sheet number.
- Layout: `.wrap` + the 12-column `.g12`; spacing comes from `.sec`.
- Headings: `.h2` with the last word in `<span class="dim">`.
- Reveals: `data-reveal="draft"` with `data-reveal-delay` in ms.

This is how a new section ends up looking like it belongs, instead of looking like the agent's idea of a section. Agents copy what they see. Give them the right thing to copy.

5. A checklist for "done"

End with what to check before calling the work finished.

## Before you finish
- [ ] No console errors. No horizontal scroll at 390px wide.
- [ ] The page still works opened from disk.
- [ ] Reduced motion shows a complete page.
- [ ] Keyboard: every control reachable, visible focus.

For a code project, the best version of this is one command. My React editions just say: run npm run check (lint, typecheck and build). If the agent can run it, it will, and it'll fix what fails before you ever see it.

What to leave out

Just as important. Everything in the file competes for the agent's attention, so every line has to earn its place.

Vague advice. "Write clean, maintainable code." "Follow best practices." The agent already thinks it does. These lines change nothing.
What the code already says. Don't list every component or explain what React is. The agent can read the code. Write down what it can't read: the intent, the constraints, the decisions.
History. "We used to use X, then switched to Y." Unless the old way is a trap it'll fall into, leave it out.
Secrets. No API keys, tokens or passwords. The file lives in the repo.
Long essays. If a section needs paragraphs of background, put it in its own doc (I use DESIGN.md for the design rationale) and link to it from AGENTS.md.

I don't have a line count I aim for. Mine ended up between 46 and 102 lines, depending on how much the template does. The test I use: if a part needs paragraphs of background, it belongs in another file.

Common mistakes

Describing instead of directing

Compare these two. Describing:

The project uses design tokens for colours and spacing.

Directing:

Use existing tokens. If you need a new one, add it to `tokens.css`
with a comment. Never hard-code hex values.

The first one is true. The second one is useful. Write in the imperative: use, keep, never, change it here.

Rules without a reason

An agent weighs your rule against everything else it knows. A rule with a reason wins that fight. A rule without one often doesn't, especially when the agent has a "better" idea.

Writing it once and never touching it again

A stale AGENTS.md is worse than none, because the agent trusts it. If a file moved or a command changed, the agent follows the old map and gets lost confidently.

My fix: every time the agent makes a mistake, I ask whether a line in AGENTS.md would have prevented it. If yes, it goes in. Most of my best rules came from bugs.

Here's a real one. Every template's docs explain how to move a section, like the hero, into another site. On 26 September I had the agent actually do it: follow the steps word for word and move each template's hero into a separate test site with its own clashing styles.

It broke in four templates. In some, the hero's entrance waited for a signal from the preloader or the nav. Move the hero without them, and the headline never appeared. In another, the hero's buttons needed a different section to exist.

The fixes took minutes. The more important part was the new rule that went into every template's AGENTS.md:

9. Every section must start on its own. An entrance that waits for a
   boot/intro signal must not rely on the preloader or the nav to
   send it: call the fallback from the section's own effect as well.

Now every agent that adds a section, mine or a buyer's, knows about it before it makes the mistake.

Writing it all yourself

You don't have to. Ask the agent to write the first version after it has worked on the project for a while: "Write an AGENTS.md for this project: where things live, rules that must not break, how to add a section, and a checklist for done." Then review it like any other part of the product. Cut the vague lines, add the reasons, fix what's wrong.

That's how all of mine were made. The agent that built the template also wrote down how it built it, and I edited it.

A template you can copy

Here's the skeleton I start from. Fill in the brackets, delete what doesn't apply.

# AGENTS.md — [Project name]

Instructions for AI coding assistants working on this project.
Read this before editing.

## What this is
[One or two sentences. What it is, and the one constraint that shapes
everything else.]

## Where things live
- [Thing]: `path/to/file`. [What to change here, or what not to touch.]
- [Thing]: `path/to/file`. [...]

## Rules that must not break
1. [Rule]: [why].
2. [Rule]: [why].
3. [Rule]: [why].

## [The most common task]
[Which file to copy, which patterns to reuse, where the copy goes.]

## Commands
- `[dev command]` — [what it does]
- `[check command]` — run before you finish.

## Before you finish
- [ ] [Check]
- [ ] [Check]

FAQ

What's the difference between AGENTS.md and CLAUDE.md?

They do the same job. AGENTS.md is the shared convention most AI coding tools read. CLAUDE.md is Claude Code's own file. Claude Code also reads AGENTS.md now, but only when there's no CLAUDE.md. Simplest setup: put everything in AGENTS.md, and if you need a CLAUDE.md too, make it a single line, @AGENTS.md.

Where does AGENTS.md go?

In the root of the project. You can add more in subfolders when a part of the project has its own rules, like my templates' HTML and React editions. The agent reads the one closest to the file it's editing, so the most specific rules win.

How long should an AGENTS.md be?

As short as it can be while still covering where things live, the rules, the most common task and the checklist. Mine are between 46 and 102 lines.

Does my AI agent actually follow it?

Much better than without one, and much better when the rules come with reasons. It's not a guarantee. That's why the file ends with a checklist and, when possible, a command that checks the work.

Should I write it myself or let the AI write it?

Both. Let the agent write the first draft from the project, then edit it yourself. You know the decisions and the reasons. It knows the files.

Wrap-up

An AGENTS.md is the cheapest quality tool you have. Ten minutes of writing saves you from explaining the same thing in every session, and it keeps your rules alive after you've forgotten why you made them.

If you read this far, thank you! 🙏

Want to see a real one in action? Every no-code.supply template ships with an AGENTS.md, a DESIGN.md and a README.md, so your own AI assistant can edit it the way it was built. 🔥

How I built 15 website templates with an AI coding agent in a week

Lauri Lännenmäki — Sat, 03 Oct 2026 11:18:26 +0000

Originally published on no-code.supply.

TL;DR

I built 15 website templates, each with its own brand, in about a week, with an AI coding agent (Claude Code) doing the typing.
The agent pretty much one-shotted the designs. My job moved from building to directing: the idea, the quality bar, and the final call.
Where AI really shines: speed, bug hunting, and packaging it all as a business.
Every template is AI-ready: it ships with docs your own AI assistant can read, so it edits the template the way it was built.
Yes, some people call it AI slop. They're templates. A template is where your site starts, not where it ends.

👉 Browse the templates

Why I did this

I'm Lauri Lännenmäki, a design engineer. I've spent fifteen years designing and building for the web, most of it somewhere between Figma, Framer and code. I'm a consultant in Finland, and I freelance on nights and weekends. Before this I made Grit UI and Fhibli UI for Framer, and a handful of Framer code components. I'm also a certified Framer Pro Expert.

I've wanted my own template shop for a long time. What stopped me was always the same thing: time. Before this I only made Framer templates, and a good one took me at least a month, on and off. Doing fifteen of them, each drawn from scratch and shipped in two code editions, was never going to happen on nights and weekends.

So I wanted to find out: can one designer build a real template business with an AI agent doing most of the typing?

Short answer: yes. Let's dig in!

The setup

Two repositories and one agent:

The templates repo: where every template is designed, built, reviewed and packaged. It also holds a small shared kit (the helpers every template reuses) and the tooling that checks and exports everything.
The storefront: no-code.supply, a static Next.js site that shows and sells the templates. Checkout runs on Polar.
The agent: Claude Code, on one of the higher-usage plans.

Every template ships in two editions:

HTML: plain HTML, CSS and JavaScript. It opens straight from the folder you download. No build step, no accounts, no framework to learn.
React: a Next.js + React + Tailwind project, with every word of copy in one file.

Some also get a Framer edition: Oda and Signal so far.

How one template gets made

Every template goes through the same phases. The agent does most of the work in each one. I decide when a phase is done.

1. The concept

This part is mine. Before any code exists, I decide what the template is: the industry, the brand, the mood, the type pairing, the palette and the one interaction people should remember.

Oda is an architecture studio designed as a drawing set: grid paper, hairline title blocks, sheet numbers, and line drawings that draw themselves as you scroll. Signal is a security SaaS. Meridian is travel. Each one gets its own identity, not a recolour of the last one.

For every concept I gave the agent 5–10 references: images and websites with the mood I was after, plus things I generally like myself. Alongside them I wrote down the typography (the type scale and its style), the spacing and the colour palette. And one rule above everything else: don't copy anything. Ever. The references set the mood: the feel, how dense the page is, how it moves. The layouts, copy, imagery and code are all made from scratch.

2. The first build

The agent builds the HTML edition from the concept. And this is the part that still surprises me: the first version is usually very close to done. I don't have a dramatic before/after to show you, because there isn't much of one. The first builds were just amazing. I had to change very little in any of the templates. Here and there I removed a section, but nothing much.

3. Review, docs and fixes

Close to done isn't done. This is where most of the time goes, and it's where the quality comes from.

Every template goes through the same definition of done before it ships:

Zero console errors or warnings.
No horizontal overflow at 360, 390, 768, 1024, 1440 and 1920 pixels wide.
0 serious or critical axe issues, a keyboard-only pass, and visible focus styles everywhere.
WCAG 2.2 AA contrast for text.
prefers-reduced-motion shows a complete, good-looking static page.
No third-party requests at all. Fonts are self-hosted. No CDNs, no analytics.
The HTML edition works from a double-clicked index.html, not just from a web server.

Lighthouse scores are a goal, not a rule. I aim for Accessibility ≥ 95, Best Practices ≥ 95 and SEO 100, but when a template's design calls for it, I'll accept a lower score.

That's a lot of checking. Luckily, checking is something the agent is very good at (more on that below).

4. The React edition

Same design, same copy, rebuilt as a Next.js project, then put through the same checklist.

5. Packaging

Zips, previews, a changelog, product copy, and the export to the storefront. More on this below too, because it turned out to be the most surprising part.

All in, it took about 3–6 hours to go from a design to a finished template in both editions.

AI-ready templates: what that actually means

This is the part I'm most proud of, and it's the reason I call these AI-ready templates.

Most people who buy a template in 2026 won't edit it by hand. They'll open it in Cursor, Claude Code or whatever assistant they use, and say "change the hero copy and make it blue." The problem: the assistant doesn't know how the template was built. So it guesses. It hard-codes a colour, breaks the mobile layout, or adds a dependency that breaks the no-build-step promise.

So every template ships with three files:

README.md: for you. How to install it, edit it, and move a section into another site.
DESIGN.md: the design rationale. Tokens, type scale, the ideas behind the layout.
AGENTS.md: for your AI assistant. Where things live, how the effects work, and the rules that must not break.

Here's a small piece of Oda's AGENTS.md:

## Rules that must not break
1. No external requests: no CDNs, Google Fonts, analytics or remote images.
3. Respect `prefers-reduced-motion`: new animations need a static equivalent.
6. Exactly one `<h1>`; keep headings ordered, landmarks, the skip link and `:focus-visible` styles.
8. Use existing tokens. If you need a new one, add it to `tokens.css` with a comment.

These files aren't an afterthought. The agent that built the template also wrote down how it built it, and I reviewed those docs like any other part of the product. So when your assistant opens the template, it follows the same rules the original was built with.

The Framer edition works the same way: it ships with Framer Skills that teach Framer's own agent how the site is built.

That's the idea behind AI-ready: the template is the starting point, and your AI assistant can take it the rest of the way without breaking it.

Where AI was great

Speed

The obvious one, but the numbers are still silly:

24 September: the templates repo starts.
26 September: the shop launches with the first six templates.
29 September: nine templates are out.
1 October: all 15 are done.

About a week. And not a full-time week, either: I did this around my consulting work, so the hours are hard to count.

Honestly, without AI I wouldn't have started this project at all. One template would have taken me months, let alone building an entire shop around them.

Bug hunting

This one surprised me. The agent spotted a lot of bugs by itself and fixed them without me telling it to. A few examples:

Tender's form error colours failed contrast. You only see an error message when a form fails, so it's easy to never check its colour.
Focus styles. Invisible with a mouse. You only notice them when you go through the page with a keyboard.
An HTML comment could swallow markup in the step that exports a template to the store. A section could quietly disappear from a demo, with no error anywhere.
Oda's reveal animations got clipped, cutting off the edges of elements as they animated in.

The list is much longer. Many times it corrected itself before I'd even noticed anything was wrong.

The quality checklist above is only realistic because of this. Checking six screen widths, two editions, reduced motion, keyboard navigation and contrast, on every template, after every change, is exactly the kind of boring, careful work people skip. The agent doesn't get bored.

Packaging it all as a business

This is the one I didn't see coming. Designing templates is maybe half of running a template shop. The other half is everything around them, and the agent built most of that too:

The storefront itself: a static Next.js site with product pages, pricing, an All-Access offer and the legal pages.
The export pipeline: one command takes a finished template and writes its product page data, previews and live demo into the store.
The Polar sync: a script that creates the products in Polar, uploads each edition's zip, and writes the checkout links back to the site. When I ship an update, it swaps the files so every past buyer gets the new version.
Share images: every product gets its own Open Graph image, generated at build time.
The launch video: a script that films the store and the demos frame by frame and renders them to MP4. No screen recording, no editing app.

Without AI, the cost of all this would have been enormous for me. It would have been a long year of sleepless nights.

What I still had to bring

The agent did the typing. It didn't decide what's good. A few things were still my job:

The concept. Every template starts with an idea only I can have: what it is, who it's for, what makes it memorable. And the rule that nothing gets copied.
The bar. The definition of done above came from me. The agent meets the bar you set. Set it low and it'll happily ship something mediocre.
The final call. I reviewed every template visually for bugs and checked that every interaction works. Basic stuff, but someone has to do it.

"Isn't this just AI slop?"

It's a fair question to ask. Anything built with AI right now gets called AI slop sooner or later, so I'd rather answer it up front.

Here's the thing: they look good, and they're templates.

A template isn't the final site. It's where the final site starts. Nobody ships a template untouched. You add your brand, your copy, your photos, your product, your decisions. The template's job is to get you to a good, working, accessible starting point fast, so you can spend your time on the parts only you can do.

And "AI-generated" isn't what makes something slop. Slop is what you get when nobody made the decisions. Default fonts, default layouts, nobody checking whether it works on a phone or with a keyboard. Every one of these templates has its own concept, its own type pairing and its own signature interaction, and every one goes through the same checklist before it ships.

The AI wrote a lot of the code. It didn't decide what good looks like. I've seen hundreds, maybe thousands, of templates in my day, and to me these are top-tier by any standard.

What I'd tell a designer starting today

Just try it. This is the biggest lesson. Get familiar with these tools. They're here to stay, and they can make your life a lot easier.
Start with the concept, not the prompt. The clearer your idea, the closer the first build gets.
Write your definition of done first. Think about the big picture you want to achieve. The agent will meet whatever bar you set.
Make the agent write the docs. They help you, your buyers, and the next agent that opens the project.
Hand it the tedious stuff. You don't have to do everything with AI. Give it the boring, careful work and keep the fun parts for yourself.
Let AI do the business parts too. Checkout, exports, share images, even the launch video. That's where one person gets a lot more leverage.
Experiment. Try things you wouldn't have had time for before.

FAQ

Can AI design a website on its own?

It can build a good one from a clear concept, and fast. The concept, the quality bar and the final call still come from a person. That's where the difference between a generic site and a good one comes from.

Are AI-built website templates any good?

They can be, if someone sets a real bar.

What is an AI-ready template?

A template that ships with docs your AI coding assistant can read: a README.md, a DESIGN.md and an AGENTS.md. The assistant then edits the template the way it was built, instead of guessing.

How long does it take to build a template with AI?

For me, about 3–6 hours from a design to a finished template, including both editions and the full quality checklist.

Do I need to know how to code to use these templates?

No. The HTML edition runs straight from the folder you download, with no build step, and the included docs let your AI assistant make changes for you.

Wrap-up

Building this shop with an AI agent changed what I think one designer can do. And I'm just getting started: more templates, and more posts like this one, are on the way.

If you read this far, thank you! 🙏

And if you'd rather skip all of this and start from something that has already been through the checklist, the templates are here. All-Access gets you every template, including every one I add later. 🔥

How to create Dark Mode using only CSS

Lauri Lännenmäki — Thu, 03 Mar 2022 22:32:55 +0000

Dark Mode and dark interfaces are not a new thing as they have been a trend for many years. When Apple released a dark mode option with the iOS 13 update back in 2019, the trend took off.

Using modern CSS, you can create dark mode with a few lines of code.

Let's dive in!

📚 Content

Dark mode is more than a trend
Dark mode is accessibility
How to set up dark mode with CSS
- Create CSS Custom Properties (variables)
- Create conditional styling
- Apply styles
Demo and final code

✨ Bonus Content

Color-scheme meta tag and CSS property
How to test your code
- Google Chrome Dev Tools
- Device OS Settings

TL;DR;

You can create dark mode using only CSS Custom Properties aka CSS variables and CSS media feature prefers-color-scheme:

/* 1. Create global variables for text and background color */
:root {
  --color-text: black;
  --color-background: white;
}

/* 2. Add conditional styling for dark mode preference */
@media (prefers-color-scheme: dark) {
  /* Re-assign previous variables */
  :root {
    --color-text: white; /* black => white */
    --color-background: black; /* white => black */
  }
}

/* 3. Assign variables to page color and background */
body {
  color: var(--color-text);
  background-color: var(--color-background);
}

That's it 🔥 View my CSS Only Dark Mode Codepen.

Dark mode is more than a trend

Dark mode is not a design trend. Dark interfaces can be easier on the eyes and reduce eye strain and fatigue. They can actually help reduce the sensation of discomfort felt when staring at websites with light backgrounds.

Dark mode also saves your device's battery life. It can reduce battery usage, especially on mobile devices.

Dark mode is accessibility

Dark mode is also an accessibility (a11y) feature. It's about respecting your users and their preferences so they can use your website the way they like.

Besides responsive media queries, modern CSS has many cool media features and prefers-color-scheme is one of them. Quote from MDN Web Docs 👇

The prefers-color-scheme CSS media feature is used to detect if the user has requested a light or dark color theme. The user might indicate this preference through an operating system setting (e.g. light or dark mode) or a user agent setting.

Users can choose if they prefer light or dark mode from their operating system settings.

(macOS)

(iOS)

With CSS, you can serve the user the theme they prefer. Media queries are used to conditionally apply styles. Media feature prefers-color-scheme is a Media Query, so you write it like you'd write your breakpoints:

/* Breakpoint */
@media (min-width: 800px) {
  /* Add conditional styles here */
}

/* Prefers Color Scheme */
/* Dark */
@media (prefers-color-scheme: dark) {
  /* Add conditional styles here */
}
/* Light */
@media (prefers-color-scheme: light) {
  /* Add conditional styles here */
}

How to set up dark mode with CSS

Create CSS Custom Properties (variables)

To setup color styles, I recommend using variables to keep your code DRY (don't repeat yourself). If you aren't familiar with CSS variables, you can read about them from MDN Web Docs.

For the sake of this tutorial we keep things simple and use black and white as our colors. And we only style our text color and background color.

/* 1. Create global variables for text and background color */
:root {
  --color-text: black;
  --color-background: white;
}

Create conditional styling

Next, let's apply conditional styling for users who prefer dark mode. By using a media query, we re-assign previous variables with new inverted values.

/* 2. Add conditional styling for dark mode preference */
@media (prefers-color-scheme: dark) {
  /* Re-assign previous variables */
  :root {
    --color-text: white; /* black => white */
    --color-background: black; /* white => black */
  }
}

Apply styles

And finally, we apply the variables to our design:

/* 3. Assign variables to page color and background */
body {
  color: var(--color-text);
  background-color: var(--color-background);
}

Demo and final code

See the final effect in action of user changing between light and dark mode in OS settings:

👇 The final code in full.

/* 1. Create global variables for text and background color */
:root {
  --color-text: black;
  --color-background: white;
}

/* 2. Add conditional styling for dark mode preference */
@media (prefers-color-scheme: dark) {
  /* Re-assign previous variables */
  :root {
    --color-text: white; /* black => white */
    --color-background: black; /* white => black */
  }
}

/* 3. Assign variables to page color and background */
body {
  color: var(--color-text);
  background-color: var(--color-background);
}

You can view the code and play with it in my Codepen.

✨ Bonus Content

Color-scheme meta tag and CSS property

The color-scheme meta tag and CSS property takes care of two important things for you. This next quote is from Google Developers web.dev and I've taken the liberty to highlight some parts of it 👇

They both make your life as a developer easier by allowing you to opt your page in to theme-specific defaults of the user agent stylesheet, such as, for example, form controls, scroll bars, as well as CSS system colors. At the same time, this feature prevents browsers from applying any transformations on their own.

By the order of values, you can determine the default appearance. Here's the syntax for both CSS and the corresponding HTML meta tag:

:root {
  color-scheme: dark light;
}

(In the CSS example, the page author prefers dark theme.)

<head>
  <meta name="color-scheme" content="light dark">
</head>

(In the HTML example, the page author prefers light theme.)

It is recommended to specify the color-scheme via the meta tag, so the browser can adopt to the preferred scheme faster.

How to test your code

Google Chrome Dev Tools

You can test your code with Google Chrome Dev Tools.

Open up your Dev Tools Inspection panel by pressing Command+Option+C (Mac) or Control+Shift+C (Windows, Linux, Chrome OS).
Click on the three dots in the upper right corner => select More tools => click Rendering.
From the Rendering tab you can find the emulation for prefers-colors-scheme.

See the screenshots below 👇

Device OS settings

As shown before, you can change the appearance from you device settings. Screenshots are from macOS and iOS. You can find the same settings from Android and Windows devices.

Resources and further reading

CSS Only Dark Mode Codepen by me
Color-scheme meta tag and CSS property at web.dev
CSS Media Feature prefers-color-scheme at MDN Web Docs
CSS Custom Properties aka CSS Variables at MDN Web Docs

Thank you 🙏

I hope you found this article helpful 🔥

You can follow me on Twitter for more CSS, Design System and Figma content 💪

Figma Plugin API: How to Load and Use Fonts

Lauri Lännenmäki — Sun, 06 Feb 2022 07:45:12 +0000

Working with Figma text through the Figma Plugin API is a lot trickier than you might think. All the text inside Figma files are nodes called TextNodes. Essentially, nodes are layers in Figma. With text nodes you have to think about mixed styles, missing fonts and loading fonts.

For now, we concentrate on loading fonts.

If you wish to change the content of a TextNode, you must load its font.

TL;DR

Here's one way of loading a font and manipulating text:

// Load font via async function
const myFontLoadingFunction = async () => {
  await figma.loadFontAsync({ family: "Work Sans", style: "Bold" })
}

// Another function where we use the loaded font
const myAnotherFunction = () => {
  // Create text layer
  const myTextLayer = figma.createText()
  // Set the font
  myTextLayer.fontName = { family: "Work Sans", style: "Bold" }
  // Set text to uppercase
  myTextLayer.textCase = "UPPER"
  // Set text content
  myTextLayer.characters = "This is my title"
  // Add text layer to current page in Figma
  figma.currentPage.appendChild(myTextLayer);
}

// Use font only after the Promise is resolved
myFontLoadingFunction().then(() => {
  myAnotherFunction()
})

That's basically it. If you want to know more about this subject, just keep on reading.

Glossary

About loading fonts
How to load fonts
What can you do with fonts and text

You can find the official Figma Plugin documentation page about TextNodes here but I believe the docs could be better and that's why I wrote this blog post.

About loading fonts

The docs tells us this important thing about text and fonts:

The important thing with text is that changing the content of a text node requires its font to be loaded and that fonts are not always available. If you attempt to change, say, fontName without first loading the font for that text node, the plugin will throw an exception.

I found out that the exception will look like this in your console.

So, basically every time you make changes to text content or its properties, you have to load its font. Only when you're changing properties like fill colour or stroke, you do not need to load the fonts.

How to load fonts

TextNodes have a property called fontName which is a javascript object that contains the font family and font style. The default font is { family: "Roboto", style: "Regular" }. In our example we want to use Work Sans, Bold.

(As a sidenote: You can load any font thats already accessible in the Figma editor. You cannot load fonts from the internet.)

The documentation says that "Loading a font is done via figma.loadFontAsync(fontname)" and maybe for someone that is enough but, as a designer, I was a bit confused when I tried it and it didn't work.

// Like in the docs => figma.loadFontAsync(fontname)
figma.loadFontAsync({ family: "Work Sans", style: "Bold" })

On it's own, this code isn't enough. This is when the error appears in the console. As we dive deeper into the docs we find this about the loadFontAsync property:

(loadFontAsync) Makes a font available in the plugin for use when creating and modifying text. Calling this function is necessary to modify any property of a text node that may cause the rendered text to change, including .characters, .fontSize, .fontName, etc.

And from it's signature (found in the docs) loadFontAsync(fontName: FontName): Promise<void> we can see that it returns a Promise. So, we must enchance our code by creating an "async/await" function:

const myFontLoadingFunction = async () => {
  await figma.loadFontAsync({ family: "Work Sans", style: "Bold" })
}

After the loadFontAsync Promise is resolved, we can use the then() method that returns a new Promise and when that is a success we can do what we initially wanted.

myFontLoadingFunction().then(() => {
  // Success!

  // Add your code here to do something with the loaded font!
})

You can read more about Promises and the then() from the MDN docs.

All the code once more:

// Load font via async function
const myFontLoadingFunction = async () => {
  await figma.loadFontAsync({ family: "Work Sans", style: "Bold" })
}

// Another function where we use the loaded font
const myAnotherFunction = () => {
  // Create text layer
  const myTextLayer = figma.createText()
  // Set the font
  myTextLayer.fontName = { family: "Work Sans", style: "Bold" }
  // Set text to uppercase
  myTextLayer.textCase = "UPPER"
  // Set text content
  myTextLayer.characters = "This is my title"
  // Add text layer to current page in Figma
  figma.currentPage.appendChild(myTextLayer);
}

// Use font only after the Promise is resolved
myFontLoadingFunction().then(() => {
  myAnotherFunction()
})

What can you do with fonts and text

After you have your fonts loaded you can use the following properties and functions of a TextNode:

characters = set/write your text content
fontSize = set font size
fontName = set font family and style/weight
textStyleId = set TextStyle using TextStyle id
textCase = set text casing to uppercase etc.
textDecoration = set decoration to underline/strikethrough
letterSpacing = set letter spacing in pixels or percents
lineHeight = set line height in pixels or percents
setRangeFontSize() = set font size to characters in range
setRangeFontName() = set font to characters in range
setRangeTextCase() = set text casing to characters in range
setRangeTextDecoration() = set text decoration to characters in range
setRangeLetterSpacing() = set letter spacing to characters in range
setRangeLineHeight() = set line height to characters in range
setRangeTextStyleId() = set TextStyle to characters in range

You can check out all the TextNode properties and functions here.

Have fun developing Figma plugins 🔥 I hope you found this article helpful!

Follow me on Twitter for more Figma, CSS and Design System content 💪

How to create responsive typography using CSS — Three different methods explained

Lauri Lännenmäki — Wed, 20 Jan 2021 20:52:14 +0000

Good typography is one of the key elements of a website. Let's take a look at three different methods on how to create responsive typography using CSS.

The three methods are:

Responsive typography using only media queries
Responsive typography using a CSS custom property as a multiplier
Responsive typography using the CSS clamp() function

TL;DR: Check out the final Codepen with all the methods. Resize the viewport to see the effect.

Why should you use responsive typography?

The web is used on various screen sizes. Your site has to work on mobile, tablet, laptop, desktop and basically everything in between so there's a lot to take into consideration.

All of the method examples below are simplified as they only cover three selectors and one breakpoint.

You can use this simple HTML to try out all the methods in this tutorial:

<h1>How to create responsive typography using CSS</h1>
<p>
  Vestibulum molestie sapien eget orci pellentesque, et aliquam lectus convallis. Phasellus neque velit, ultricies ut lacus at, finibus lobortis dui. Proin eget diam elit.
</p>
<h2>Three different methods explained</h2>
<p>
  Pellentesque sagittis nisl nec rhoncus porta. Quisque luctus turpis nec turpis consequat fermentum et vitae diam.
</p>

Let's dig in!

Method 1: Responsive typography using only media queries

This is the most basic method in our list.

Simply, declare your text styles and increase the font-size on bigger screens using a breakpoint:

/* Declare text styles */
h1 {
  font-size: 2em;
}
h2 {
  font-size: 1.5em;
}
p {
  font-size: 1em;
}

/* Increase font sizes by 1.5x on bigger screens */
@media (min-width: 48rem) {
  h1 {
    font-size: 3em;
  }
  h2 {
    font-size: 2.25em;
  }
  p {
    font-size: 1.5em;
  }
}

Check out the result from this Codepen. Resize the viewport to see the effect.

Using this method is totally fine and it does the job very well.

The downside is the large amount of code you have to write. The codebase gets larger with every new selector you need to add. You have to write the styles separately for every selector in each breakpoint.

In a real world you would probably have text selectors h1, h2, h3, h4, h5, h6, p and at least two breakpoints. At that point, this code is would've already gone from 20 lines to 67 lines. That's 3.35x increase in the amount of code.

The next method will show how to decrease the code amount and make it easier to maintain!

Method 2: Responsive typography using a CSS custom property as a multiplier

CSS custom properties (variables) are super powerful. In the previous method, we increased the font sizes manually one selector at a time. Now, we'll declare a multiplier variable for the font-sizes and only increase the value of the multiplier inside a breakpoint.

Let's look at the code example in full and then break it down:

/* Declare a font size multiplier variable */
:root {
  --text-multiplier: 1;
}

/* Increase the size of the multiplier on bigger screens */
@media (min-width: 48rem) {
  :root {
    --text-multiplier: 1.5;
  }
}

/* Declare text styles using calc() function and the multiplier */
h1 {
  font-size: calc(2em * var(--text-multiplier));
}
h2 {
  font-size: calc(1.5em * var(--text-multiplier));
}
p {
  font-size: calc(1em * var(--text-multiplier));
}

Check out the result from this Codepen. Resize the viewport to see the effect.

The first step is to declare a variable that we use to control our font size later on. We set the default value to 1.

:root {
  --text-multiplier: 1;
}

The second step is to increase the multiplier value inside a breakpoint. Unlike SASS variables, CSS custom properties can be used inside media queries.

@media (min-width: 48rem) {
  :root {
    --text-multiplier: 1.5;
  }
}

The last step is to declare our font-sizes but this time we use the calc() function so we can utilise our multiplier.

h1 {
  font-size: calc(2em * var(--text-multiplier));
}
h2 {
  font-size: calc(1.5em * var(--text-multiplier));
}
p {
  font-size: calc(1em * var(--text-multiplier));
}

As you can see, we only need to declare our font sizes once. This is a huge improvement compared to the first method.

Compared to the first method, we only have 17 lines of code compared to 20. If we would add four more selectors and one breakpoint, our code would only increase from 17 lines to 34. Remember that using the first method it would require 67 lines. Almost twice as much.

The decrease of code is due to our elegant way of using a CSS custom property as a multiplier. Adding another breakpoint takes only three lines of code because we don't have to modify our font sizes at all. The code is also a lot easier to maintain and modify.

Adding breakpoints is as simple as:

/* Add more breakpoints */
@media (min-width: 64rem) {
  --text-multiplier: 1.75;
}
@media (min-width: 80rem) {
  --text-multiplier: 2.0;
}

To the user, this methods looks exactly the same as the first but the code is much better.

Next up, we'll take a look at a new CSS clamp() function.

Method 3: Responsive typography using the CSS clamp() function

The clamp() function is pretty powerful! You can set a value using three parameters: a minimum value, a preferred value and a maximum value. Basically you'll have a 3-in-1 value!

Example declaration for responsive text using the clamp() function looks like this:

font-size: clamp(2rem, 5vw, 3rem);

This allows us to create responsive typography without any media queries. With only one line of code we set the minimum value (mobile), the maximum value (desktop) and the preferred value.

The font size will become fluid as it will always be the preferred value inside the min-max range. Very powerful!

To set the responsive typography for our demo, it is as simple as this:

/* Declare text styles */
h1, h2, p {
  /* Font minimum, preferred and maximum value */
  font-size: clamp(var(--min), var(--val), var(--max));
}

/* Font size variables */
h1 {
  --min: 2em; /* minimum value */
  --val: 5vw; /* preferred value = 5% viewport width */
  --max: 3em; /* maximum value */
}
h2 {
  --min: 1.5em;   /* minimum value */
  --val: 4vw;     /* preferred value = 4% viewport width */
  --max: 2.25em;  /* maximum value */
}
p {
  --min: 1em;   /* minimum value */
  --val: 2.5vw; /* preferred value = 2.5% viewport width */
  --max: 1.5em; /* maximum value */
}

Check out the result from this Codepen. Resize the viewport to see the effect.

If you look at the code, you'll see that by using CSS custom properties together with the clamp() function we are able to declare all the text styles at the same time with only on line of code.

After that, we just set the --min, --val and --max custom properties for each selector and we are done!

CSS custom properties can be scoped inside selectors so you can use the same custom properties with multiple selectors just like we have done here with our h1, h2 and p. These custom properties will not clash together even though they have the same name.

This method takes up 18 lines of code and with four more selectors and one breakpoint it would be 38 lines. So, it's slightly larger than on the second method but we get fluid typography in return.

Note: The clamp() function is pretty new, so you should check if it has the browser support you need from caniuse.com.

Wrap up

CSS is powerful!

In many cases, there's more than one way to achieve the desired result.

If you read this far, thank you! I hope you learned something new.

Here's the final Codepen with all the methods once more. Resize the viewport to see the effect.

Thank you 🙏

I hope you found this article helpful 🔥

You can follow me on Twitter for more CSS, Design System and Figma content 💪