There Are Only Four Sensible Ways to Build a Website  🔗 **Source:** [There Are Only Four Sensible Ways to Build a Website](https://www.jonoalderson.com/conjecture/four-ways-to-build-a-website/) > [!note]+ Document Notes > tags: #cms #web-development #architecture #wordpress #technical-strategy > author: Jono Alderson > source: jonoalderson.com > reference: https://www.jonoalderson.com/conjecture/four-ways-to-build-a-website/ > date created: 2025-01-10 10:30 > > # 🏷️ Title: There are only four sensible ways to build a website > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Evaluate current website architecture against the four patterns — implementation review #cms - [H2] Document publishing workflows and content complexity — operational assessment #content-strategy - [H3] Assess team capabilities for chosen stack long-term — resource planning #technical-strategy ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Jono Alderson - Independent Technical SEO](https://www.jonoalderson.com/) - [WordPress.org](https://wordpress.org/) ## 📝 Summary - **What happened**: Jono Alderson argues that despite endless CMS options, there are only four sensible website patterns based on organizational behavior and needs - **Why it matters**: Teams often choose stacks based on identity rather than operational reality, leading to expensive mismatches - **Key stakeholders**: Engineering teams, product managers, content creators, business stakeholders making technology decisions - **Risks and tradeoffs**: Wrong stack choice creates ongoing operational burden, limits growth, or forces costly rebuilds - **Bottom line**: Match your technology choice to your primary organizational pattern: product-like experiences (React), commerce (Shopify), static content (static generators), or complex publishing (WordPress/Drupal) ## 📖 Main Content Alderson challenges the conventional wisdom that CMS choice is primarily a technical decision, arguing instead that it's a constraint system that shapes organizational capability over time. He identifies four core patterns that most websites fall into, each with a clear technical answer. The core insight is that websites are systems that accrete complexity, not static artifacts. The stack chosen at launch determines whether growth feels like "compounding capability or slow, grinding failure." The four patterns are: 1. **React/Headless** - When the website is genuinely product-like with complex state and interactions 2. **Shopify** - When the primary job is commerce and selling at scale 3. **Static approaches** - When content rarely changes and simplicity is valuable 4. **WordPress/Drupal/TYPO3** - When complex, continuous publishing is the core system Alderson warns against "hybrid" approaches and the "seductive middle ground" of visual builders, arguing these optimize for creation speed but struggle with long-term operation. ## 🗒️ Notes #### 📄 [Article] — [H1] CMS choice is a constraint system, not a tooling decision - Key idea: Technology choice shapes organizational capability ceiling and operational risk floor - Evidence: "It decides what kinds of problems you can solve, which ones you will struggle with, and which ones you will never even see coming" #### 📄 [Article] — [H2] Teams choose stacks as identity expressions rather than operational needs - Key idea: Engineering teams pick React for control, design teams choose visual builders, editorial teams default to WordPress - Evidence: "These aren't irrational choices, but they are rarely grounded in a clear understanding of what the organisation actually needs to operate over time" #### 📄 [Article] — [H3] Websites are systems that accrete complexity over time - Key idea: The thing you launch is not the thing you end up running - Evidence: "They accrete complexity. More stakeholders, more content types, more integrations, more expectations, more edge cases" #### 📄 [Article] — [H2] React/headless is for genuinely product-like experiences - Key idea: Only justified when websites carry meaningful state and complex interactions - Evidence: "Some websites are applications which happen to run in a browser. They carry meaningful state. They orchestrate complex interactions" #### 📄 [Article] — [H3] Most React adoption is premature optimization - Key idea: A bit of interactivity doesn't make a website an application - Evidence: "A login does not require a bespoke architecture. Personalisation, in most cases, is shallow and can be handled without turning the entire system inside out" #### 📄 [Article] — [H2] Shopify for commerce-focused businesses - Key idea: Constraint is the value - handles payments, inventory, compliance machinery - Evidence: "The hard problems are no longer how to structure content or how to compose interfaces. They are payments, inventory, fulfilment, tax, fraud, compliance" #### 📄 [Article] — [H2] Static approaches for stable, simple sites - Key idea: Many websites don't change often and don't need dynamic complexity - Evidence: "A surprising number of websites don't change very often. They launch, they get updated occasionally, and then they sit there doing their job" #### 📄 [Article] — [H1] WordPress/Drupal for complex publishing systems - Key idea: Mature CMS platforms handle operational complexity of structured content at scale - Evidence: "These systems are designed to handle the operational complexity of publishing at scale. Not just editing content, but managing it as a system" #### 📄 [Article] — [H3] Visual builders optimize for creation, not operation - Key idea: Tools like Webflow excel at quick creation but struggle with long-term governance - Evidence: "In practice, these tools optimise for the moment of creation, not the reality of operation" #### 📄 [Article] — [H2] Hybrid approaches are usually one dominant system with secondary concerns - Key idea: Most "hybrid" websites aren't really hybrids - one system drives, others adapt - Evidence: "Most 'hybrid' websites aren't really hybrids. They're one dominant system with a secondary concern bolted on" #### 📄 [Article] — [H3] Headless multi-system architectures are extremely difficult - Key idea: Connecting best-of-breed systems requires expertise in failure modes and boundaries - Evidence: "You are now responsible for defining the boundaries between systems, synchronising data, handling failure states" #### 📄 [Article] — [H1] Teams misunderstand themselves, not the technology - Key idea: Wrong stack choices come from overestimating flexibility needs and underestimating ownership costs - Evidence: "They overestimate their need for flexibility, and underestimate the cost of owning it" ## 📚 References - [Four Ways to Build a Website - Jono Alderson](https://www.jonoalderson.com/conjecture/four-ways-to-build-a-website/) - [WordPress.org](https://wordpress.org/) - [Shopify](https://shopify.com/) ## 🗣️ Paraphrase - Website technology choice fundamentally shapes organizational capability and operational risk over time, making it a strategic constraint system rather than just a technical decision - Most teams select technology stacks based on team identity and immediate appeal rather than understanding their actual operational needs and long-term sustainability requirements - Despite endless CMS options, most websites fall into four clear patterns with obvious technical answers: product-like applications need React, commerce sites need Shopify, stable sites need static generators, and complex publishing needs traditional CMS platforms ## 📰 Newsletter **Choose Your Website Stack Based on Behavior, Not Identity** Jono Alderson's latest piece cuts through the noise of endless CMS debates with a simple truth: there are only four sensible ways to build a website. The key insight? Your choice shapes what's possible for years to come. For WordPress professionals, this validates what many of us know intuitively - WordPress shines when complex, continuous publishing is the core system. The platform's strength isn't just content creation, but managing structured relationships, workflows, and governance at scale. The article warns against the headless trend when it's not truly justified. While React and headless architectures have their place for genuinely product-like experiences, most sites adopting this pattern end up "rebuilding a CMS from scratch, badly." **Key takeaway**: Match your technology to your primary organizational pattern. If you're managing complex content relationships, user permissions, and publishing workflows, WordPress remains the sensible choice. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### WordPress - **Core**: Evaluate current Gutenberg capabilities against visual builder trends - **Documentation**: Create decision framework guides for stack selection - **Community**: Develop case studies showing WordPress success in complex publishing scenarios - **Training**: Build courses on content modeling and relationship management - **Marketing**: Counter headless-first narratives with operational reality stories #### DevRel - **Developer advocacy**: Create talks on "choosing the right constraint system" - **Education**: Workshop on long-term operational costs of different architectures - **Developer experience**: Document WordPress as publishing system, not just website builder - **Community management**: Moderate discussions about platform choice with operational focus #### OSPO - **Strategic Alignment**: Align platform choices with organizational publishing patterns - **Community Engagement**: Support WordPress ecosystem as publishing infrastructure - **Developer Support**: Training on stack evaluation beyond feature checklists ## 🧪 Hypotheses - Teams that choose technology based on operational patterns rather than technical features will have lower long-term maintenance costs - Organizations using WordPress for complex publishing will outperform those using headless approaches for similar use cases - Visual builders will show increasing technical debt over time compared to traditional CMS platforms for content-heavy sites - Static site approaches will gain adoption as AI tools reduce the barrier to creation ### 📊 Methodology - Longitudinal study tracking website performance and maintenance costs across different stack choices - Survey organizations about decision-making criteria versus actual operational outcomes - Analyze migration patterns from headless back to traditional CMS platforms ### ❓ Questions - How do we measure "operational complexity" to better predict appropriate stack choice? - What signals indicate when an organization is outgrowing their chosen platform constraints? - How does AI-assisted development change the cost calculations for different approaches? ### 🔮 Future Research - Framework for evaluating organizational publishing maturity - Comparative analysis of long-term total cost of ownership across platforms - Impact of AI tools on the traditional stack selection criteria ### 💡 Implications - **Practice**: Need for operational assessment before technical decisions - **Policy**: Platform selection should include long-term capability planning - **Education**: Training programs should emphasize constraint systems thinking - **Funding**: Budget planning must account for hidden operational costs of flexible platforms ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade #### 👀 Visual learners - Present: Clear categorization of four patterns with examples - Improve: Decision matrix diagram, architectural comparison charts #### 🔊 Aural learners - Present: Conversational tone with clear argumentation flow - Improve: Podcast version discussing real-world examples #### 🗣️ Verbal learners - Present: Rich analogies (constraint systems, accretion of complexity) - Improve: Glossary of technical terms, more business analogies #### 🧩 Kinesthetic learners - Present: Practical decision framework - Improve: Interactive assessment tool, hands-on evaluation checklist #### 🧠 Logical learners - Present: Clear if-then logic structure for each pattern - Improve: Decision tree, cost-benefit analysis framework #### 🧑‍🤝‍🧑 Social learners - Present: Organization-focused perspective - Improve: Team discussion guides, stakeholder interview templates #### 🧘‍♀️ Solitary learners - Present: Self-assessment questions implicit in content - Improve: Formal self-evaluation rubric, reflection prompts #### 🌿 Naturalistic learners - Present: Ecosystem thinking about technology choices - Improve: Platform evolution analogies, sustainability considerations ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading hierarchy, article structure - Improve: Better heading descriptions, landmark navigation #### Keyboard navigation - Present: Standard article navigation - Improve: Skip links to key sections #### Contrast and readability - Present: Clear text formatting - Improve: Check contrast ratios on code examples #### Text resizing and reflow - Present: Responsive design - Improve: Test at 200% zoom levels #### Media and captions - Present: Text-only article format - Improve: N/A for this content type #### Forms and interactions - Present: Simple contact forms - Improve: Form validation feedback ### 🌍 DEIB Assessment #### Cultural breadth - Present: Technology-focused without cultural bias - Improve: Examples from diverse organizational contexts #### Inclusive language - Present: Professional, jargon-free explanations - Improve: Define technical terms inline #### Neurodiversity support - Present: Well-structured with clear sections - Improve: Visual breaks, summary boxes #### Representation - Present: Focus on organizational patterns rather than individual roles - Improve: Include diverse team structure examples #### Psychological safety - Present: Non-judgmental approach to past decisions - Improve: Emphasize learning from mistakes ### ✅ Logical Validity #### Strong reasoning - **Deductive strength**: Strong - if organizational pattern X, then technology Y follows logically - **Inductive strength**: Strong - based on observed patterns across many organizations - **Causal reasoning**: Strong - clearly links technology choices to operational outcomes - **Analogical strength**: Effective use of constraint system analogy #### Fallacies - **False dichotomy**: Slight tendency to present only four options when nuance exists - **Appeal to consequences**: Some arguments focus on negative outcomes rather than inherent flaws #### Tone of voice - **Overall tone**: Authoritative but helpful, with practical focus on real-world outcomes ### 🛡️ DARVO Analysis - **Deny**: No defensive denials present - **Attack**: No attacks on opposing viewpoints or people - **Reverse victim/offender**: No victim/offender dynamics - **Emotional cues**: Frustration with poor technology choices, but channeled constructively ## 🎯 Conclusion Alderson provides a valuable framework for cutting through CMS choice paralysis by focusing on organizational patterns rather than technical features. For WordPress advocates, this reinforces the platform's strength in complex publishing scenarios while acknowledging appropriate use cases for other approaches. The key insight - that technology choice is a constraint system shaping long-term capability - should fundamentally change how teams evaluate platforms. Rather than optimizing for creation speed or technical elegance, the focus should be on sustainable operation over time. This framework helps teams avoid the common trap of choosing stacks as identity expressions and instead align technology decisions with actual operational needs and capabilities. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] CMS choice shapes organizational capability ceiling > [!quote] [There are only four sensible ways to build a website](https://www.jonoalderson.com/conjecture/four-ways-to-build-a-website/) by [[Jono Alderson]] via [[jonoalderson.com]]. Published 2026-04-09. Accessed 2025-01-10. > "Your choice of CMS is not a tooling decision. It is a constraint system." Framework for evaluating technology decisions based on long-term operational impact rather than immediate technical appeal. [view highlight](https://www.jonoalderson.com/conjecture/four-ways-to-build-a-website/#constraint-system) #cms #technical-strategy ID:rw_001 ### [H2] WordPress excels at complex publishing systems > [!quote] [There are only four sensible ways to build a website](https://www.jonoalderson.com/conjecture/four-ways-to-build-a-website/) > "These systems are designed to handle the operational complexity of publishing at scale." WordPress and similar platforms solve content relationship and workflow problems that modern stacks often reintroduce poorly. [view highlight](https://www.jonoalderson.com/conjecture/four-ways-to-build-a-website/#publishing-systems) #wordpress #content-strategy ID:rw_002 --- ### 🔖 Atomic Split Pad (Zettel Candidates) #### [Z1] Technology choices create operational constraints over time - Applies to all technology decisions, not just CMS selection - Referenced throughout article examples - Links: [[Technology-Strategy]] [[Operational-Complexity]] #### [Z2] Teams choose technology based <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Articles/There Are Only Four Sensible Ways to Build a Website|There Are Only Four Sensible Ways to Build a Website, jonoalderson.com]] ## Highlights - They want deeper editorial control, richer content modelling, unusual product structures, bespoke experiences which cut across the grain of the platform. At that point, the logic often drifts towards workarounds, heavy customisation, or stitching in additional systems to compensate. The simplicity which made the platform attractive begins to erode. ([View Highlight](https://read.readwise.io/read/01knwvdd1pw81x861q5d968cwx)) - Tags: 👻 ai highlighted - They think they need flexibility, so they reach for headless. They think they need control, so they build custom. What they actually need is structure. Relationships. Workflows. A way to model content so that it can be reused, maintained, and evolved without everything collapsing under its own weight, grounded in the kind of semantic thinking the web was built on (see [why semantic HTML still matters](https://www.jonoalderson.com/conjecture/why-semantic-html-still-matters/)). ([View Highlight](https://read.readwise.io/read/01knwvdd2mak0f9kx723rfpatb)) - Tags: 👻 ai highlighted - Visual builders. Low-code platforms. Systems where designers can move fast, teams can ship without developers, and the interface feels like the product. **Framer, Webflow, Wix, Squarespace**. Each with its own flavour, but all orbiting the same idea. You don’t need to choose between flexibility and simplicity. You can have both. ([View Highlight](https://read.readwise.io/read/01knwvdd3jfnxdr89stfcfp6r2)) - Tags: 👻 ai highlighted - None of this is obvious at the start. The tools are designed to feel empowering. But they assume a level of simplicity which many organisations outgrow surprisingly quickly. ([View Highlight](https://read.readwise.io/read/01knwvdd4nhkk1jjh00mank6v8)) - Tags: 👻 ai highlighted