Yes, I Have 100. But It's Just Text, Right?

Here is the report. Mobile, not desktop.

100 in Performance. 100 in Accessibility. 100 in Best Practices. 100 in SEO.

I already know the reply, because I have heard it every time.

"Sure, but your site barely has any images."

Correct.

"It is mostly text."

Also correct.

"There is almost no CSS."

There is exactly as much as it needs.

"And your blog does not update several times a day."

It does not.

"You do not even have complex integrations."

None at all.

Exactly. That is the point.

Read that list again

Every one of those objections is supposed to be the catch. The asterisk that makes the score not count.

But stop reading it as a list of things my site lacks, and read it as what it actually is: a list of things my site does not need.

Few images, because the work I am selling is not visual.

Mostly text, because the people who hire me read before they call.

Little CSS, because the design has nine sections and none of them animates.

A blog that updates when I have something worth publishing, because I am not running a content operation.

No integrations, because nothing here needs to talk to anything else.

That is not a site that got a good score despite being simple. It is a site that is simple because that is what its job required, and the score is what happens afterwards.

The 100 is not an achievement. It is a consequence.

Web development starts with a question, and it is not "which framework"

It starts with: what is this site for?

Everything else is downstream of that answer. The stack. The copy. The images. The layout. The hosting. The build pipeline, and whether there needs to be a build pipeline at all.

A site whose job is to publish an article every few weeks, link to a handful of profiles, and convince a stranger that I know what I am doing has a very specific set of requirements. Once you write those requirements down honestly, most of the decisions make themselves.

The problem is that almost nobody writes them down.

The usual mistake is a good answer to a question nobody asked

Bad architecture rarely comes from bad answers. It comes from answering the wrong question, competently.

What would be impressive?

What did the last project use?

What does this framework's documentation assume I am building?

What will still look current in two years?

What is easiest to sell to the client as "modern"?

Every one of those produces a defensible decision. You can write a convincing paragraph justifying any of them. Not one of them starts from the client, and that is the only place the answer could have come from.

Complexity is not a one-time decision

This is the part that gets left out of the pitch, because it does not show up in the quote.

Every dependency is a standing obligation. Something that can break while you sleep, on an update you did not initiate and did not ask for. A surface that somebody has to watch, and if nobody is watching it, the site is not "low maintenance": it is unmaintained. I have written elsewhere about what that watching is actually worth, and about the weaknesses that never even make it into a database.

For a site whose purpose is to publish a few articles a year, that ongoing cost buys nothing the purpose required.

You did not save the client anything by giving them a CMS with eleven plugins. You handed them a subscription to a problem.

Sometimes complexity is the right answer

This is not an argument that everyone should hand-write HTML and feel superior about it.

A marketing agency publishing forty campaigns a month, with a team of editors who are not developers, running A/B tests, personalizing content and pushing leads into a CRM, has business rules that genuinely justify machinery. There, the machinery pays for itself. Refusing it would be the same mistake in the opposite direction: a decision made from the developer's preference instead of the client's situation.

The error is not choosing complexity. The error is treating the choice as permanent.

One of the inputs just changed

For twenty years, the strongest argument for heavy abstraction was labor. Writing code by hand was slow and expensive, so you bought a framework or a CMS to avoid writing it. That trade was real, and for a long time it was correct.

That input has changed. Producing and modifying code is now close to trivial compared to what it cost a few years ago.

Which means "it's hardcoded" has stopped being a self-evident objection. It was never really about the HTML. It was shorthand for "expensive to change", and that is no longer automatic.

It is not free either, and I am not going to pretend otherwise: a static site still needs an answer to how does the client change their own phone number. But that is one requirement to solve, not a reason to adopt an entire platform.

Development is not moving in giant strides any more

It is moving in agentic ones. Same distance, different legs.

And that quietly kills the argument that built half the web.

The old fear was reasonable. Hand a site to the next developer, or to yourself eighteen months from now, and they open a folder full of markup they have to understand before they can change a single word. That fear is the actual selling point of most platforms. Not the features. The promise that nobody will ever have to look inside.

What you bought instead was a drag-and-drop panel with a tooltip that says increase this to raise your margin.

It is a beautiful promise. It is not a strategy.

Today, "there is code in here" is close to the least frightening thing you can find in a project. Your next developer can read it. You, with an assistant open, can read it. Changing a phone number, a section, a whole layout is no longer gated behind knowing the platform's particular way of doing things. The code stopped being the wall.

So the maintenance question, what will the next person be able to handle, stops being the one that decides the stack. Which leaves the only question that ever mattered: what does this site have to achieve?

What agencies should be selling

If writing code is no longer the expensive part, then choosing the technology is no longer the valuable part either.

What is left is the work that was always the hard one: the experience of the person using the site, and whether anybody finds it at all.

That is where an agency earns its fee. An integrated positioning strategy: who you are trying to reach, what they are actually searching for, what they find today instead of you, and what this site has to be in order to be the thing they were looking for. None of that gets cheaper when code gets cheaper. It gets more valuable, because everything around it just became commodity.

An agency married to a single stack is running the process backwards: it starts from the answer and then looks for a client whose question fits.

The rule

Use the technology that suits the client.

Not the one that suits your resume, your habits, or your agency's default stack. Not the one that makes the proposal sound more expensive.

And this is the part that is easy to miss: what suits the client ends up suiting you too. A site built for what it actually does is cheaper to run, breaks less, survives longer, and keeps working after the engagement ends. That is the project that still exists in three years, and the client who comes back.

Fitting the solution to the purpose is not modesty. It is the version with the best odds of succeeding.

So, yes

I have 100.

And yes: it is mostly text, with few images, almost no CSS, a blog I update when I have something to say, and no integrations whatsoever.

Thank you for noticing.

That was the design.