Skip to main content

Your Website Doesn’t Need 500 Features. It Needs 15 That Work Well.

July 13, 2026 Highland Software

“Just because you can, doesn’t mean you should.”

One of the hardest lessons I’ve learned over the years has nothing to do with WordPress.

It has everything to do with restraint.

As developers, we’re surrounded by incredible tools. Themes with hundreds of customization options. Page builders capable of creating almost any layout imaginable. Plugins that promise to solve every conceivable problem with a few clicks.

It’s tempting to use them.

After all, they’re available.

But one of the most important questions I ask before adding any feature to a project is surprisingly simple:

Does this website actually need it?

That’s a very different question from:

Can this software do it?

Those two questions often lead to completely different solutions.


The 10/90 Problem

Over the years I’ve noticed a pattern.

Most business websites use roughly the same collection of content:

  • A homepage
  • About page
  • Services
  • Team
  • Testimonials
  • Contact form
  • Blog
  • A few calls to action

Yet many are built using page builders and themes that include hundreds of widgets, templates, animations, effects, layout controls, and design options.

The irony?

Most websites use perhaps ten percent of those features.

The remaining ninety percent quietly sits there, increasing complexity without adding any real value.

I call this the 10/90 problem.

We install software capable of doing almost everything…

…to build a website that only needs a handful of things.


Every Feature Has a Cost

One of the biggest misconceptions in software development is that unused functionality is somehow free.

It isn’t.

Every feature carries a cost.

More CSS.

More JavaScript.

More PHP.

More database queries.

More documentation.

More testing.

More maintenance.

More updates.

More opportunities for conflicts.

Even if a visitor never clicks a feature, the software still needs to support it. Developers need to understand it. Administrators need to navigate around it. Future updates need to avoid breaking it.

Complexity doesn’t disappear simply because a feature isn’t used.


General-Purpose Software Isn’t the Problem

Before anyone thinks this is an attack on page builders or commercial themes…

It isn’t.

General-purpose software exists for a reason.

If you’re an agency building dozens of websites every year, flexibility matters.

If your marketing team creates new landing pages every week, a page builder can save an enormous amount of time.

If your business depends on constantly experimenting with layouts and content, having hundreds of options is valuable.

Sometimes flexibility is exactly what a project needs.

The problem isn’t the tool.

The problem is using a general-purpose solution when the problem itself is highly specific.


Not Every Problem Is a Nail

There’s an old saying:

When all you have is a hammer, everything looks like a nail.

I think modern web development sometimes falls into a different trap.

We discover an incredibly powerful tool and start using it to solve every problem simply because it’s familiar.

Sometimes that’s exactly the right decision.

Sometimes it isn’t.

A marketing agency creating dozens of unique landing pages?

A page builder is probably the right hammer.

A ten-page corporate website that changes twice a year?

Maybe not.

Good engineering isn’t about refusing to use powerful tools.

It’s about recognizing when they solve the problem—and when they simply introduce complexity you never asked for.

Not every problem is a nail.

But sometimes you absolutely do need a hammer.

The skill lies in knowing the difference.


Build Around Requirements, Not Possibilities

This is probably the biggest shift in my thinking over the years.

I no longer begin projects by asking:

“What can this software do?”

Instead I ask:

“What does this organization actually need?”

If the answer is:

  • A hero section
  • Services
  • Team members
  • Testimonials
  • Blog posts
  • Contact forms

Then that’s what I build.

Nothing more.

Nothing less.

No sliders because they’re fashionable.

No animation libraries because they look impressive.

No fifty different layout options that nobody will ever use.

Every component should exist because it solves a real business requirement.

Not because the framework happened to include it.

Software should be designed around requirements

…not possibilities.


Simplicity Benefits Everyone

This isn’t just about performance.

It’s about people.

One of the most common complaints I hear from content editors is that they’re overwhelmed.

Hundreds of widgets.

Endless styling options.

Padding controls.

Margin controls.

Responsive settings.

Global settings.

Animation settings.

Typography settings.

The flexibility is impressive.

But flexibility isn’t always the same thing as usability.

Most organizations don’t want unlimited creative freedom.

They want to update their website without worrying they’re about to break it.

By reducing unnecessary options, we often make software easier to learn, easier to maintain, and far less intimidating for the people who use it every day.


Engineering Is About Making Choices

One of my favourite sayings is:

Just because you can, doesn’t mean you should.

Good software isn’t measured by how many features it includes.

It’s measured by how well it solves the problem it was built to solve.

Every feature should earn its place.

Every dependency should have a purpose.

Every plugin should solve a problem that actually exists.

That’s true whether you’re choosing a framework, installing a plugin, or writing custom code.

The best engineering decisions are rarely about using the most powerful tool.

They’re about using the right one.


Final Thoughts

I’m not against page builders.

I’m not against commercial themes.

I’m certainly not against powerful development tools.

I use them when they’re the right solution.

But I’ve learned that software becomes better when it’s built intentionally.

Cleaner code.

Fewer dependencies.

Simpler maintenance.

Better accessibility.

Improved performance.

A better experience for content editors.

A better experience for visitors.

In the end, your website probably doesn’t need 500 features.

It needs 15 that work exceptionally well.

And that’s often enough.

Highland Principle #3: Build around requirements, not possibilities.

More From Highland Software