I did not ask AI to make 200+ websites. That is what people assume when they hear about FreeStackTemplates.io. They picture somebody opening a chat window, typing "make me a SaaS landing page," and doing that two hundred more times. If you have ever tried that, you know what happens. The first site looks great. By the fifth, you are fighting inconsistent navigation, duplicate stock photos, dead links, and layouts that look like they were designed by a committee of competing chatbots. Every prompt is a blank slate. Every output is a gamble.
I needed a system.
So I built a pipeline where design decisions are structured data, prompts are generated from combinatorial inputs instead of written by hand, the AI builds under strict rules with explicit gates, scripts validate everything it produces, a visual review tool catches what scripts cannot, and a conversion layer turns each template into five frontend frameworks automatically.
That pipeline produced 200+ multi-page website templates across 5 tech stacks: HTML/Tailwind, React, Next.js, Vue, and Svelte, all free to download. The templates are the output. The pipeline is the real product.
Here is how it actually works, from the data layer to the final framework export.
The Architecture At A High Level
The pipeline has eight stages. Each one feeds the next:
- Structured CSV files define industries, styles, landing patterns, typography, colors, UX guidance, and page structures.
- A prompt generator turns that data into concrete template briefs.
- A master instruction file tells the AI exactly how to plan, build, QA, and finalize a site.
- An AI build stage generates multi-page HTML/Tailwind templates.
- Assembly and QA scripts inject shared layout and audit links, assets, and metadata.
- A review panel lets me manually inspect templates and mark problems.
- A structure converter rewrites each HTML template into a normalized intermediate representation.
- Framework converters use that intermediate representation to emit Next.js, React, Svelte, and Vue versions.
If you have read my other posts, this should feel familiar. I do not let AI operate unbounded. I give it a system, constrain the output, and validate the result. That philosophy drives everything here.
The Data Layer: Turning Design Decisions Into Inputs
The foundation is a set of CSV files in design-data/data/. These are not just reference material. They are the structured knowledge base that drives every prompt.
Each CSV carries a specific slice of the design system:
products.csv- Maps business types to design direction: style recommendations, landing page patterns, color palette focuslanding.csv- Defines homepage structure and conversion logic: section order, CTA placement, conversion optimizationstyles.csv- Turns a style name into an implementation brief: effects, accessibility, mobile friendliness, complexitycolors.csv- Grounds palettes in product context: primary, secondary, CTA, background, and text hex valuestypography.csv- Pairs fonts as a system decision: heading and body fonts, mood keywords, Google Fonts URLsux-guidelines.csv- Stores reusable usability rules: dos and don'ts with code examples and severity levelscharts.csv- Recommends visualizations for data-heavy pages: chart types, accessibility notes, library recommendations
To make this concrete, here is one row from each of the key CSVs, the actual data the pipeline uses:
products.csv - SaaS (General)
Primary style: Glassmorphism + Flat Design
Landing pattern: Hero + Features + CTA
Color focus: Trust blue + accent contrast
Key consideration: Balance modern feel with clarity. Focus on CTAs.
styles.csv - Minimalism & Swiss Style
Primary colors: Black #000000, White #FFFFFF
Effects: Subtle hover (200-250ms), smooth transitions, sharp shadows
Best for: Enterprise apps, dashboards, SaaS platforms
Accessibility: WCAG AAA
Complexity: Low
colors.csv - SaaS (General)
Primary: #2563EB
Secondary: #3B82F6
CTA: #F97316
Background: #F8FAFC
Text: #1E293B
Border: #E2E8F0
landing.csv - Hero + Features + CTA
Section order: Hero with headline → Trusted By logos → Value prop →
Key features → Industry Stats → How It Works →
Testimonials → FAQ → CTA section → Footer
CTA placement: Hero (sticky) + Bottom
Every row is dense, opinionated, and specific enough that the AI never has to guess.
This matters because the AI is never starting from a blank page. It is always operating inside a constrained design space: what kind of site, what style family, what landing-page pattern, what sections, what the conversion goal is. That constraint is what makes generating 200+ templates feasible instead of chaotic.
Prompt Generation: From CSVs To Template Briefs
Most people write prompts by hand. I generate mine.
A prompt generation script (generate-prompts.py) combines inputs from the CSV knowledge base into concrete build specs. The process is straightforward:
- Load
products.csvkeyed by Product Type. - Load
landing.csvkeyed by Pattern Name. - Randomly combine one product type, one style (primary or secondary), one landing-page pattern, and one CTA from a preset list.
- Pull the color palette focus and key considerations from the product row.
- Pull the section order from the landing CSV.
- Construct a final prompt string with all of that: business type, style, layout, color theme, key focus areas, sections, and CTA.
- Deduplicate and cap by product count.
A single generated prompt carries the business category, design direction, layout pattern, content structure, color direction, decision criteria, and CTA goal, all in one dense line. The prompt is not treated as creative writing. It is treated as a compact spec.
Here is an actual generated prompt from the pipeline:
Build a website for a Curated Fashion E-Commerce Brand. Use Editorial + Minimalist Typography style. Layout: Hero-Centric + Product Showcase. Color theme: White (#FFFFFF) + Black (#000000) base, Gray-50 (#F9FAFB) alternating sections, custom primary scale from #FFF1F2 to #881337 with #E11D48 default for hover accents and interactive elements. Key focus: Product catalog. Lookbook editorial. Curated collections. Brand storytelling. Cart and checkout. Customer accounts. Index Sections: 1. Full-screen hero with dark gradient overlay and light-weight uppercase heading, 2. New arrivals four-column product grid with hover zoom, 3. Split-layout editorial feature with full-height image, 4. Shop by category with image cards and centered text overlay, 5. Instagram six-column grid linked to social, 6. Newsletter signup with email form. Primary CTA: Explore Collection.
One prompt carries the business type, style family, layout pattern, exact hex values, key features, section order, and CTA. Nothing is left to the AI's imagination.
That prompt produced this - Maison Curated, a 14-page editorial ecommerce site:
That is the key design decision. Instead of manually inventing 200+ different briefs and hoping each one is detailed enough, I generate them from combinations of structured attributes. The combinatorial math does the variety work. The data does the quality work.
The Retrieval Layer: How The AI Pulls From The Dataset
The AI does not just read raw CSV files directly. It uses a search layer.
The core engine (core.py) defines which CSV belongs to each design domain, which columns are searchable, and which should be returned. It builds a BM25 search index over the CSV content so the AI can query the dataset by intent instead of scanning everything manually.
A command-line wrapper exposes queries across every design domain:
python search.py "<keyword>" --domain product
python search.py "<keyword>" --domain style
python search.py "<keyword>" --domain typography
python search.py "<keyword>" --domain color
python search.py "<keyword>" --domain landing
python search.py "<keyword>" --domain ux
python search.py "<keyword>" --domain charts
Each domain gets its own query. The AI runs all of them before writing a single line of HTML.
That means when the AI starts building a template, it does not rely on a single static prompt. Each prompt acts as a query seed into a structured design database. The AI retrieves matching style guidance, color palettes, typography pairings, UX rules, and landing patterns. Then it combines those retrieved fragments with the hard rules in the build playbook.
This is a more important detail than it might seem. The AI is not just following instructions. It is pulling design knowledge from a queryable index, the same way a developer might reference a design system wiki before starting a build.
The Instruction Layer: Telling AI How To Build, Not Just What To Build
Here is where the project stops being "prompt engineering" and becomes systems engineering.
The prompt alone is not enough. If you give AI a well-structured brief and say "build this," you will get a plausible-looking site with dead links, inconsistent nav, and pages that reference things that do not exist. I know because I watched it happen dozens of times before I built the guardrails.
The real control mechanism is a build playbook (build-playbook.md). It does not just say "build a site." It defines a build protocol with explicit gates:
- A mandatory execution order
- Planning before implementation, a required
IMPLEMENTATION_PLAN.mdbefore any code - Strict page-count limits by template type
- Exact rules for detail-page reuse
- A zero dead-links policy
- A required QA sequence
- Metadata generation only after QA passes
On top of that, a QA automation overlay enforces a strict post-build checklist:
- Run the layout assembler
- Run the link auditor
- Verify no
href="#"or empty links remain - Run the asset auditor
- Verify image URLs
- Run the metadata generator
In practice, the AI is not just being told how to design a template. It is being told how to behave like a production assistant with a checklist. If you have read my post on how I automate my agents, this is the same philosophy: constrain the agent, gate-check the output, verify before marking anything done.
Why HTML/Tailwind Is The Source Format
HTML/Tailwind is the authoring format. Not the final ceiling.
I chose it for practical reasons: it is the easiest format for AI to generate complete visual output. HTML is explicit, Tailwind keeps styling local to the markup, the pages are easy to inspect without a build step, and the same output can later be normalized into framework-specific code. That normalization is what makes the whole pipeline possible. HTML/Tailwind gives the AI a concrete, inspectable target, and it gives the rest of the pipeline a deterministic input that every downstream step can rely on.
The Website Generation Stage
Once the prompt and instruction layers are in place, the actual site generation happens into site-templates/. Each template gets its own folder with a naming convention like theme-industry-style:
ai_chatbot_platform-saas-modernagriculture_farm-agriculture-moderncyber_fortress-saas-cyberpunknutriplan_ai-wellness-aurora_flat
That naming scheme is doing more than labeling. The metadata generator parses the folder name to infer theme, industry, and style. Everything downstream depends on this convention.
Inside a generated template folder, you get a multi-page Tailwind site: index.html, about.html, contact.html, pricing.html, archive pages like blog.html or services.html, detail pages like blog-post.html or product-detail.html, plus shared header.html and footer.html partials, metadata.json, and sometimes planning notes.
The AI generates all of this under tight rules: use Tailwind, stay within page-count limits, make every link functional, map archive pages to exactly one detail page per content type, and keep shared header and footer separate from page bodies. That separation feeds directly into the next stage.
Shared Layout Assembly
During generation, it is easier to keep shared layout as source-of-truth partials. During delivery, each page needs fully embedded markup. The layout assembler bridges that gap.
The script supports three patterns:
- Marker replacement via
<!-- HEADER -->and<!-- FOOTER -->comments - Block replacement of existing
<header>and<footer>elements - Fallback injection directly after
<body>and before</body>
After assembly, every page is a complete, self-contained document. That makes them easier to review and easier to convert later.
QA: Enforcing Site Integrity With Scripts
If you let AI generate 200+ multi-page websites without automated QA, you will ship broken sites. I guarantee it. AI output fails in predictable ways: a page exists but is never linked, a nav item points to a missing file, archive-to-detail relationships drift, and the same stock photo shows up on every page.
The QA stage catches those structural errors before I ever look at a template visually.
Link Auditing
The link auditor parses every <a href> in a template folder and builds a small adjacency graph for the site. It flags broken internal links, orphan pages unreachable from index.html, and dead-end pages with no incoming links. It is graph validation applied to website navigation, simple, effective, and it catches the exact class of errors AI-generated multi-page sites produce most often.
Asset Auditing
The asset auditor scans HTML for externally referenced media, img src, srcset, inline background-image, <style> backgrounds, video posters, and media sources. It checks those URLs with curl, flags broken assets, and reports duplicate image usage across pages.
That duplicate-image check matters more than you might think. A generated site can technically work while still feeling cheap if the same hero image appears on every page. The asset auditor pushes the templates toward more believable variety.
Metadata Generation
After QA passes, the metadata generator creates a metadata.json file in each template folder. It infers industry, style, theme, and page count from the folder structure, then creates permutations for each supported stack. Metadata is not an afterthought, it is generated from the site itself and aligned with the stack outputs the pipeline is going to produce.
The Manual Review Layer
Scripts catch structural problems. They do not catch ugly.
That is what the review panel is for. It is a Flask-backed tool that gives me a carousel for browsing templates, fit-to-screen or scrollable views, issue tagging, per-page notes, and persistent issue storage.
The issue categories tell you exactly what kinds of defects I expected AI to introduce: broken layout, poor contrast, missing icons, broken or wrong images, not enough sections, missing detail pages, unreadable hero text, missing header or footer, and contact form issues.
Template generation has two kinds of quality: structural correctness and design credibility. The scripts handle the first. The review panel exists for the second. You cannot automate taste, but you can build a tool that makes it fast to exercise.
Structured HTML: The Intermediate Representation
This is the most important engineering layer in the whole system.
Instead of converting arbitrary HTML directly into the other four frameworks, which would mean each converter has to solve HTML cleanup, semantic inference, and component detection on its own, the pipeline first normalizes everything into a clean intermediate format.
The structure converter (html_structure_converter.py) takes raw HTML pages and produces a normalized output stored in converters/structured-html/. For each page, you get:
- A structured HTML file with semantic markup
content.json- normalized content buckets: headings, paragraphs, CTAs, imagescomponents.json- inferred component usage: Header, Navigation, Card, Section, Grid, Button, Iconconversion-config.json- configuration for downstream convertersstyles.jsonandstyles.css- extracted styling patterns
The converter parses Tailwind-heavy HTML with BeautifulSoup, classifies layout and spacing and typography patterns, detects reusable component shapes, and extracts page content into structured data, all while preserving enough document structure to rebuild the page in any target framework.
That two-stage design, normalize first, then translate, is what makes the rest of the pipeline realistic. Each framework exporter becomes a translation step instead of a full parser plus translator. It is the engineering move that turns the project from "AI generated some websites" into a real multi-target content pipeline.
Converting Structured HTML Into Frameworks
Once a template exists in structured form, the framework exporters operate on clean, consistent input. An orchestration script (convert_all.py) ties it together: read a source template, run the structure converter, run the framework converters, write results into stack-specific output folders, and zip the output.
Each exporter handles the framework-specific translation:
Next.js converts to App Router style output, HTML to JSX, class to className, page metadata extraction, reusable component extraction, and project scaffolding with src/app/, src/components/, and Tailwind config.
React targets plain React component output, JSX conversion, React props and event handlers, and extraction of repeated primitives into reusable components like Button, Link, Icon, Image, and Text.
Vue maps to Vue component syntax, Vue event bindings, page-level metadata objects, and component-driven output that preserves the Tailwind class strategy.
Svelte targets SvelteKit conventions, Svelte-friendly templates, Svelte event handlers, and SvelteKit page naming like +page.
The critical thing all four share: because they operate on the intermediate representation instead of raw HTML, they are translators, not parsers. The normalization layer already solved the hard problems. Each exporter just maps from one well-defined shape to another.
What I Actually Learned
A pipeline like this buys speed and scale, but I would be lying if I said every part worked perfectly from day one. Here is what I learned building it.
Prompts are necessary but not sufficient. Even a detailed, data-driven prompt can still produce inconsistent navigation, duplicate imagery, or sloppy page relationships. That is exactly why the project needs both scripted QA and a visual review tool. The prompt sets direction. The scripts enforce discipline.
HTML is a good source format, but it is not a clean application format. AI can generate HTML/Tailwind quickly, but that output is not immediately ready to become a maintainable React or Vue codebase. The structured conversion layer exists because raw markup is not a strong interchange format by itself.
Framework conversion is translation, not magic. The converters preserve structure, content, and most of the styling model. But they are still translating generated markup. The better the original template discipline, the better the converted output. Garbage in, garbage out still applies, you just need to catch the garbage earlier.
The intermediate representation was the best decision I made. I almost skipped it and went straight from HTML to framework code. That would have been a nightmare, four converters each solving the same parsing problems independently. The two-stage approach (normalize, then translate) cut the complexity of every exporter in half and made the whole conversion layer maintainable.
The real product is the system. The templates matter, but the durable asset is the pipeline: data-driven prompts, instruction-driven generation, enforced QA, visual review, intermediate normalization, and multi-stack conversion. That system is what makes generating hundreds of templates feasible instead of insane.
The End Result
That is how I built FreeStackTemplates.io. Not by asking a model to "make 200+ websites," but by building a workflow where data defines the brief, prompts define the task, instructions define the rules, scripts enforce the guardrails, review defines the quality bar, and converters define the delivery targets.
AI generated the markup. Code enforced the quality. Structure made the whole thing scale.
200+ templates. 37 industries. 29 styles. 5 tech stacks. Free to download.
Browse the full library at FreeStackTemplates.io and grab whatever you need.
Related Reading:
