DEV Community: Lauri Lännenmäki

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.

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 💪