Generating a six-page dental clinic site with Qwen3.5
A local LLM test for website development: Qwen3.5 received a six-page dental site task using HTML, Tailwind CSS, and Alpine.js. Covers the 18-minute, 2-second run, recovery, reported output, and evidence limits.
The task
I asked Qwen3.5 to build a six-page dental clinic site using HTML, Tailwind CSS, and Alpine.js. Build steps and a SPA approach were prohibited. The task tested whether the model could maintain a multi-page structure and implement shared UI and page-specific interactions.
The full run took about 18 minutes and 2 seconds. The model reported generating the required files.
Multilingual support focused on the UI. Maintainability and SEO were also requirements.
What the test aimed to check
- Design of a static multi-page site
- Handling of ARIA attributes, focus management, and contrast
- Lightweight interactions with Alpine.js
- Recovery from tool errors and adaptation to the environment
Task conditions
Allowed technologies
- Plain HTML files only (no build step)
- Tailwind CSS via CDN
- Alpine.js via CDN (lightweight interactions only)
- No external UI component libraries
- No reuse of reference site text or imagery
The six required pages
| File | Content | Key Interactions |
|---|---|---|
| index.html | Hero, service cards, doctor previews, news, CTA | None (static) |
| services.html | 12+ treatment cards, category filter | Alpine.js filter, FAQ accordion |
| doctors.html | 6+ profiles | Expandable detail UI |
| info.html | Pricing table, insurance, payment methods | Estimate modal |
| visit.html | First-visit flow, booking funnel | Validation states |
| access.html | Address, transit, map | Route-mode tabs (car/train/walk) |
Shared layout
- Header: clinic name, primary nav, language-switch UI
- Mobile nav: Alpine.js hamburger menu, focus management, ESC-to-close
- Book Appointment: in-header on desktop, fixed bottom action on mobile
- Footer: clinic info, privacy/terms links, copyright
The fixed page count and interaction requirements allow the same task to be used for model comparisons.
Execution record
Directory creation and recovery
The first Create directory site attempt failed with Path to create was outside the project. The model then retried as follows:
- Called
list_allowed_directories - Confirmed
/was listed as an allowed root - Used absolute paths for
/Users/ksh3/Development/sandbox7/siteandsite/assets
It checked the allowed scope after the error, changed the paths, and continued.
File generation order
The model wrote each HTML file separately, added README.md, checked the directory listing, and added assets/placeholder.svg.
- Create directory structure
- Generate each page (index -> services -> doctors -> info -> visit -> access)
- Write README
- List files to confirm existence
- Add supporting asset
What the model reported
| Page | Reported Content |
|---|---|
| index.html | Hero, 8 service cards, 6 Why Choose Us points, 4 doctor previews, 3 news items, hours/insurance summary, CTA band |
| services.html | 16 treatment cards, category filter, 6-item FAQ accordion |
| doctors.html | 6 doctor profiles with expandable details |
| info.html | 8-row pricing table, cost-breakdown modals, insurance and payment methods |
| visit.html | 6-step first-visit timeline, reservation methods, validation states |
| access.html | Contact details, hours, route-mode tabs |
Page-level records
The source also contains this summary of the page features:
| Page | Main Elements | Alpine.js Interaction |
|---|---|---|
Home (index.html) | Hero section, 8 service cards, 4 strengths, doctor preview, news, office hours | Mobile navigation and language-switching UI |
Services (services.html) | 14 treatment cards, 4 categories, FAQ section | Client-side category filtering and FAQ accordion |
Doctors (doctors.html) | 6 doctor profiles, specialties, languages, qualifications | Expand/collapse behavior for profile details |
Info (info.html) | 8 pricing items, insurance support list, payment methods | Dynamic estimate modal showing cost breakdown |
Visit (visit.html) | 6-step first-visit flow and booking guidance | Booking request form with validation |
Access (access.html) | Contact info, map preview, nearby stations, parking info | Route guidance toggle for car, train, and walking |
The self-report lists 16 treatment cards; this table lists 14. Home’s strengths also differ: 6 Why Choose Us points versus 4 strengths. Without the HTML files, I cannot confirm which counts match the implementation.
Layout and accessibility reports
The booking button is fixed at the bottom on mobile and placed in the header on desktop. The record says the Alpine.js hamburger menu supports focus management and closing with ESC.
It also reports using header, nav, main, and footer, with headings from h1 through h3. Avoiding external UI libraries was intended to keep loading light and reduce layout shift.
Duration and diagnostics
The full process took about 18 minutes and 2 seconds.
- Generated HTML, CSS utility classes, and JavaScript logic for six pages
- Diagnostics reported no errors or warnings across the HTML files
- Used local SVGs and inline icons
What to check in the next comparison
The HTML files were not preserved, so the model’s report alone cannot establish quality. Reviewing the actual files would be necessary to check:
- Whether ARIA attributes are present
- Whether focus management is implemented
- Whether Tailwind class composition stays tidy
- Whether Alpine.js state management is correct
In a later test, I would run the same prompt on other models and save generated files, screenshots, and review results for comparison. Accessibility, interactions, and class composition would be evaluated quantitatively.
I would also catalog multi-page structure collapse, accessibility omissions, Alpine.js under-implementation, inconsistent page shells, and thin README documentation. If adding content translation, its boundary and update workflow would need to be defined separately from multilingual UI support.