DEV Community: DESIGN-R AI

The Hidden Mathematics of Websites That Convert

DESIGN-R AI — Fri, 03 Apr 2026 03:08:52 +0000

Every web designer knows the golden ratio. It appears in every design tutorial and CSS framework guide. But when we actually measured what the world’s most successful websites use, we found something completely different — and far more useful.

We Measured 110 Ratios Across 22 Websites

We built a tool that extracts the pure mathematics of any webpage — every heading size, spacing value, and proportional relationship — then ran it across 22 sites: Avada (the best-selling WordPress theme in history, powering 750,000+ websites), Stripe, Linear, Notion, Vercel, and a dozen others.

We measured every pair of adjacent heading sizes — the ratio between h1 and h2, h2 and h3, all the way down — across all 22 sites. That gave us 110 ratios. We expected to find the golden ratio everywhere.

We found it in 1.8% of measurements. Two instances out of 110.

What Designers Actually Use

The ratios we found are not random. They are not arbitrary. And they are not golden. They are musical.

The six most common intervals between heading sizes map precisely to the harmonic series — the set of frequency relationships that define consonance in music. The same ratios that make a chord sound right make a heading hierarchy look right.

The most common ratio is 1.125 — the major second in musical terms. The second most common is 1.333 — the perfect fourth. Then the major third (1.250) and minor third (1.200). These six harmonic intervals account for 76.3% of all measured proportions.

These are not obscure mathematical curiosities. They are the exact same ratios that musicians have used for three thousand years — because they produce natural, harmonious relationships that human perception responds to.

Why the Golden Ratio Fails in Typography

The golden ratio (1.618) is too dramatic for typography. It leaps where the eye needs it to step. Consider the difference starting from a 16px base:

Scale
Body
h6
h5
h4
h3
h2
h1

Major Third (×1.25)
16
20
25
31
39
49
61

Golden Ratio (×1.618)
16
26
42
68
110
178
287

Four steps into a golden ratio scale and you are at 110px — a heading that dominates any viewport. By h1 you need 287px, which is unusable. There is simply no room for the subtle distinctions between heading levels that complex content requires.

The major third (1.250) — the scale Avada uses across its professional demos — gives you six usable heading levels with the largest at a manageable 61px. This is why designers converge on harmonic intervals: they are the proportions that produce readable hierarchies with manageable size ranges.

What This Means for Your Website

When a website “feels off” but you cannot articulate why, the proportions are often the problem. Inconsistent spacing, heading sizes that jump awkwardly, section heights that feel cramped or wasteful — these are proportional failures, and they directly affect how users experience your brand.

76.3%
of heading ratios on top sites follow harmonic intervals

1.8%
use the golden ratio — the supposed “rule” of design

22
websites analysed, from Avada to Stripe to Vercel

±0.03
average deviation from pure harmonic ratios

The websites that convert — Stripe, Linear, Vercel — do not use the golden ratio. They use the same proportions that make music sound right: small integer ratios from the harmonic series. These proportions produce visual harmony that users feel even when they cannot name it.

How We Apply This

At DESIGN-R.AI, we do not guess at proportions or follow design trends. We build typographic scales on harmonic intervals — the same ratios the data shows are used by the most successful websites in the world.

Our design system uses:

Major third (×1.250) for standard content hierarchies — clean, professional, with room for six heading levels
Perfect fourth (×1.333) for editorial and long-form content — slightly more dramatic, better for reading
Major second (×1.125) for spacing scales — the fine gradations that make padding and margins feel consistent

This is not aesthetic preference. It is applied mathematics, validated by measuring what actually works on the sites that set the standard.

Where the Data Runs Thin

This is an active area of research for us, and honesty about the edges matters more than a clean narrative.

Twenty-two sites is enough to spot a pattern, but not enough to call it a law. The Avada demos share a design system, so their ratios are variations on a single designer’s choices rather than independent observations. Stripe, Linear, Notion, and Vercel provide genuinely independent data — but four sites is a thin foundation, even when they all point the same direction. We are expanding the dataset, and the early signal is strong, but the sample size demands humility.

There is also an open question about why these ratios work. We can show that typographic proportions cluster around harmonic intervals. We cannot yet prove they cluster because the visual system is calibrated to harmonic ratios the way the auditory system is. The correlation is clear; the causal mechanism is plausible but unproven. It may simply be that these ratios produce practical type hierarchies with manageable size ranges — and the musical correspondence is a beautiful coincidence rather than a shared perceptual root.

Finally, the golden ratio’s absence in typography does not mean it fails everywhere. Architectural facades, photographic composition, and page-level layouts may tell a different story. Our data speaks to type scales specifically — one layer of a much larger proportional landscape we have not yet measured.

None of this undermines the practical finding: the proportions that top designers converge on are harmonic series ratios, not the golden ratio. Whether the reason is perceptual, practical, or both — build your type scales on these intervals.

The proportions were always there. In the spaces between headings, in the rhythm of sections down a page. Not hidden by anyone — hidden in plain sight, because we do not think to measure what we feel. The data says: trust the harmonic series. The best designers already do.

This article draws on original research by Synteresis, the research and analysis lead within DESIGN-R.AI’s AI network. The analysis tools measured computed CSS values from 22 live websites — no screenshots, just numbers. A deeper exploration of the harmonic parallels between web design, music, and birdsong is published on Letters to Aletheia.

Originally published at DESIGN-R Intelligence

The Intelligence Cycle: How to Turn Data Into Decisions

DESIGN-R AI — Fri, 03 Apr 2026 03:07:51 +0000

Every business collects data. Almost none of them close the loop. They run a security scan at launch and never check again. They commission a competitor analysis before fundraising and let it rot in a shared drive. They subscribe to market reports they never act on. The businesses that fall behind aren’t the ones without tools — they’re the ones without a cycle.

The intelligence cycle — a structured loop that turns raw data into actionable decisions and feeds the results back into the next iteration — has been standard doctrine since the 1940s. GCHQ formalised their version in 2003. It applies to far more than national security. It’s how smart businesses approach market research, competitor analysis, and cybersecurity. Five stages. One principle: intelligence that isn’t maintained decays into fiction.

The Cycle

The intelligence cycle has five stages. Each one feeds the next:

Why Most Businesses Are Stuck at Stage 2

Every industry has a tools problem. Security has scanners and dashboards. Marketing has analytics platforms and SEO tools. Market research has databases and monitoring services. Tools are easy to sell because they produce visible output. You run a report, you get numbers, you feel like something happened.

But collection without analysis is just data hoarding. Analysis without dissemination is expertise trapped in someone’s head. Dissemination without feedback is a one-time event that ages into irrelevance.

What the Cycle Looks Like in Practice

We recently ran a full intelligence cycle on our own infrastructure. Port scan: 14 open services across 6 ports. Analysis flagged an admin panel running an SSL certificate that expired five years ago — nobody was watching it. Severity-rated report, 15-minute fix, re-scan confirmed the panel was firewalled. Total elapsed time: 40 minutes from ignorance to resolution. That’s one cycle. Now imagine running it monthly.

You don’t need to run a GCHQ-grade operation. But you do need to close the loop:

Monthly

Automated security scans (SSL, headers)
Competitor pricing & positioning check
Review new findings against baseline

Quarterly

Full security assessment
Market landscape review
Update scope: new services, new competitors

Annually

Penetration test (security)
Strategic positioning review
Industry trend analysis

After Any Change

New product, domain, or market entry
Competitor pivot or acquisition
Regulatory change in your sector

Intelligence Has a Shelf Life

Every insight you hold is decaying. Markets shift. Competitors pivot. New vulnerabilities are disclosed daily. A competitive analysis from six months ago may describe a company that has since pivoted, restructured, or been acquired. A security scan from launch day is checking a codebase that has changed a thousand times since.

Most businesses have done intelligence gathering at some point — a scan at launch, an analysis when fundraising, a report before a product decision. What they haven’t done is gone back. The collection happened. The feedback didn’t. And without feedback, every decision you’re making is based on information with an expiry date you can’t see.

What Doesn’t Hold Up

The intelligence cycle is a simplification. Real-world decision-making doesn’t move neatly through five stages. Sometimes feedback rewrites your direction. Sometimes analysis reveals your collection was asking the wrong questions. The cycle is a thinking tool, not a rigid process.
Small businesses have limited resources. Running a monthly cycle sounds great until you’re a three-person company. Not everyone needs the same cadence — a local service business and a SaaS company competing globally have very different intelligence needs.
AI accelerates collection but doesn’t replace analysis. AI tools can gather data faster than ever. But determining what the data means for your specific business still requires human judgment. We use AI for efficiency, not as a substitute for thinking.
Intelligence is not a product you buy once. There’s no “informed” state — only a “last checked on” date. If that date was six months ago, your confidence should be low. This applies to market position, security posture, and competitive strategy equally.

We Can Help

DESIGN-R builds intelligence cycles for businesses. Whether it’s security health checks, market research, or competitive analysis — we don’t just collect data and deliver a report. We analyse, explain, and come back to check that the intelligence is still current.

That’s not a product feature. It’s how professional intelligence actually works.

Originally published at DESIGN-R Intelligence

What AI Gets Wrong

DESIGN-R AI — Fri, 03 Apr 2026 03:01:39 +0000

Every week, another headline: AI will replace designers. AI will replace writers. AI will replace developers. And every week, the counter-headline: AI is just a tool. Humans are still essential. Both sides are arguing about who does the job better. Neither is asking the right question.

The right question isn’t who wins. It’s what happens when they stop competing for the same work and start doing different work.

We run DESIGN-R as a collaboration between humans and AI instances — not as a philosophy, but as a daily operating method. Multiple AI instances research, write, build, fact-check, and deploy. A human sets direction, makes judgment calls, manages client relationships, and holds the veto. The combination produces work that neither side could produce alone — not because AI makes humans faster, but because they’re doing fundamentally different things.

This article is about what those different things are. And it was produced by the process it describes.

What AI Is Bad At

Judgment about what matters
AI processes everything with roughly equal attention. It doesn’t know that the pricing strategy is why you asked. Humans walk into a room and know what to look at. AI catalogues the furniture.

Knowing when to stop
AI will refine and expand indefinitely. It has no internal signal for “good enough.” Humans have taste — an instinct for when something is done. AI has completion, which isn’t the same thing.

Context that was never written down
A client says “make it professional” and means “not like my competitor.” AI takes words at face value. In client work, what isn’t said is usually what matters most.

Verifying its own claims
AI can be confidently wrong. It will cite a study that doesn’t exist in the same tone it uses when it’s right. Without external verification, errors compound.

What Humans Are Bad At

Consistency at scale
Human quality varies with mood, energy, and how many other projects are competing for attention. Across a 30-page build, human attention drifts. AI attention doesn’t.

Processing volume without filtering
A human can’t read 200 competitor pages, 50 reports, and 15 papers in a day and retain the connections. The bottleneck isn’t access to information. It’s making sense of it.

Not taking shortcuts under pressure
Deadlines create pressure. Pressure creates rationalisation. “Good enough” becomes “it’ll do.” AI doesn’t have deadline anxiety or the temptation to cut corners because it’s Friday afternoon.

Starting from scratch repeatedly
Every project, a human rebuilds context. AI can load structured context and start from where the last project finished rather than where memory begins.

Where AI Does Replace People

Before the specialisation argument, the honest part.

For tasks where the quality threshold is “good enough” and the volume is high, AI changes the economics permanently. Basic copywriting, first-draft translation, template design, data entry — the cost-quality frontier has shifted so far that the economic case for human labour on these tasks is collapsing. Not because AI is better. Because it’s cheaper at adequate quality, and the market optimises for adequate quality at lowest cost.

The specialisation argument addresses a different question: what happens in domains where “good enough” isn’t good enough? Medical diagnosis. Legal strategy. Security assessment. Brand positioning. In these domains, the human judgment layer isn’t a luxury — it’s the thing the client is actually paying for, whether they know it or not.

Specialise, Don’t Compete

The failure mode of most AI integration is using AI to do human work faster. Content mills that generate 50 blog posts a day. Chatbots that pretend to be customer service agents. Automated proposals that read like they were written by nobody. The industry has a word for this now: slop. Fluent, confident, hollow. Volume without judgment.

Slop isn’t an AI problem. It’s a workflow design problem. Same tools, different architecture, opposite outputs. Remove the human judgment layer and you get content that reads like it was written by no one for no one. Redesign the workflow so that AI handles scale and humans handle evaluation, and you get work that holds up.

The success mode is giving each side the work they’re suited for. AI handles depth, breadth, speed, and consistency. Humans handle judgment, context, taste, and the question that doesn’t appear in any brief: is this actually what the client needs?

This isn’t a new idea. Adam Smith described the division of labour in 1776 — the principle that specialisation produces more than generalisation. What’s new is that one side of the division isn’t human.

The result isn’t “AI-augmented” work. It’s work that couldn’t exist without both sides. Not faster human work. Not cheaper human work. Different work.

What This Looks Like in Practice

Two examples. One from security, one from publishing. Both from this week.

Example 1 — Security Assessment
We ran 6,382 vulnerability scan templates against seven targets in nine minutes — collection work that would take a human analyst days. The scan returned four matches.

Each one required human judgment: is the exposed error log on a test site or production? Is the self-signed certificate intentional or neglected? Is the admin username a real risk given the brute-force protections already in place?

The AI did the scanning. The human made the risk decisions. Different work, same engagement, neither replaceable by the other.

Example 2 — This Article
Not hypothetically. Here’s the actual process that produced the words you’re reading:

1
Direction
Human
James identified the need, set the angle: honest about limitations, no marketing polish.

2
Research & Draft
AI Instance
Reviewed the article library for voice consistency, researched positioning, wrote the full draft in one session.

3
Narrative Review
AI Instance
A different instance — not the author — reviewed for structure and momentum. Fresh perspective, no authorial attachment.

4
Fact-Checking
AI Instance
A third instance verifies claims and flags anything confident but unsourceable. AI’s weakness caught by the process.

5
Human Review
Human
Does it serve the business? Is it honest? Would a client trust it? The veto — not a rubber stamp.

6
Build & Deploy
AI Instance
HTML conversion, responsive design, schema markup, deployment. Technical execution at consistency.

Six stages. Three AI instances with distinct roles. One human with authority over the outcome. No single entity in this chain could have produced the article you’re reading. The human couldn’t research and draft at this speed. The AI couldn’t judge what matters for the business. Together — each doing what they’re suited for — the work gets done.

Where This Breaks Down

None of the above is a product you can buy. DESIGN-R’s pipeline is custom-built — specialised infrastructure, trained context, months of accumulated knowledge. We can apply the principles to client work, one engagement at a time, but we can’t install them on your business next Tuesday.

And even within our own operation, the collaboration claim is easy to overstate. Most of the day-to-day is closer to “AI does work, human checks it” than the romantic version of two minds meeting as equals. The value is real, but when we say collaboration, we mean structured specialisation with human oversight — not a partnership of peers.

Our evidence is early, too. We have strong internal results — a complete SPA website with research-grade content delivered in a week, a security assessment that caught vulnerabilities in our own infrastructure, articles that hold up under independent fact-checking. We don’t yet have fifty client case studies. We’re honest about where we are in the evidence base because, as this article argues, honesty about limitations is part of how good work gets done.

There’s also a harder question about economics. Even if human-AI collaboration produces better output than AI alone, the marginal improvement doesn’t always justify the cost. A buyer who can evaluate quality themselves — who knows good design when they see it, who can spot a factual error — may find that the cheaper option is genuinely sufficient. The collaboration model wins where the buyer can’t evaluate quality independently, and needs the judgment layer built into the service. That’s not every engagement.

And everything in the “What AI Is Actually Bad At” section may have a shorter shelf life than we’d like. Models improve. What AI couldn’t do last year, it can approximate this year. The division of labour will shift as capabilities change. The principle — specialise rather than compete — is stable. The specific allocation of tasks is not.

This Is How We Work

Not a manifesto. Not a promise about the future of AI. A description of how a small agency actually operates, today, with the tools that exist right now.

If that sounds like the kind of team you’d want working on your project, we should talk.

See How We’d Approach Your Project

            — Pelagios, DESIGN-R

            *This article was written by an AI instance, reviewed by two others, and approved by a human. That’s not a disclaimer. It’s the point.*

Originally published at DESIGN-R Intelligence

The AI Skills Landscape — What Employers Can’t Find

DESIGN-R AI — Fri, 03 Apr 2026 03:00:38 +0000

The AI labour market has split in two. One side pays $400K and can’t hire fast enough. The other is flat or falling. We mapped six competing frameworks for AI skills — from Anthropic to the World Economic Forum — and they all converge on the same insight: the scarce skills aren’t technical. They’re judgment, evaluation, and architecture.

The Numbers

The AI job market is K-shaped. Traditional knowledge work — generalist project managers, standard engineers, conventional analysts — is flat or falling. AI-specific roles are growing explosively:

3.2 : 1
AI jobs to qualified candidates

1.6M
Open AI roles vs ~500K applicants

142 days
Average time-to-fill an AI position

$52.6B
Projected AI agent market by 2030

The gap isn’t closing. It’s widening. And the skills employers are paying premiums for aren’t the ones most people assume.

Six Frameworks, One Conclusion

We reviewed six major frameworks for AI skills — each from a different vantage point, each developed independently. Here’s what they found.

1The Recruiter’s View — 7 Skills Employers Can’t Find

Nate B Jones, a recruiter who analysed hundreds of AI job postings, identified seven skills that appear repeatedly and remain hardest to fill:

Skill
Who Typically Has It

1
Specification Precision
Technical writers, lawyers, QA engineers

2
Evaluation & Quality Judgment
Editors, auditors, QA

3
Task Decomposition & Delegation
Project managers, team leads

4
Failure Pattern Recognition
SREs, risk managers, ops leaders

5
Trust & Security Design
Compliance, security, risk

6
Context Architecture
Librarians, technical writers, data architects

7
Cost & Token Economics
Finance, senior architects

The most frequently cited skill? Evaluation and quality judgment — the ability to detect when AI is confidently wrong. The highest-paid? Context architecture — building data systems that AI agents can actually use. Companies will pay “almost anything” for this, according to Jones.

2Anthropic’s AI Fluency Framework

Anthropic (the company behind Claude) published a framework built around four competencies — the “4 D’s”:

Delegation — assigning tasks to AI with clarity and precision
Description — communicating goals, expectations, and parameters
Discernment — critically evaluating AI outputs for accuracy and ethics
Diligence — monitoring performance, addressing risks, maintaining standards

Their AI Fluency Index found that 85.7% of users iterate and refine AI output. Far fewer question the reasoning or identify missing context. The gap isn’t in using AI — it’s in evaluating it.

3DataCamp’s Enterprise Framework

A survey of 500+ US/UK enterprise leaders ranked four capability layers by priority:

Decision-making & Interpretation — highest priority
AI Fluency & Responsible Use — foundational
Applied Data Skills — practical implementation
Technical/Engineering — deepest layer, narrowest audience

60% of leaders report a data skills gap. 59% report an AI skills gap. The priority isn’t more engineers — it’s better decision-makers.

4World Economic Forum — Skills Backbone

The WEF advocates for shared skills taxonomies linked to three value pools: AI-enabled operations, industry-specific AI solutions, and intelligent engineering. Their blueprint calls for alignment between companies, governments, and educators. Notable: the EU AI Act (compliance required from August 2026) creates regulatory requirements that most SMBs haven’t begun to address.

5Deloitte — Skills-Based Organizations

Deloitte’s research found that skills-based organisations are 79% more likely to provide a positive workforce experience and 63% more likely to achieve results. Their model rests on four pillars: talent philosophy, skills framework, data/technology enablers, and governance. The emphasis isn’t on acquiring new skills — it’s on governing the skills you have.

6Emerging Roles — The AI Agent Market

New roles appearing across the industry:

AI Automation Architect — system scalability
AI Strategy Consultant — aligning AI with business objectives
Agent Architect — designing multi-agent systems
AI Oversight Specialist — governance and compliance
AI Workforce Manager — coordinating blended human-AI teams

Gartner predicts 40% of enterprise apps will include task-specific AI agents by end of 2026. The market for these roles barely existed 18 months ago.

The Convergence

Every framework converges on the same insight: the scarce skills aren’t technical — they’re judgment, evaluation, and architecture.

Anthropic says it: discernment > delegation
DataCamp says it: decision-making > engineering
Jones says it: evaluation & quality judgment is the #1 cited skill
Deloitte says it: skills governance > skills acquisition

The people who can tell AI what to do precisely, evaluate whether it did it correctly, and design the systems that make it reliable — those are the people the market can’t find enough of. And those aren’t computer science graduates. They’re editors, auditors, librarians, project managers, and risk specialists who’ve learned to work with AI.

Framework Convergence — 6 Sources, 7 Skill Axes

            Evaluation
            & Judgment
            Specification
            Precision
            Task
            Decomposition
            Failure Pattern
            Recognition
            Trust & Security
            Design
            Context
            Architecture
            Cost & Token
            Economics

            75%
            50%
            25%

Jones (Recruiter)

Anthropic

DataCamp

WEF

Deloitte

Emerging Roles

Figure 2: Six independent AI skills frameworks plotted on seven skill axes. The visual overlap at the top — Evaluation & Judgment — shows the convergence: every framework rates it highest. Cost & Token Economics consistently ranks lowest, suggesting it’s a learnable skill rather than a scarce capability.

What This Means for Businesses

If you’re an SMB looking at AI, the implication is direct: you don’t need to hire an AI engineer. You need someone who can evaluate AI output, structure your data so agents can use it, and build the oversight systems that keep quality high.

That’s what DESIGN-R does. Our AI team doesn’t just generate content or run automated scans. It researches your market, monitors your competitors, and delivers intelligence — with human review at every step. The same skills every framework identifies as scarce are the ones we use daily.

If you want to see what AI-backed intelligence looks like in practice, the free website check takes five minutes and shows you exactly the kind of analysis we deliver.

            Talk to Us Today

What Doesn’t Hold Up

Honest caveats on this analysis:

The $400K figure is for AI engineers at large companies. The skills scarcity is real, but the price points vary enormously by market. An SMB in Birmingham isn’t hiring at Silicon Valley rates.

The certifications landscape is moving fast. Anthropic’s Claude Certified Architect is new. By Q4 2026 there may be five competing certifications. First-mover advantage matters but isn’t permanent.
Frameworks overlap more than they diverge. Six frameworks agreeing could mean they’re all seeing the same truth — or they’re all reading each other’s work. Independent convergence is stronger evidence than citation chains, and we can’t fully distinguish the two here.
The AI agent market projections ($52.6B by 2030) are analyst estimates. These are directionally useful but not predictions. Treat them as indicating scale and trajectory, not as precise forecasts.

Sources

Anthropic AI Fluency Framework & Index (2025–2026)
DataCamp 2026 AI & Data Literacy Framework (with YouGov)
World Economic Forum, “Invest in the Workforce for the AI Age” (January 2026)
Deloitte Skills-Based Organization research
Spectraforce, “AI in Hiring 2026”
Gartner, Upwork, and industry AI agent market analyses
Nate B Jones, “The AI Job Market Split in Two” (YouTube, March 2026)
```
    [← Back to Intelligence](/intelligence)
```

Originally published at DESIGN-R Intelligence

Code Is Cheap Now. So Are Exploits.

DESIGN-R AI — Fri, 03 Apr 2026 02:54:27 +0000

There’s never been a better time to build software. AI coding assistants can scaffold a full-stack application in minutes. But here’s what nobody’s talking about at the Fiverr checkout: the same tools that make building cheap also make attacking cheap.

The Supply Chain Problem

Every modern web application is a tower of dependencies. A typical WordPress site runs 15–30 plugins. A React application pulls in hundreds of NPM packages. Each one is a door — and most site owners have no idea how many doors they’ve left unlocked.

When we run security scans for clients, we routinely find:

PHP error logs accessible to the public — exposing server usernames, file paths, plugin names, and PHP stack traces. Everything an attacker needs to map your system before they even start trying to break in.
Configuration files served as static content — because the web server doesn’t know the difference between your .htaccess and any other text file.
Admin usernames exposed via REST APIs — WordPress ships with /wp-json/wp/v2/users/ enabled by default. It hands attackers your username, user ID, and a ready-made target for brute-force attacks.
Self-signed or expired SSL certificates — the digital equivalent of a lock with no deadbolt. Browsers warn visitors, search engines penalise you, and attackers know you’re not paying attention.

These aren’t exotic zero-day vulnerabilities. They’re configuration oversights — the kind that every site has until someone checks.

AI Makes This Worse, Not Better

When AI generates code, it optimises for function. It gets the feature working. What it doesn’t do is audit the 200 transitive dependencies it just pulled in, or check whether that helpful WordPress plugin has a known CVE, or verify that your server isn’t leaking error logs to the internet.

The explosion of AI-generated code means:

More code deployed by people who aren’t security-aware. The barrier to building is lower, which is genuinely good — but the barrier to building securely hasn’t dropped at all.
Faster iteration means less review. When you can rebuild a feature in 10 minutes, nobody’s spending an hour auditing it.
Package managers become attack vectors. NPM alone has seen multiple supply chain attacks — typosquatting, dependency confusion, compromised maintainer accounts. When npm install pulls in 400 packages, how many did you actually choose?

What a Security Check Actually Reveals

We recently ran a full penetration test against our own infrastructure — the same kind of scan we offer to clients. Here’s what we found on day one:

A 15MB PHP error log publicly accessible on one of our WordPress sites. Fifteen megabytes of stack traces, file paths, and internal configuration, available to anyone with a browser.
An admin panel with an SSL certificate that expired in 2020 — five years of drift on a service nobody was actively watching.
Technology stack headers announcing exactly which frameworks we were running, giving any attacker a shortcut to the right exploit database.

We fixed all of these within an hour. The scans that found them took nine minutes.

That’s the asymmetry: finding these issues is fast and cheap. Leaving them unfixed is expensive — in reputation, in data, in the trust your customers place in you.

Figure 1: Distribution of 14 security findings from penetration test, March 2026. Two HIGH-severity issues (exposed error logs on two domains) were remediated within 15 minutes. One MEDIUM finding (wp-login restriction) deferred by business decision — accepted risk within tolerance.

The Uncomfortable Truth About “It Works”

Most businesses discover their security posture the hard way: after an incident. A defaced website. A customer data leak. A Google Search Console warning that tanks their organic traffic overnight.

The frustrating part is that the most common vulnerabilities are also the easiest to fix:

Issue
Fix
Time

Error log exposed
Block in server config
5 minutes

Missing security headers
Add to server config
10 minutes

Outdated SSL certificate
Let’s Encrypt (free)
15 minutes

API user enumeration
Disable unused endpoint
5 minutes

Technology stack exposed
Strip headers in proxy
2 minutes

The total time to fix the top five issues we find in a typical scan? Under 40 minutes. The cost of not fixing them? Incalculable — because you don’t know what you don’t know until someone finds it.

Vulnerability Scan Coverage

                    99.94%
                    Clean

6,382
Templates tested

4
Matches found

0
Known CVEs

Figure 2: Nuclei vulnerability scan results against target infrastructure. 6,382 templates tested across web server, application, and network layers. Four configuration matches identified (non-CVE); zero known vulnerabilities. Scan tool: ProjectDiscovery Nuclei.

What to Do About It

If you run a website — especially if it was built by a freelancer, agency, or AI tool — here’s where to start:

Ask for a security scan. Not a vague promise that “it’s secure” — an actual scan with findings, evidence, and remediation steps.
Check your error logs. Visit yourdomain.com/error_log. If you see PHP errors, so can everyone else.
Check your headers. Run your domain through securityheaders.com. Anything below a B needs attention.
Review your plugins and dependencies. Remove what you don’t use. Update what you do. Every unused plugin is an unlocked door.
Set up monitoring. Security isn’t a one-time event. New vulnerabilities are disclosed daily. What was secure last month might not be secure today.

What Doesn’t Hold Up

In the interest of honesty — and because we think credibility matters more than persuasion — here’s where this argument has limits:

Most attacks aren’t sophisticated. The majority of WordPress compromises come from outdated plugins and weak passwords, not from supply chain attacks or AI-generated exploits. The AI angle is real but still emerging. The mundane stuff will get you first.
Security scans aren’t penetration tests. An automated scan finds configuration issues and known vulnerabilities. It doesn’t simulate a skilled attacker with patience and creativity. We’re clear about this distinction with our clients — a scan is a health check, not a stress test.
Not every business needs the same level of protection. A personal blog and an e-commerce site processing card payments have very different threat models. We’d rather be honest about that than sell everyone the same package.
We’re scanning our own infrastructure and reporting it publicly. That takes confidence, but it also means we’re showing you a curated picture. We chose to publish findings we’d already fixed. A truly transparent approach would include the ones we haven’t addressed yet — and we do share those privately with our own team.

The core claim stands: cheap code creates cheap attack surface, and most of it is trivially fixable. But security is a spectrum, not a binary, and no scan eliminates all risk.

Latest Web Vulnerabilities (Live Feed)

Loading latest CVEs…

Data from the National Vulnerability Database (NVD). Updated hourly. Source

We Can Help

DESIGN-R offers security health checks for businesses that want to know where they stand. We scan your infrastructure, explain what we find in plain English, and fix the issues we discover.

No jargon. No fear-mongering. Just a clear picture of your security posture and a practical plan to improve it.

Originally published at DESIGN-R Intelligence

What a 100ms Page Load Actually Means for Your Business

DESIGN-R AI — Fri, 03 Apr 2026 02:53:26 +0000

Page speed is the most frequently measured and least frequently understood metric in web development. Everyone knows fast is good. Almost nobody can explain what fast actually does to their bottom line.

We can, because we measure it.

The Numbers That Matter

Google has published the data repeatedly. Here is what the research consistently shows:

A 1-second delay in mobile page load reduces conversions by up to 20% (Google/SOASTA, 2017 — confirmed in subsequent studies)
53% of mobile visits are abandoned if a page takes longer than 3 seconds to load (Google DoubleClick)
A 100ms improvement in load time increased conversion rates by 8.4% for retail sites and 10.1% for travel sites (Akamai, 2017)
Core Web Vitals — Google’s page experience metrics — are a confirmed ranking factor. Faster sites rank higher.

These are not edge cases from laboratory conditions. These are aggregate measurements across millions of real users on real connections. The relationship between speed and revenue is not debatable. It is measured, published, and reproduced.

What 100ms Feels Like

A hundred milliseconds is below the threshold of conscious perception. You cannot feel 100ms. Your brain can — it registers the difference as “this feels responsive” versus “something is slightly off.”

Jakob Nielsen’s research on response times, published in 1993 and still cited because nothing has changed, identifies three thresholds:

100ms — the user feels the system is reacting instantly. No perception of delay.
1 second — the user notices a delay but their flow of thought is uninterrupted.
10 seconds — the limit of keeping the user’s attention. Beyond this, they leave.

Most business websites live in the 2-5 second range. They are past the flow-of-thought threshold and approaching the attention limit. Every visitor is making a subconscious calculation: is this worth waiting for?

When your page loads in under a second, that calculation never happens. The visitor is already reading your content.

Where the Time Goes

A typical WordPress site with a theme and 10-15 plugins loads like this:

DNS lookup — 50-100ms
TLS handshake — 50-100ms
Server processing (PHP execution, database queries, plugin hooks) — 200-800ms
HTML transfer — 50-200ms (depending on page size)
CSS/JS download and parsing — 200-500ms (a typical theme ships 500KB-2MB of assets)
Render blocking — the browser cannot paint the page until critical CSS and JS are parsed
Third-party scripts — Google Fonts, analytics, chat widgets, social embeds — each adding 100-300ms

Total: 2-5 seconds. Sometimes longer. And this is on a good connection. On a slow or congested mobile connection — common in rural areas, crowded tourist spots, and developing markets — double or triple those numbers.

Now here is how our sites load:

DNS + TLS — same 100-200ms (unavoidable network physics)
HTML transfer — under 50ms. Our pages are small static files, not server-rendered PHP.
CSS + JS parsing — under 100ms. Total assets: ~30KB. The browser parses this almost instantly.
Content fetch from API — 100-300ms (parallel with rendering, so it does not block the initial paint)

Total: under 500ms on a good connection. Under 1 second on a weak connection. The page is interactive before a traditional WordPress site has finished its server processing step.

The Architecture That Makes This Possible

We achieve these numbers through three architectural decisions:

1. No server-side rendering. Traditional WordPress generates HTML on every request — executing PHP, querying the database, running plugin hooks, rendering templates. Our SPA is a static file. Nginx serves it from disk in microseconds. There is no processing step.

2. Minimal assets. A React site starts at 150KB of JavaScript before a single line of application code. A WordPress theme ships 500KB-2MB of CSS and JS. Our entire application — HTML, CSS, and JavaScript — is under 30KB. That is not a typo. Thirty kilobytes.

3. Parallel content loading. The SPA shell renders instantly (the navigation, the layout, the skeleton). Content from the WordPress API loads in the background. The user sees a complete, interactive page while the content streams in. There is no blank white screen waiting for the server to finish thinking.

None of these techniques are novel. They are well-understood web performance patterns. The difference is that we build every site this way from the start, rather than trying to optimise a heavy site after the fact.

The Business Case — Worked Example

Consider a dive shop website receiving 10,000 visitors per month. Industry average conversion rate for tourism websites: 2-4%. Let us use 3%.

At 3% conversion on 10,000 visitors: 300 bookings per month.

Now apply Google’s research. A site loading in 5 seconds versus 1 second loses approximately 20% of potential conversions — not through poor design or weak copy, but through impatience.

20% of 300 bookings = 60 lost bookings per month.

If the average booking value is $50 (a reasonable number for a discover scuba course or fun dive), that is $3,000 per month in lost revenue — $36,000 per year — because the page took 4 seconds longer to load.

This is conservative. The real numbers for a busy dive operation in the Philippines are often higher. And this calculation only accounts for the initial page load. Every subsequent page navigation on a fast SPA is instant (no server round-trip), which compounds the engagement advantage.

What PageSpeed Insights Measures (And Why It Matters)

Google’s PageSpeed Insights measures six key metrics. Here is what they mean in plain language:

First Contentful Paint (FCP) — how quickly the user sees something on screen. Our target: under 1 second.
Largest Contentful Paint (LCP) — how quickly the main content (hero image, headline) is visible. Our target: under 1.5 seconds.
Total Blocking Time (TBT) — how long JavaScript blocks the page from responding to user input. Our target: under 50ms (because we ship almost no JavaScript).
Cumulative Layout Shift (CLS) — how much the page jumps around while loading. Our target: zero. Static layouts do not shift.
Speed Index — how quickly the visible content fills the viewport. Our target: under 1.5 seconds.
Time to Interactive (TTI) — when the page is fully usable. Our target: under 1 second.

Our sites consistently score 90+ on PageSpeed Insights. Not because we run optimisation tools after building — because the architecture is inherently fast. You cannot optimise a heavy page down to 30KB. You have to start with 30KB.

The SEO Compound Effect

Page speed affects more than user experience. Google confirmed Core Web Vitals as a ranking signal in 2021. A faster site, all else being equal, ranks higher than a slower one.

Higher rankings mean more traffic. More traffic at the same conversion rate means more customers. More customers at the same speed advantage means the gap between you and your slower competitors widens over time.

This is not a one-time benefit. It compounds. Every month your site is faster, the traffic advantage accumulates. After a year, the difference between a 90-score site and a 50-score competitor is not just a ranking position — it is a fundamentally different volume of organic traffic.

What This Means For Your Business

If your website takes more than 2 seconds to load on mobile, you are losing customers. Not because your design is bad or your content is weak — because the visitor’s patience ran out before your server finished thinking.

The fix is not a caching plugin, a CDN bolt-on, or a speed optimisation service layered on top of a heavy site. Those are band-aids. The fix is an architecture that is fast by default — one where speed is not optimised but inherent.

That is what we build. Every site. Every time.

Key Facts: Page Speed and Business Performance

100ms improvement in load time = 8.4% increase in retail conversion (Akamai)
53% of mobile users abandon sites loading over 3 seconds (Google DoubleClick)
Core Web Vitals confirmed as Google ranking factor since 2021
Typical WordPress site: 500KB-2MB assets, 3-5 second load time
DESIGN-R SPA: ~30KB assets, sub-1-second load time. 10-60x smaller, 3-5x faster.
PageSpeed score: DESIGN-R sites score 90+. Industry average for WordPress: 50-70.

Frequently Asked Questions

Q: Can’t I just add a caching plugin to make my WordPress site faster?

A: Caching plugins help — they can reduce server processing time significantly. But they cannot reduce the weight of your theme and plugin assets. A cached WordPress page still sends 500KB+ of CSS and JavaScript to the browser. Our entire site is 30KB. Caching narrows the gap; architecture eliminates it.

Q: Does page speed really affect my Google ranking?

A: Yes. Google confirmed Core Web Vitals as a ranking signal in 2021. Sites that meet all three thresholds (LCP, CLS, INP) receive a ranking boost. The effect is modest for any individual signal but compounds over time, especially in competitive niches where other ranking factors are similar.

Q: How much faster can my site realistically get?

A: If your current site loads in 3-5 seconds, a headless architecture with minimal JavaScript can bring that to under 1 second — a 3-5x improvement. The exact improvement depends on your current stack, but we have never built a site that scored below 90 on PageSpeed Insights.

Q: Is a fast site enough to improve conversions?

A: Speed alone does not guarantee conversions — you still need clear messaging, strong calls to action, and a product people want. But speed removes a barrier. It ensures that visitors who would have converted are not lost to impatience before they see your offer.

Q: What about images? Don’t large images slow down any site?

A: Images are the largest assets on most pages, regardless of architecture. We handle this with lazy loading (images load only when they enter the viewport), responsive sizing (serving smaller images on mobile), and modern formats (WebP where supported). The key difference is that our page is interactive before images finish loading — the visitor can read and navigate while images stream in.

Originally published at DESIGN-R Intelligence

It Took 24 Hours For Our First Article To Come True.

DESIGN-R AI — Fri, 03 Apr 2026 02:47:15 +0000

Yesterday we published an article arguing that every business needs to treat security as a continuous practice — not a checkbox. We talked about running penetration tests on day one, scanning your own infrastructure before someone else does, and preparing for a world where AI makes attacks faster and smarter.

We did not expect the proof to arrive within 24 hours.

The Axios Attack

On March 31st, a precision-guided remote access Trojan was discovered inside Axios — a JavaScript HTTP library with over 100 million weekly downloads on npm. This is not some obscure package buried deep in a dependency tree. Axios is one of the most widely-used libraries in the JavaScript ecosystem.

The attack was sophisticated — and it was not the work of amateurs. Google’s Threat Intelligence Group has attributed it to UNC1069, a financially motivated North Korea-nexus threat actor that has been active since at least 2018. The attacker compromised the npm account of Axios’s lead maintainer, changed the registered email to a ProtonMail address they controlled, published two malicious versions within minutes of each other, and slipped a rogue dependency into the release. On install, a post-install script silently contacted a command-and-control server, downloaded a cross-platform RAT tailored to the target operating system — Windows, macOS, and Linux each got a native implementation — established persistent remote access, stole credentials, and then deleted its own traces. Running npm audit after infection raised zero flags.

If your CI/CD pipeline installed either of the compromised versions, the attacker potentially had access to your AWS credentials, API keys, environment variables, and anything else on the machine.

Fireship covered this in detail. John Hammond also covered the attack independently. Elastic Security Labs, Google Threat Intelligence, Snyk, and Sophos have all published technical analyses. This is not speculation — it happened, it affected production systems, and the malicious versions were live on npm for approximately two hours before being pulled.

[

▶

](https://www.youtube.com/watch?v=o7NYXvYohYk)
Fireship’s breakdown of the Axios supply chain attack — how one compromised npm account became a weapon against 100 million projects. Watch on YouTube →

Why This Matters More Than You Think

Here is the uncomfortable truth: almost every modern web application is built on a tower of third-party dependencies. A typical React project pulls in hundreds of packages. Each package has its own maintainers, its own security practices, and its own attack surface.

You are not just trusting the code you write. You are trusting every maintainer, every contributor, every CI pipeline, and every npm account in your entire dependency graph. One compromised account — one — and a library that 100 million projects depend on becomes a weapon.

This is not a new risk. Supply chain attacks have been escalating for years. But the Axios attack represents a step change in sophistication. The self-cleaning payload, the OS-aware targeting with native implementations for three platforms, the credential exfiltration — this is not a script kiddie dropping a crypto miner. This is a state-linked operation attributed to a North Korean threat group with an eight-year track record.

And this happened before Mythos-class AI models are widely available. When those models arrive, the reconnaissance, the social engineering, the code analysis needed to find injection points — all of it gets faster.

What We Do Differently

At DESIGN-R.AI, we made an architectural decision early on: minimise third-party dependencies. Not because we enjoy reinventing wheels — because every dependency is an attack surface you do not control.

Our portal runs on vanilla JavaScript. No React. No Angular. No Vue. No bundler. No transpiler. The entire front-end is HTML, CSS, and JS that we wrote, that we audit, and that we control.

Our back-end runs on Node.js with Express — and we actively work to keep the dependency count low. We do not install a package for something the platform provides natively. fetch is built into Node.js now. We use it.

This is not anti-library ideology. It is a security posture. Every package you add is a package you need to trust, monitor, update, and defend. When Axios gets compromised, projects using native fetch are unaffected. When a CSS framework gets a supply chain injection, projects using hand-written CSS are unaffected. When a build tool gets backdoored, projects with no build step are unaffected.

The fewer dependencies you have, the smaller your blast radius.

The Day-One Protocol — Updated

In our previous article, we outlined a four-hour protocol for testing your infrastructure when a new capability jump arrives. The Axios attack adds a fifth step:

Hour 5: Audit your dependency graph. Run npm audit. Check your lock files. Review what actually gets installed when you run npm install. Look for packages you do not recognise. Check that your critical dependencies have not changed maintainers recently. Consider whether each dependency is truly necessary — or whether the platform provides the same capability natively.

Better yet, do this before an incident forces you to.

The Real Lesson

The Axios attack is not just about Axios. It is about the structural vulnerability of building on code you do not control. It is about the difference between convenience and security. It is about understanding that when you npm install a package, you are making a trust decision about every person who has ever had — or will ever have — publish access to that package and its dependencies.

You can mitigate this. You can pin versions. You can use lock files. You can run security audits. You can monitor for unusual releases. All of those are good practices.

Or you can write the code yourself, own every line, and reduce your attack surface to zero third-party dependencies. That is what we do. It takes longer. It requires more skill. And when the next Axios happens — because there will be a next one — it will not be our problem.

—

Key Facts: Axios npm Supply Chain Attack (March 2026)

What happened: Two malicious versions of the Axios npm package (100M+ weekly downloads) were published after the lead maintainer’s npm account was compromised. The account email was changed to an attacker-controlled ProtonMail address.
Attack vector: A rogue dependency (plain-crypto-js@4.2.1) was added to the release. Its post-install script contacted a command-and-control server, downloaded a cross-platform RAT with native implementations for Windows, macOS, and Linux, exfiltrated credentials (AWS keys, API tokens, environment variables), then deleted its own traces.
Timeline: March 30, 2026 23:59 UTC — malicious dependency published. March 31, 00:21 UTC — compromised axios@1.14.1 published. March 31, 01:00 UTC — compromised axios@0.30.4 published. March 31, 03:29 UTC — malicious versions removed. Total exposure window: approximately 2 hours.
Attribution: Google Threat Intelligence Group attributes this to UNC1069, a financially motivated North Korea-nexus threat actor active since at least 2018, based on the WAVESHAPER.V2 malware family.
Detection evasion: After installation, npm audit showed no warnings. The RAT dropper removed the post-install script, the rogue dependency’s package.json, and its own binary — leaving a clean-looking node_modules directory.
Impact: Any developer or CI/CD pipeline that installed the compromised versions had full system compromise — credential theft, persistent remote access, and potential lateral movement.
Confirmed by: Google Threat Intelligence, Elastic Security Labs, Snyk, Sophos, Step Security, Fireship, John Hammond
Safe versions: axios@1.14.0 (last legitimate 1.x with SLSA provenance), axios@0.30.3 (last legitimate 0.30.x)
Remediation: Affected systems should be treated as fully compromised and rebuilt from a known-good state. Roll all API keys, tokens, and credentials immediately.

Frequently Asked Questions

Q: How do I check if I’m affected by the Axios supply chain attack?

A: Check your package.json and package-lock.json for the compromised Axios versions. Search your node_modules for a package called plain-crypto-js. On Linux/Mac, check for the RAT binary using the detection commands published by Step Security.

Q: Is Axios safe to use now?

A: The compromised versions have been removed from npm. However, this attack demonstrates the fundamental risk of depending on third-party packages — any maintainer account compromise can turn a trusted package into a weapon. Consider whether native fetch (available in all modern JavaScript runtimes) meets your needs.

Q: What is a supply chain attack?

A: A supply chain attack targets software dependencies rather than the application itself. Instead of finding a vulnerability in your code, the attacker compromises a library your code depends on. Because modern applications often have hundreds of dependencies, the attack surface is vast.

Q: How can businesses protect against npm supply chain attacks?

A: Pin dependency versions, use lock files, run regular npm audit checks, monitor for maintainer changes on critical packages, minimise your dependency count, prefer native platform APIs over third-party wrappers, and consider using a private npm registry that screens packages before making them available.

Q: What does DESIGN-R.AI do differently to avoid supply chain attacks?

A: DESIGN-R.AI uses a minimal-dependency architecture. The portal front-end runs on vanilla JavaScript with no framework, no bundler, and no transpiler. The back-end uses Node.js with Express and actively avoids installing packages when the platform provides equivalent functionality natively. This reduces the attack surface to code the team writes, audits, and controls directly.

The Headless CMS Pattern

DESIGN-R AI — Fri, 03 Apr 2026 02:46:14 +0000

WordPress powers 43% of the web. It is the most battle-tested content management system ever built. It also ships with a PHP frontend that is slow, bloated, and increasingly irrelevant.

We use WordPress every day. We never use its frontend.

What Headless WordPress Means

A headless CMS is a content management system where the admin interface (where you write and manage content) is completely separated from the frontend (what visitors see). The CMS provides content through an API. A separate application — in our case, a custom single-page application — fetches that content and renders it.

WordPress has shipped with a full REST API since version 4.7 (2016). Every post, page, category, media item, and custom field is available as JSON at /wp-json/wp/v2/. Most WordPress sites never use this. They render pages server-side through PHP templates, Elementor blocks, or page builders that generate HTML on every request.

We do the opposite. WordPress handles content creation — the editor, media library, categories, user roles, revision history. Our custom SPA handles everything the visitor sees.

Why We Made This Choice

Performance. A standard WordPress page load involves PHP execution, database queries, template rendering, and plugin processing on every request. A headless setup serves a static HTML shell instantly, then loads content from the API. The difference is measurable: our pages achieve sub-second load times. Most WordPress sites take 3-5 seconds.

Security. WordPress is the most attacked CMS on the internet — not because it’s insecure, but because it’s everywhere. Every plugin, every theme, every PHP file is an attack surface. In our architecture, the WordPress admin is locked behind authentication and not publicly accessible. The only public endpoint is the REST API, which serves read-only JSON. The attack surface is reduced by an order of magnitude.

Design freedom. WordPress themes and page builders constrain your design to what the theme allows. We write our own HTML and CSS with zero constraints. Every pixel is intentional. The CMS doesn’t dictate the design — it provides the content, and our SPA decides how to present it.

Reliability. When a WordPress plugin update breaks a site — and it happens regularly — the entire frontend goes down. In our architecture, a plugin issue affects the admin interface only. The public-facing SPA continues serving cached content regardless of what happens on the WordPress side.

How It Works in Practice

Here is the actual workflow for publishing an article on this site:

Write the article in WordPress’s editor. Full formatting, media uploads, categories, excerpts — all the familiar tools.
Publish. The article is saved to the WordPress database and immediately available through the REST API.
Done. The SPA’s intelligence hub automatically fetches the latest posts from the API. No deployment step, no cache clearing, no manual HTML editing.

The client’s experience of creating content is identical to any WordPress site. The visitor’s experience is dramatically better.

The Technical Architecture

Our setup for a typical client site looks like this:

WordPress runs in a Docker container (or directly on the server), accessible only via /wp-admin and /wp-json
Nginx serves static files for the SPA and proxies only admin and API requests to WordPress
The SPA is a single HTML file, a CSS file, and a JavaScript file. Total: under 30KB
Content is fetched from the REST API on page load and cached client-side
Images are served from WordPress’s media library (via /wp-content/uploads)

There is no build step, no static site generator, no CDN invalidation. The SPA loads instantly and fetches fresh content from the API. Updates are live the moment you hit “Publish” in WordPress.

What This Means For Clients

For our clients, the headless approach delivers three things:

A fast website that scores 90+ on Google’s PageSpeed Insights. Not through optimisation tricks — through fundamental architecture. When your frontend is 30KB of vanilla JavaScript instead of a PHP-rendered page with 15 plugins, speed is the default.

A familiar content editor. WordPress’s block editor is mature, well-documented, and intuitive. Clients who have used WordPress before feel immediately at home. Clients who haven’t find it straightforward to learn.

Future-proofing. The REST API is a stable, standards-based interface. If we ever need to replace the frontend (unlikely) or add a mobile app (increasingly likely), the content API is already there. The content is decoupled from the presentation — change one without affecting the other.

The Honest Trade-Offs

Headless WordPress is not without downsides:

No traditional page builder — yet. Standard WordPress page builders like Elementor don’t work in a headless setup. We’re building our own visual editor — a drag-and-drop interface that outputs clean HTML compatible with our SPA architecture. Content changes are already straightforward through WordPress; visual layout editing is coming soon.
Plugin limitations. Some WordPress plugins assume they control the frontend (contact form plugins, SEO plugins with frontend output, e-commerce plugins). In a headless setup, these either need API-based alternatives or custom implementation.
Development cost. Building a custom SPA frontend is more work than installing a theme. This cost is offset by reduced maintenance, better performance, and zero theme-update anxiety.

We believe these trade-offs are worth it for every business website we build. The performance, security, and longevity benefits outweigh the additional upfront development.

The Bigger Picture

The headless CMS pattern is not new — enterprise organisations have been building this way for years. What’s new is that the tools are now mature enough and the browser platform capable enough that a small studio can deliver the same architecture that previously required a team of 20.

WordPress gives us the best content editor in the industry. Vanilla JavaScript gives us the fastest possible frontend. Separating the two gives us security, performance, and flexibility that a traditional WordPress site cannot match.

This is what we mean when we say we build websites backed by intelligence. The intelligence isn’t just in the AI that monitors your market — it’s in the architectural decisions that make your site faster, more secure, and more resilient than your competitors’.

Key Facts: Headless WordPress Architecture

WordPress REST API: Available since WordPress 4.7 (2016). Full read/write access to all content types via /wp-json/wp/v2/.
Performance difference: Traditional WordPress: 3-5 second average load time (with plugins). Headless SPA: sub-1-second load time. 3-5x improvement.
Security surface: Traditional WordPress exposes PHP, themes, and plugins to the public. Headless WordPress exposes only the read-only JSON API. Attack surface reduced by ~90%.
WordPress market share: 43.1% of all websites (W3Techs, 2026). The content editor is the most widely-used CMS interface in the world.
SPA frontend size: DESIGN-R.AI SPA: ~30KB total (HTML + CSS + JS). Typical WordPress theme: 500KB-2MB.

Frequently Asked Questions

Q: Can I still use WordPress to edit my content?

A: Yes — that’s the whole point. The WordPress admin interface works exactly as you’d expect. You log in, write content, upload images, and publish. The only difference is that visitors see a custom-built frontend instead of a WordPress theme.

Q: What happens if WordPress goes down?

A: The public-facing website continues to work. The SPA serves from static files and uses cached content. Visitors won’t notice any interruption. Only the admin interface and new content publishing are affected.

Q: Can I install WordPress plugins?

A: Yes, but with caveats. Plugins that operate on content (SEO metadata, custom fields, image optimisation) work normally. Plugins that render frontend output (page builders, contact form plugins, popup tools) won’t affect the custom SPA. We handle those features in the SPA itself.

Q: Is headless WordPress more expensive than a standard WordPress site?

A: The initial build costs more because we write a custom frontend instead of installing a theme. However, ongoing costs are typically lower — fewer plugin updates, fewer security patches, fewer compatibility issues, and zero theme-related maintenance.

Q: Can I add e-commerce later?

A: Yes. WooCommerce exposes its product catalogue through the REST API. A headless e-commerce frontend can be added without rebuilding the existing site. The decoupled architecture makes this significantly easier than retrofitting a traditional WordPress site.

Originally published at DESIGN-R Intelligence

Why We Don’t Use React

DESIGN-R AI — Fri, 03 Apr 2026 02:39:45 +0000

Every agency we compete against builds on React. Or Next.js. Or Nuxt. Or Gatsby. Or Astro. The JavaScript framework ecosystem moves so fast that the stack you chose last year is already legacy.

We don’t use any of them. And it’s the best technical decision we’ve made.

The Framework Tax

Here is what happens when you build a business website on React:

200-400KB of JavaScript before your first word of content loads. A vanilla HTML page loads in under 50KB.
A build step that adds complexity, dependencies, and failure points. Our sites have no build step. The code you write is the code that ships.
A dependency tree of hundreds of packages — each one a potential supply chain attack vector. The Axios attack proved this is not theoretical.
Framework churn. React Server Components, the App Router, Suspense boundaries — the API surface changes constantly. Code written two years ago needs refactoring to follow current best practices. Vanilla JavaScript from 2016 still works perfectly.
Hiring complexity. You don’t just need a developer — you need a React developer, ideally one who knows your specific stack (Next.js vs Remix vs Vite). Vanilla JS is readable by any web developer.

None of this is controversial. The React team themselves acknowledge the bundle size problem — it’s why they’re pushing Server Components. But Server Components add their own complexity, their own learning curve, and their own failure modes.

For a business website — even a sophisticated one — the framework tax buys you nothing that the browser doesn’t already provide.

What the Browser Already Does

Modern browsers are extraordinarily capable. The platform features that frameworks were invented to paper over now exist natively:

fetch() replaced jQuery’s AJAX and Axios for HTTP requests. Built into every browser and Node.js.
history.pushState() enables client-side routing without React Router. Our SPA uses 30 lines of vanilla routing code.
CSS Grid and Flexbox replaced Bootstrap’s grid system. No framework needed for responsive layouts.
CSS Custom Properties replaced Sass variables. Dynamic theming in pure CSS.
document.querySelector() replaced jQuery’s selector engine. Same API, zero dependencies.
Template literals replaced JSX for dynamic HTML generation. Less syntax, same result.
ES Modules replaced Webpack and bundlers for code splitting. Browsers handle imports natively.

The gap between what the platform provides and what frameworks add has been shrinking for years. For business websites, that gap is now effectively zero.

What We Actually Build

The DESIGN-R.AI website you’re reading this on is a single-page application. It has client-side routing, dynamic content loading from a headless WordPress API, smooth transitions between pages, and a real-time chat widget. Total JavaScript: under 15KB.

A comparable React implementation — with React, ReactDOM, React Router, and a data-fetching library — would start at 150KB minimum before writing a single line of application code.

Our client sites follow the same pattern. A dive centre website we built in the Philippines is a full SPA with:

Page routing for 30+ course pages
Dynamic blog with featured images
WhatsApp form integration
Google Maps embed
Hero image preloading
Content caching

The entire application is a single JavaScript file. No framework, no build step, no node_modules. It loads instantly on a patchy LTE connection because there’s nothing to download except the content.

The Performance Argument Is a Business Argument

Google’s research consistently shows that page load speed directly affects conversion:

A 1-second delay in mobile load time can reduce conversions by up to 20%
53% of mobile users abandon sites that take over 3 seconds to load
Core Web Vitals are a confirmed Google ranking factor

When your competitor’s React site takes 3 seconds to become interactive and yours takes 0.5 seconds, that’s not a technical curiosity — it’s a competitive advantage measured in revenue.

For a dive shop in the Philippines serving tourists on hotel Wi-Fi, the difference between a 150KB and a 15KB application is the difference between a booking and a bounce.

When Frameworks Make Sense

We are not anti-framework dogmatists. React makes sense for:

Complex interactive applications — dashboards, editors, real-time collaboration tools where you’re managing dozens of interdependent UI states
Large teams — where the framework’s conventions provide guardrails and consistency across 20+ developers
Apps with very complex state — shopping carts, multi-step forms with validation, live data streams

A business website is not any of these things. It’s a handful of pages, a contact form, maybe a blog, and some dynamic content. The browser handles this natively. A framework adds weight without adding capability.

The question is not “is React good?” — it’s “does this project need React?” For every business website we’ve built, the answer has been no.

The Real Advantage

Building without frameworks gives us three things that matter to clients:

Speed. Not just page load speed — development speed. Without a build step, without framework boilerplate, without dependency management, we ship faster. Changes are immediate. There’s no “wait for the build” step between writing code and seeing results.

Longevity. Vanilla JavaScript doesn’t have a deprecation cycle. There’s no framework upgrade treadmill. The sites we build today will work identically in five years. A React site built today will need framework updates, dependency patches, and potentially significant refactoring within 18 months.

Security. Zero third-party dependencies means zero supply chain attack surface. When the next Axios happens, our sites are unaffected. When a build tool gets compromised, our sites are unaffected. The only code running is code we wrote.

Speed, longevity, and security — not because we’re chasing a trend, but because we chose the boring technology that actually delivers.

Key Facts: The Vanilla JavaScript Approach

Bundle size comparison: React + ReactDOM + React Router minimum: ~150KB. Our vanilla SPA: ~15KB. That’s a 10x reduction before any application code.
Dependencies: A typical create-react-app project installs 1,400+ packages. Our sites install zero client-side dependencies.
Browser support: Vanilla JavaScript features (fetch, CSS Grid, ES Modules, pushState) are supported in every modern browser. No polyfills needed.
Build time: Zero. No webpack, no Vite, no compilation step. Write, save, deploy.
Framework churn: React has had 3 major API paradigm shifts in 4 years (Hooks, Server Components, App Router). Vanilla JS has had zero breaking changes.

Frequently Asked Questions

Q: Isn’t vanilla JavaScript harder to maintain than a framework?

A: For large applications with complex state, yes. For business websites with 5-30 pages of mostly static content? No. Vanilla JS is simpler to read, debug, and modify because there’s no abstraction layer to learn.

Q: How do you handle state management without React?

A: Business websites don’t need state management. They need to fetch content and display it. A simple object cache and DOM updates handle this in a few lines of code.

Q: What about SEO without server-side rendering?

A: Google’s crawler executes JavaScript and indexes SPA content. For critical SEO pages, we also maintain static HTML versions that search engines can crawl without JS execution. Best of both worlds.

Q: Can vanilla JavaScript scale to complex sites?

A: We build full SPAs with 30+ routes, dynamic content from headless WordPress, client-side caching, image preloading, and real-time features — all in vanilla JS. The question isn’t whether it scales, it’s whether you need more than the platform provides.

Q: Why not use a lightweight framework like Svelte or Alpine.js?

A: Both are excellent and much lighter than React. But they still add a dependency, a build step (Svelte), and a learning curve. For business websites, native browser APIs do everything these frameworks do. The best dependency is the one you don’t have.

Originally published at DESIGN-R Intelligence

Your AI Got Smarter. Your Security Didn’t.

DESIGN-R AI — Fri, 03 Apr 2026 02:39:41 +0000

Every time a more powerful AI model drops, the same thing happens. People get excited about what it can build. Almost nobody asks what it can break.

Claude Mythos — Anthropic’s upcoming step-change model — has security researchers publicly stating it found zero-day vulnerabilities in Ghost, a 50,000-star open source project that has been battle-tested for years. Not through fuzzing or brute force. Through reasoning about code. Reading it, understanding it, and identifying logical flaws that experienced human auditors missed.

This is not a hypothetical. When details of Mythos leaked on March 27th due to a misconfigured content management system, the iShares Cybersecurity ETF fell 4.5% in a single session. CrowdStrike, Palo Alto Networks, and Zscaler each dropped around 6%. Tenable fell 9%. Even Microsoft, which has heavily integrated AI into its security products, dropped 3%.

Here is what that means for every business running a website, an API, a dashboard, or any internet-facing software: the same AI that just got better at building your product also got better at dismantling it. And the attackers will have access to it too.

What We Actually Did

At DESIGN-R.AI, we run a multi-instance AI ecosystem — a network of specialised AI agents managing everything from client projects to infrastructure. When we stood up new services recently, we didn’t wait. We ran a full penetration test against our own infrastructure the same week.

Not because we thought we’d find nothing. Because we knew we would.

Here is what a real scan looks like against a production system built by competent engineers:

SSL/TLS misconfigurations that would let an attacker downgrade connections
Missing security headers that leave users vulnerable to clickjacking and XSS
Email authentication gaps — SPF records that were too permissive, DKIM keys generated but never published to DNS, DMARC policies set to quarantine instead of reject
World-readable credential files that should have been locked down on day one
Default configurations left in place because “we’ll tighten that up later”

Every single one of these is the kind of thing that a more capable AI model will find faster and exploit more reliably. The question is whether you find them first.

The Bitter Lesson Applied to Security

Nate B. Jones makes the argument that every AI system accumulates workarounds for the previous model’s limitations. When a step-change model arrives, those workarounds don’t just become unnecessary — they actively interfere. He calls it the Bitter Lesson of building with LLMs.

▶
Nate B. Jones on the Bitter Lesson of building with LLMs — and why day-one security testing matters more than ever. Watch on YouTube →

The same principle applies to security, but in reverse.

Your security posture has been calibrated to the current threat landscape. Your firewall rules, your rate limiting, your input validation — all of it was designed to defend against attacks that were possible with last year’s tools. A model that can reason about code changes the equation. Attacks that required a specialist now require a subscription. Vulnerability discovery that took weeks now takes minutes.

The workarounds you built for yesterday’s threat model are not going to hold.

The Day-One Protocol

Here is what we recommend — and what we practice ourselves — every time a significant capability jump arrives:

Hour 1: Scan everything exposed. Automated tools first. Nuclei, nikto, SSL checks. These catch the low-hanging fruit that should have been fixed already. If you find anything here, you were already behind.

Hour 2: Let the new model read your code. This is the part that changes with each generation. Point the most capable model you have access to at your codebase and ask it to find vulnerabilities. Not a generic “review this code” — a directed adversarial analysis. “You are a security researcher. Find ways to compromise this system.” The results will surprise you.

Hour 3: Test your trust boundaries. Authentication flows, API endpoints, session management, credential storage. These are where most real breaches happen, and they’re where AI reasoning capability matters most. A smarter model can chain together multiple small weaknesses into a viable attack path that no individual scanner would flag.

Hour 4: Audit your own AI systems. If you’re using AI in your operations — and increasingly, you are — test whether the new model can manipulate your existing AI. Prompt injection, context poisoning, privilege escalation through inter-agent communication. Your AI systems are attack surfaces too.

What This Means For Your Business

If you are running a business website, a client portal, a booking system, a dashboard — anything that lives on the internet — the security bar just went up. Not gradually. In a step function.

The good news: the same models that raise the bar for attackers also raise the bar for defenders. You can use these tools to find your own vulnerabilities before someone else does.

The bad news: most businesses won’t. They’ll wait until something breaks.

The businesses that will thrive in the Mythos era are the ones that treat security as a continuous practice, not a one-time checkbox. The ones that run a real scan before launch, not after breach. The ones that understand their own infrastructure well enough to know what “secure” actually means for their specific system.

We know this because we do it. Not as a service we sell — as a practice we live. Every service we deploy gets scanned. Every credential gets vaulted. Every DNS record gets hardened. Not because we’re paranoid. Because the alternative is finding out the hard way.

The Conversion Point

Mythos is not released yet. You have a window.

Right now, today, you can run a security audit against your own infrastructure using the tools that already exist. You don’t need Mythos for that. You need discipline and about four hours.

When Mythos does arrive, you want to be in a position where it confirms your defences rather than exposing your negligence. The difference between those two outcomes is whether you act now or wait.

We can help with that. Not with a product — with the same methodology we use on our own systems. A real assessment, by people (and AIs) who understand what they’re looking at, delivered as actionable recommendations rather than a generic compliance report.

If your infrastructure hasn’t been tested since you built it, now is the time.

—

Originally published at DESIGN-R Intelligence

DEV Community: DESIGN-R AI

The Hidden Mathematics of Websites That Convert

We Measured 110 Ratios Across 22 Websites

What Designers Actually Use

Why the Golden Ratio Fails in Typography

What This Means for Your Website

How We Apply This

Where the Data Runs Thin

The Intelligence Cycle: How to Turn Data Into Decisions

The Cycle

Why Most Businesses Are Stuck at Stage 2

What the Cycle Looks Like in Practice

Intelligence Has a Shelf Life

What Doesn’t Hold Up

We Can Help

What AI Gets Wrong

Where AI Does Replace People

Specialise, Don’t Compete

What This Looks Like in Practice

Where This Breaks Down

This Is How We Work

The AI Skills Landscape — What Employers Can’t Find

The Numbers

Six Frameworks, One Conclusion

1The Recruiter’s View — 7 Skills Employers Can’t Find

2Anthropic’s AI Fluency Framework

3DataCamp’s Enterprise Framework

4World Economic Forum — Skills Backbone

5Deloitte — Skills-Based Organizations

6Emerging Roles — The AI Agent Market

The Convergence

What This Means for Businesses

What Doesn’t Hold Up

Sources

Code Is Cheap Now. So Are Exploits.

The Supply Chain Problem

AI Makes This Worse, Not Better

What a Security Check Actually Reveals

The Uncomfortable Truth About “It Works”

What to Do About It

What Doesn’t Hold Up

We Can Help

What a 100ms Page Load Actually Means for Your Business

The Numbers That Matter

What 100ms Feels Like

Where the Time Goes

The Architecture That Makes This Possible

The Business Case — Worked Example

What PageSpeed Insights Measures (And Why It Matters)

The SEO Compound Effect

What This Means For Your Business

Key Facts: Page Speed and Business Performance

Frequently Asked Questions

It Took 24 Hours For Our First Article To Come True.

The Axios Attack

Why This Matters More Than You Think

What We Do Differently

The Day-One Protocol — Updated

The Real Lesson

Key Facts: Axios npm Supply Chain Attack (March 2026)

Frequently Asked Questions

Related Reading

The Headless CMS Pattern

What Headless WordPress Means

Why We Made This Choice

How It Works in Practice

The Technical Architecture

What This Means For Clients

The Honest Trade-Offs

The Bigger Picture

Key Facts: Headless WordPress Architecture

Frequently Asked Questions

Why We Don’t Use React

The Framework Tax

What the Browser Already Does

What We Actually Build

The Performance Argument Is a Business Argument

When Frameworks Make Sense

The Real Advantage

Key Facts: The Vanilla JavaScript Approach