I Built a Client Website With Claude, Astro and Sanity  🔗 **Source:** [I Built a Client Website With Claude, Astro and Sanity](https://www.youtube.com/watch?v=Iz-TC0uP6Gc) > [!note]+ Document Notes > tags: [astro, sanity-cms, cloudflare-pages, headless-cms, claude-code, ai-assisted-design, page-builders, elementor, wordpress-alternatives, client-work, web-design-process, design-feedback-tooling, ai-slop-debate, freelance-web-design, rino-de-boer] > author: Rino de Boer > source: YouTube > reference: https://www.youtube.com/watch?v=Iz-TC0uP6Gc > date created: 2026-09-02 08:45 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > > [!warning] Read with these in mind > > **Auto-captions.** 2,121 words of YouTube ASR from a Dutch speaker; the timestamps in `<span>` tags are the only structure. Two product names are uncertain transcriptions: "Novamira" (the connector between his WordPress site and Claude — unverified product, possibly misheard) and "Pixieset" (plausible; a real photographer gallery service). "photogenetic" is the speaker's word for photogenic. **Sponsor/affiliate context.** Rino de Boer is an Elementor-tutorial YouTuber ("maybe you see me as the Elementor guy"); Hostinger is named as the easy-hosting comparison, and Hostinger is a common sponsor in this channel niche — no sponsorship is disclosed in this transcript, so treat the mention as unverified either way. **Unverified claims.** "the moment he clicks save… Cloudflare puts the new version live" — a static-site rebuild and deploy is not instant; no build time is stated. The 16–17 hour vs. 40 hour comparison is the speaker's estimate, not a measurement. Screen-recording demonstrations (prototype, plugin UI, Sanity studio) are described but not captured in the transcript. Publication date 2026-09-02, 10:52 runtime. > > # 🏷️ Title: I Built a Client Website with Claude, Astro and Sanity (No Pagebuilder) > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Source: https://www.youtube.com/watch?v=Iz-TC0uP6Gc - No links in the captured transcript (0 `<a>` tags). Products named by voice only: Claude, Sanity, Astro, Cloudflare, GitHub, Figma, Dribbble, Pixieset, Pages CMS, Keystatic, Slack, Hostinger, Elementor, WordPress, "Novamira" (uncertain). ## 📝 Summary **What this is.** A 10-minute case study from an Elementor-focused YouTuber who built a friend's wedding photo/video portfolio without WordPress or a page builder: Claude generated and iterated the design and front-end, Astro is the framework, Sanity (free plan) is the client-editable CMS, Cloudflare hosts, GitHub sits between Sanity saves and Cloudflare deploys. He estimates 16–17 hours total against a hand-built estimate of 40, with 2–3 hours of that spent re-prompting Claude on the prototype. "In total it took like two days," counting client meetings and CMS setup. **The irony he doesn't name as one.** The one piece of tooling he built for the project — a client-feedback plugin where the client clicks an element on the HTML prototype, leaves an anchored comment, and a Slack notification fires — runs on his own WordPress site. Claude wrote that plugin too. So the "no WordPress" project depended on WordPress for the review loop, and he's now using the plugin on "many different projects." **The design argument.** He anticipates the "AI slop" objection and answers it in three moves: design "is about making decisions" and he made them (questionnaire, goals, audience, competitor review, two Dribbble references the client picked); "a lot of what gets called AI slop is actually just people recognizing patterns that the AI is doing, but good designers also design in patterns"; and "you're designing for your client and not for the design community." **The honest limits.** The front-end "is not even built perfectly in terms of variables and classes"; that's acceptable for a one-pager but "when you're working with a huge project with multiple pages and templates, then a design system becomes a lot more important." Cloudflare "is not as easy as a platform like Hostinger." Making the site client-editable "is not easy." Page builders "still have a place" when projects "get super big." **Bottom line.** A working freelancer's honest account of what a Claude + Astro + Sanity + Cloudflare stack costs and delivers for a one-page portfolio: faster than hand-building, slower than the hype, and still leaning on WordPress for the part (client review) that the new stack doesn't solve. The strongest content is the process, not the stack — the client questionnaire, the FAQ built from real customer objections, and the element-anchored feedback plugin. ## 📖 Main Content **The client and the brief.** A photo and video business whose wedding work was "a little bit on the side" and previously delivered as single-wedding preview links (Pixieset). The client wanted a consolidated portfolio that also worked as "a little bit of a sales machine": prices and packages on the page so inquiries arrive pre-qualified. De Boer added an FAQ after learning that a recurring question from couples is — in Dutch on the site — "We are not photogenic and we don't like posing. Is that a problem?" His framing: "our role as a web designer is not just to make the website, it is to guide the clients through the process." The FAQ turned the site from portfolio into objection-handling. **The process before any tool.** A client questionnaire capturing main goal, secondary goal, and audience; competitor research ("what he likes and didn't like about his competitors"); a Dribbble mood board of wedding-site styles from which the client picked two. "This also takes away a lot of anxiety on my part whether what I'm gonna design is actually good." The point he wants viewers to take: the decisions were made before Claude was prompted, so "Claude did the design, but I would argue that I did the design." **Prototype iteration.** The first prototype shown was "already after a few hours of prompting"; the true first version "was actually a lot worse" and wasn't recorded. He puts the re-prompting at "around two, three hours." The original prompt was "quite big." Real client photos were available from the start, which matters for a photo-heavy layout. **The feedback problem, and the WordPress answer.** Figma gives clients a comment-on-canvas link; an HTML file in a folder doesn't. He asked Claude to build a WordPress plugin: the client opens `mysite/preview/<version>`, clicks an element, types a comment (name field, bold/italic), saves; the comment appears in his WordPress admin and posts to Slack. Version one had comments "flying around" unanchored; version two sticks them to elements, which lets Claude read the feedback with element context. The loop he describes: Slack notification → ask Claude to check the feedback (via a WordPress↔Claude connector he calls "Novamira") → Claude edits the HTML in the local folder → uploads a new version → generates a new preview link. He notes paid alternatives exist for HTML review and offers to release the plugin if there's interest. **Choosing a CMS.** Evaluated Sanity, Pages CMS (open source), and Keystatic ("doing tests with this one"). Chose Sanity for the free plan. He built "a little CMS with some post types" — portfolio items with photo/video type, position, alt text field — and reviews. Saving in Sanity triggers a build; Cloudflare deploys. His comparison: like WordPress "the moment you click save, the changes are live… but then without all the caching layers and everything that makes it slow." The client's login shows only content fields — none of the "pop-ups and all kinds of things that the client really doesn't care about" on a WordPress dashboard. **Why Astro, why Cloudflare.** Image-heavy site, wanted speed. "Astro ships very minimal JavaScript" versus WordPress "especially with PageBuilders" shipping "a whole bunch." He mentions Astro can also front a headless WordPress. Cloudflare account created in the client's name. GitHub is the deploy intermediary; "it took me a while to figure this out." **On design quality and "slop."** Admits imperfect variables and classes; argues a one-pager doesn't need a design system because "AI is good enough at this point to make sure that the design is consistent on one page," and "if something looks off, you can just tell the AI to fix it." Concedes "Claude has certain things that it repeats." Then the three-part defense of AI-assisted design quoted in the Summary. **The accounting.** Design and front-end build: "a few hours." Client-editability, Cloudflare, GitHub, email and domain setup: the rest. Total 16–17 hours; his hand-build estimate is 40. Verdict: "still a win," "we're going to a time where we may not need the PageBuilder and WordPress all the time." ## 🗒️ Notes - **The plugin is the most transferable artifact and it's a WordPress plugin.** Element-anchored client comments on a static HTML preview, with Slack notification and machine-readable anchoring so an agent can act on them. That's a real gap in the Astro/headless workflow, and he filled it with the platform he's leaving. Worth watching whether he releases it. - **"No WordPress" is true of the deliverable, not the workflow.** WordPress hosts the review loop; Sanity replaces the editing UI; Cloudflare replaces hosting. The video's title claim survives; its thesis ("we don't really need WordPress") is undercut by his own tooling. - **The speed comparison is against page builders, not against WordPress.** Every performance claim ("ships a whole bunch of JavaScript," "caching layers… that makes it slow") is about Elementor-class page builders on shared hosting. A block-theme WordPress site with no builder isn't in his comparison set. For the block editor vs. Astro question Courtney cares about, this video is evidence about Elementor, not about Gutenberg. - **Sanity's client UI is the WordPress-admin critique done by demonstration.** "When the client logs in, this is the only thing they see." The WordPress dashboard for a small-business client — plugin nags, update notices, admin pointers — is what he's contrasting with. That's a UX argument WordPress can answer (curated admin, `remove_menu_page`, client roles) but usually doesn't by default. - **Alt text made it into the CMS schema.** He shows the client entering alt text per portfolio image. Small, but it's an accessibility affordance built into the editing model rather than bolted on. - **The time estimate is soft in both directions.** "Two days" and "16 or 17 hours" and "a few hours" for design/build appear in the same video; the 40-hour hand-build baseline is a guess. The honest number is the ratio he believes, ~2.5×, not the hours. - **"Instant" publish isn't.** Sanity save → GitHub → Cloudflare build → deploy is a pipeline with a build step; he compares it favorably to WordPress caching but doesn't say how long it takes. Unverified. - **Dutch-market freelancer, one-page brochure site.** The whole case is a portfolio one-pager for a friend. He says so, and scopes the conclusion to "relatively simple" projects. Don't generalize past that. - **ASR uncertainties.** "Novamira" — unverified; could be a misheard MCP/connector name. "Pixieset" is plausible. Neither affects the argument. ## 📚 References - de Boer, R. *I Built a Client Website with Claude, Astro and Sanity (No Pagebuilder)*, YouTube, 2026-09-02, 10:52. Auto-captions. - Named tools (voice only, no links): Claude (Anthropic), Astro, Sanity (free plan), Cloudflare (Pages/Workers unstated), GitHub, Figma, Dribbble, Pixieset, Pages CMS, Keystatic, Slack, Hostinger, Elementor. - The client-feedback WordPress plugin is described but not named or linked; not released at recording time. - Cross-reference (Courtney): `courtneyr-design-system` and the Stream/blog zine redesign — a block-theme build that is the comparison this video omits. ## 🗣️ Paraphrase I'm known for Elementor tutorials, and I just built a client site with none of it: Claude for design and code, Astro for the front end, Sanity so the client can edit, Cloudflare to host. Two days including meetings, about 16–17 hours of work against maybe 40 by hand. The client is a wedding photographer who wanted his portfolio in one place plus prices and an FAQ that answers "we're not photogenic" before anyone asks. I did the design work that matters — goals, audience, competitors, two reference styles the client picked — and then spent two or three hours steering Claude to a prototype. Getting client feedback on an HTML file was the gap, so I had Claude build me a WordPress plugin: the client clicks an element on a preview link, leaves a comment, I get a Slack ping, and Claude can read the anchored comments and revise. Sanity gives the client a screen with only the fields he needs. Astro keeps the JavaScript small. The code isn't perfectly systematized, but for a one-pager it doesn't need to be. People will call it AI slop; I think design is decisions, patterns are what designers use anyway, and the client — not the design community — is who I'm designing for. Page builders still make sense for big projects. For simple ones, I'm less sure we need them, or WordPress. ## 📰 Newsletter **The Elementor guy built a site without Elementor — and kept WordPress for the one thing the new stack couldn't do.** Rino de Boer's 10-minute case study puts Claude, Astro, Sanity, and Cloudflare to work on a wedding photographer's one-page portfolio: 16–17 hours versus his 40-hour hand-build guess, two to three of those hours re-prompting the design. The useful parts aren't the stack. They're the process — a client questionnaire, competitor review, two Dribbble references the client chose, and an FAQ built from a real objection ("we're not photogenic") — and a Claude-written WordPress plugin that lets the client click any element on an HTML prototype, leave an anchored comment, and ping Slack, so an agent can read the feedback with element context and revise. That plugin runs on WordPress. The performance case is made against page builders on shared hosting, not against the block editor; the "instant publish" claim skips the build step; the hour counts are estimates. His own scoping is the right one: page builders "still have a place" on big projects, and this is a one-pager for a friend. What WordPress should hear: his client's Sanity login shows only content fields, and that's the comparison he's winning. ## ✅ Action Items **DevRel** - The element-anchored feedback plugin is a concrete, demonstrable developer story: agent reads client comments with DOM context and ships a revision. If he releases it, it's a case study candidate; if not, the pattern is reproducible. `#action/h2` - The video's implicit critique — WordPress admin shows clients things they don't care about — is a positioning problem, not a technical one. Content that shows a curated client admin answers it. `#action/h3` **OSPO** - Not applicable to this source. **Community** - Not applicable to this source. **WordPress teams** (Core, Core Performance, Core AI, Core Program Team, Mobile, Playground, Community, Training, Marketing, Support, Design, Documentation, Photos, TV, Polyglots, Accessibility, Meta, CLI, Hosting, Tide, Openverse, Themes, Plugins) - **Core Performance:** every speed claim here is against page builders. A published comparison of a block theme vs. Astro on the same one-pager would either confirm or retire the "WordPress ships too much JavaScript" line for builder-free sites. `#action/h2` - **Design:** "when the client logs in, this is the only thing they see" is the bar. A client-role dashboard that hides plugin nags and update notices by default is the feature being requested by demonstration. `#action/h2` - **Marketing:** "the Elementor guy" saying "we may not need the PageBuilder and WordPress" conflates the two. Messaging that separates WordPress from page builders is overdue; this video is the evidence. `#action/h3` - **Hosting:** "Cloudflare is not as easy as Hostinger" — managed WordPress hosting's ease is the retained advantage he names. Worth quoting. `#action/h3` - All other teams: not applicable to this source. **The WPOCC** - Not applicable to this source. **FAIR** - Not applicable to this source. **Personal (Courtney)** - **You're joining Pantheon on Sept 14.** This video is a freelancer choosing Cloudflare + GitHub + static build over managed WordPress hosting and finding it harder than Hostinger. The "not easy" list — Cloudflare setup, GitHub intermediary, email and domain — is the managed-hosting value proposition stated by someone leaving it. Keep for onboarding context. `#action/h2` - **Block editor vs. "no pagebuilder."** Your zine redesign is a block-theme build with no builder. That's the comparison this video skips. If you write about it, this is a citable example of the Astro pitch resting on Elementor-era performance assumptions. `#action/h2` - **Steal the FAQ move.** An FAQ built from the client's most common real objection ("we're not photogenic") is a reusable discovery question for any client site: "what do people ask you before they book?" `#action/h3` - **Watch for the plugin release.** Element-anchored comments on a static preview with agent-readable context is a pattern worth having regardless of stack. `#action/h3` ## 🧪 Hypotheses - **H-A:** For one-page brochure sites, the time savings de Boer reports come mostly from AI-generated front-end code, not from leaving WordPress; the same Claude workflow targeting a block theme would land in a similar hour range. *Testable by replicating the brief on a block theme.* - **H-B:** The "clients only see what they need" advantage of Sanity is reproducible in WordPress with a client role and admin curation, and the reason it isn't the default is defaults, not capability. *Testable in one afternoon.* - **H-C:** Sanity save → GitHub → Cloudflare deploy for this site takes 30–120 seconds, not "the moment you click save." *Testable if the site URL were known; it isn't given.* - **H-D:** Element-anchored client feedback readable by an agent shortens revision cycles more than any framework choice in this stack. *Testable if the plugin is released.* ### 📊 Methodology A single-case practitioner report, n=1, self-reported hours, no measurement of page speed beyond "super fast," and a hand-build baseline that is an estimate. The demonstrations (prototype, plugin, Sanity studio) are shown on screen and not in the transcript, so this note can't check them. The speaker's incentives cut both ways: he's known for Elementor content and is signaling a pivot, which makes his concessions (page builders still have a place; Cloudflare is harder; client-editability is not easy) more credible than his headline. Treat the ratio (~2.5× faster than hand-build) as his belief and the process description as the reliable part. ### ❓ Questions - What is the actual save-to-live latency on the Sanity → GitHub → Cloudflare pipeline? - What did the "absolute first version" from Claude look like, and what in the prompt moved it? The 2–3 hours of re-prompting is the real cost and it's unexamined. - Is "Novamira" a real connector, and does the WordPress plugin expose comments over a REST endpoint or MCP for Claude to read? - Would the same client questionnaire → Claude prompt → block theme workflow have taken meaningfully longer? He never tried it. - What does the client do when Sanity's free-plan limits are hit, or when a build fails? Who supports the pipeline in a year? - Is Hostinger a sponsor of the channel? The comparison is favorable and undisclosed here. ### 🔮 Future Research - Replicate the brief — one-page wedding portfolio, client-editable, image-heavy — on a block theme with Claude doing the build, and compare hours and Lighthouse scores. That's the missing control. - Survey what WordPress agencies use for element-anchored client feedback on staging; if the answer is "paid SaaS or nothing," his plugin pattern is a gap in the ecosystem. - Track de Boer's channel for the plugin release and for whether the pivot from Elementor content holds. - Compare Sanity/Keystatic/Pages CMS client UIs against a curated WordPress client role for the "only what they need" test. ### 💡 Implications **For WordPress.** The competitive threat in this video isn't Astro; it's the client editing experience and the page-builder JavaScript tax being attributed to WordPress as a whole. Both are addressable. Neither is addressed by default. **For freelancers.** The stack shifted but the billable hours moved, not vanished: from building the front end to wiring Cloudflare, GitHub, email, domain, and a CMS the client can use. "Making the website editable for clients is not easy" is the sentence to remember. **For AI-assisted design.** His defense — decisions are the design, patterns are normal, the client is the audience — is the practitioner's answer to "AI slop." It's sound for a one-pager where the client chose the references. It gets weaker as the project grows and the design system he admits he skipped becomes load-bearing. **For managed hosting.** He names the trade: control and speed for setup difficulty. That's the pitch for managed WordPress hosting, stated by someone who just walked away from it. ## 🧠 Learning Styles Assessment **Visual** — the primary mode. The video is a screen recording of the prototype, the plugin UI, the Sanity studio, and the Dribbble references; none of that is in the transcript. **Auditory** — served; conversational, first-person narration with a clear arc (brief → process → prototype → feedback → CMS → hosting → reflection). **Read/write** — weak; auto-captions only, no links, no written summary. **Kinesthetic** — indirect; the process (questionnaire, reference picking, prompt iteration, plugin loop) is reproducible but no artifacts are shared. **Sequential** — well served; the video follows the project timeline. **Global** — served by the opening and closing thesis statements. **Overall:** a show-and-tell for practitioners who already know the tools' names. Not a tutorial; he says "I cannot explain the whole stack in this video." ## 📊 Accessibility Assessment Assessment of the video as a learning artifact and of what the transcript reveals about the built site. Not an audit of either. #### Alternative text and non-text content The built site's CMS includes an alt text field per portfolio image, entered by the client — a good sign for WCAG 1.1.1 if the client fills it. The video itself relies on screen recordings with no described visuals; a viewer without sight gets the narration only. #### Keyboard navigation Not assessable. The feedback plugin's click-an-element interaction is mouse-described; keyboard operability unknown. #### Contrast and readability Not assessable from transcript. Wedding-photography sites in the Dribbble style he references often use low-contrast script type; unverified for this build. #### Text resizing and reflow Not assessable. Astro output is plain HTML/CSS, which is a neutral starting point. #### Media and captions YouTube auto-captions only; several product names are unreliable. No human captions, no transcript posted. #### Forms and interactions The plugin's comment form (name, comment, bold/italic, save) is described; labeling and focus behavior unknown. #### Standards reference WCAG 2.2 AA — relevant criteria: 1.1.1 Non-text Content (alt text field present), 1.2.2 Captions (auto-captions only), 2.1.1 Keyboard (unknown), 1.4.3 Contrast (unknown), 2.4.7 Focus Visible (unknown). Nothing can be marked pass or fail. ## 🌍 DEIB Assessment #### Cultural breadth A Dutch freelancer working for a Dutch client (the FAQ is in Dutch), explaining in English to a global audience. Tools and pricing assumptions are Western/European small-business. #### Inclusive language Neutral. "The client," "he" for the specific client. "AI slop" is used to name a critique he then rebuts. #### Neurodiversity support Linear narration with explicit signposting ("so let me show you how this went," "so that's just something that I wanted to say"). Fast-paced screen recordings may be hard to follow without the visuals. #### Representation One voice, one client. The client's perspective is reported ("my client is super happy"), not heard. The couples whose objection ("not photogenic") became an FAQ are represented only through that line. #### Psychological safety He names his own anxiety ("takes away a lot of anxiety on my part whether what I'm gonna design is actually good") and pre-empts criticism without dismissing critics ("I totally get that"). That's a healthy register for a practitioner reporting an experiment. ## ✅ Logical Validity **Central claim:** for simple sites, WordPress and page builders may not be needed; this project shows it. **Support:** one completed project, faster than his hand-build estimate, client happy, site fast. **Weaknesses:** 1. *Sample of one, self-estimated baseline.* 16–17 vs. 40 hours compares a measurement to a guess. 2. *Conflation.* "WordPress and a PageBuilder" is treated as one thing throughout; the performance evidence is about page builders. The conclusion about WordPress doesn't follow from evidence about Elementor. 3. *Self-undermining tooling.* The review loop runs on WordPress. "We don't really need WordPress" is contradicted by the workflow that produced the site. 4. *Unverified pipeline claim.* "The moment you click save… live" versus a build pipeline. 5. *Scope discipline is good.* He limits the conclusion to "relatively simple" projects and concedes builders "still have a place." That's the part that holds. **Fallacies.** Hasty generalization, mitigated by his own scoping. False equivalence between WordPress and page builders. No straw man — he states the "AI slop" objection fairly before answering it. **Verdict.** Valid as "here's what worked for me on a one-pager." Invalid as a claim about WordPress generally. The design-as-decisions argument is coherent for the scale he's working at. ## 🛡️ DARVO Analysis Not applicable to this source. No accusation, no victim/offender reversal. The nearest thing to a defensive move is his pre-emptive answer to the "AI slop" critique, and he handles it by conceding ground ("Claude has certain things that it repeats," "I totally get that") before arguing — the opposite of denial or reversal. ## 🎯 Conclusion De Boer built a one-page wedding portfolio with Claude, Astro, Sanity, and Cloudflare in what he estimates at 16–17 hours, and the result is a credible practitioner's report because of what he concedes: the code isn't systematized, Cloudflare is harder than managed hosting, client-editability is the hard part, and page builders still fit big projects. The headline — no WordPress, no page builder — is true of the deliverable and false of the workflow: his client-feedback tool is a Claude-written WordPress plugin he now uses everywhere. The performance and admin-clutter arguments are aimed at Elementor-on-shared-hosting and hit it; they don't touch a block theme, which he never tried. For Courtney, three things travel: the FAQ-from-real-objections discovery question, the element-anchored feedback plugin pattern (agent-readable client comments), and a clean statement of the managed-hosting value proposition from someone who just left it — two weeks before she starts at Pantheon. ## 🔄 Refactor Appendix — I Built a Client Website with Claude, Astro and Sanity (No Pagebuilder) ### 📚 Literature Atoms (H3) #### [H1] Design is the decisions; the tool that renders them is secondary > [!quote] ID:rw_01m1h1fdc81z7wqm3qcmt1tzze > "In this case, Claude did the design But I would argue that I did the design, right? Because what is design really about? It is about making decisions." The questionnaire, goals, audience, competitor review, and client-picked references came before the prompt. The defense of AI-assisted design rests here. Tags: `#atom/literature/h1` #### [H2] "AI slop" is often pattern recognition, and designers work in patterns too > [!quote] ID:rw_01m1h1fdc81z7wqm3qcmt1tzze > "A lot of what gets called AI slop is actually just people, recognizing patterns that the AI is doing, but good designers also design in patterns. at the end of the day, you're designing for your client and not for the design community" Preceded by the concession "Claude has certain things that it repeats." The argument holds for a one-pager with client-chosen references; weakens with scale. Tags: `#atom/literature/h2` #### [H3] The client's editing screen should show only what the client needs > [!quote] ID:rw_01m1h1fdc81z7wqm3qcmt1tzze > "So when the client logs in, this is the only thing they see. They don't see anything as you see on WordPress where you have like pop-ups and all kinds of things that the client really doesn't care about." The WordPress admin critique by demonstration. Answerable with a curated client role; not answered by default. Tags: `#atom/literature/h3` #### [H4] Leaving WordPress moved the hours; it didn't remove them > [!quote] ID:rw_01m1h1fdc81z7wqm3qcmt1tzze > "I did not use WordPress. I did not use a PageBuilder, but it was also not a few hours of work. […] But making the website editable for clients is not easy. Using something like Cloudflare is not as easy as a platform like Hostinger. A GitHub also needs to be in between […] so again, the whole thing took like I think 16 or 17 hours." The concession that makes the report credible. Design and build were "a few hours"; the rest was plumbing. Tags: `#atom/literature/h4` ### 🧠 Permanent Candidates (H4) #### [P1] The "leave WordPress" case is usually a "leave page builders" case wearing a bigger claim Every performance and clutter argument in this video is evidence about Elementor-class builders on shared hosting — JavaScript weight, caching layers, admin noise. A block theme with no builder isn't in the comparison, and the speaker's own review tooling runs on WordPress. When a practitioner says "we may not need WordPress," check whether the evidence is about WordPress or about what was installed on it. *Candidate; one source, but the conflation is common enough in freelancer content that a named pattern is useful, and it's directly relevant to how Courtney writes about the block editor.* Links: [[Page Builder JavaScript Tax]] · [[Block Editor vs Headless Pitch]] · [[WordPress Positioning MOC]] Tags: `#atom/zettel/z1` #### [P2] Client-editable is the hard half of a client site, whatever the stack Design and front-end build took "a few hours"; CMS setup, hosting, deploy pipeline, email and domain took the rest of 16–17. The stack changed which vendor supplies the editing UI (Sanity for WordPress) and which supplies hosting (Cloudflare for managed WP), but the hours went to the same job: making it something the client can run. *Candidate; the general claim is well supported by agency experience, and this is a clean single-source statement of it from someone who expected otherwise.* Links: [[Managed Hosting Value Proposition]] · [[Client Site Handoff Costs]] · [[Freelance Web Work MOC]] Tags: `#atom/zettel/z2` ### ✏️ Fleeting Queue - Element-anchored client comments on a static HTML preview, with Slack notification and agent-readable DOM context — a Claude-written WordPress plugin. Watch for release; reproducible either way. `#atom/fleeting/f1` - "What do people ask you before they book?" — the discovery question that produced the FAQ. Add to client questionnaire. `#atom/fleeting/f1` - "Novamira" — verify whether this is a real WordPress↔Claude connector or an ASR error. `#atom/fleeting/f1` - Sanity / Pages CMS / Keystatic as the three headless CMS options a WordPress freelancer evaluates in 2026. `#atom/fleeting/f1` ### → Things 3 (max 2 actions) 1. **Add "what do people ask before they book?" to the client discovery questionnaire** you use for SJUCC and any site work. `#action/h3` 2. **Note the managed-hosting sentence for Pantheon onboarding:** "Using something like Cloudflare is not as easy as a platform like Hostinger. A GitHub also needs to be in between." `#action/h2` <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/I Built a Client Website With Claude, Astro and Sanity.md|I Built a Client Website With Claude, Astro and Sanity by Rino de Boer]] ## Highlights - so this also takes away a lot of anxiety on my part whether what I'm gonna design is actually good In this case, Claude did the design But I would argue that I did the design, right? Because what is design really about? It is about making decisions. And so the first prototype already came out quite good which is this one. So here you can see the first prototype, and my original prompt was of course also quite big Is it perfect? No, but it is very close to what I wanted. ([View Highlight](https://read.readwise.io/read/01m1h21bms9naf9k79zes4j40a)) - Note: H1 — Design is the decisions; the tool that renders them is secondary. Questionnaire, goals, audience, competitor review, client-picked references all preceded the prompt. #atom/literature/h1 - Tags: atom/literature/h1 - So when the client logs in, this is the only thing they see. They don't see anything as you see on WordPress where you have like pop-ups and all kinds of things that the client really doesn't care about. The client only really needs to see something simple like this. and then everything is hosted on Cloudflare. So I made a Cloudflare account for my client And then told Claude that I wanna host it on Cloudflare. And because this website is quite heavy when it comes to images, I of course wanted it to be fast, so I choose Astro, Because Astro ships very ([View Highlight](https://read.readwise.io/read/01m1h21rb7w615ys8an4hgxw0a)) - Note: H3 — The client's editing screen should show only what the client needs. Sanity studio vs WordPress admin pop-ups; the WP-admin critique by demonstration. Astro chosen for minimal JS on an image-heavy site. #atom/literature/h3 - Tags: atom/literature/h3 - Yes, AI and especially Claude has certain things that it repeats, but again, this is very close to the actual style that I wanted. The client gave a lot of input, and if I would've made this in Figma, it would've been really close to what you see right here A lot of what gets called AI slop is actually just people, recognizing patterns that the AI is doing, but good designers also design in patterns. at the end of the day, you're designing for your client and not for the design community So that's just something that I wanted to say ([View Highlight](https://read.readwise.io/read/01m1h21jhxh78p1fq8yshsbfbb)) - Note: H2 — "AI slop" is often pattern recognition, and designers work in patterns too; design for the client, not the design community. Concedes Claude repeats itself. #atom/literature/h2 - Tags: atom/literature/h2 - so yeah, the site is live now. I think my experiment is successful. I did not use WordPress. I did not use a PageBuilder, but it was also not a few hours of work. I mean, maybe just the design and the build of the actual front end was a few hours. But making the website editable for clients is not easy. Using something like Cloudflare is not as easy as a platform like Hostinger. A GitHub also needs to be in between I also helped the client with setting up their email and domain. so again, the whole thing took like I think 16 or 17 hours. ([View Highlight](https://read.readwise.io/read/01m1h21z02zkxkdhcxyypcr9bd)) - Note: H4 — Leaving WordPress moved the hours; it didn't remove them. Design+build "a few hours"; client-editability, Cloudflare, GitHub, email/domain took the rest of 16–17. Hostinger comparison undisclosed as affiliate. #atom/literature/h4 - Tags: atom/literature/h4