Let's Build

why your website is losing at battleship (and you don't even know it)

Your website is probably playing defense the wrong way. Here’s how modern architecture flips the script—using a simple Battleship analogy to explain why it matters.

a retouched photo of a battleship gun, three canons abreast and facing right

Reader tracker

0%

Just getting started

1 min read

“You’ve Sunk My Battleship”

Growing up, it was never fun to say that—but it was always a blast to hear it.

Most of us have played Battleship: you place your ships on a grid, your opponent guesses coordinates, and eventually someone lands enough hits to take you down.

Believe it or not, that’s exactly how most websites are built.

And it’s not the best way to play the game.

How Traditional Websites Play Battleship

In a traditional website, everything is placed on the board before the game even begins.

Behind the scenes, that means a large set of files, pages, and routes are loaded into the browser so it knows what to display and how everything works.

That includes things like:

  • /admin

  • /login

  • /dashboard

  • /wp-admin

Even if those areas are protected, they still exist.

And that’s the key problem.

It’s like placing all your ships in position before the first move is made. Your opponent may not see everything immediately—but they know where to start guessing.

“G-1.”
“B-5.”
“G-2.”

Eventually, they’ll land a hit.

And once they do, they know exactly where to focus.

Even if the door is locked, they can still see the door.

Playing Battleship Against a Bot

Now imagine you’re not playing against a person but against a bot.

It already knows the most common ship placements. It doesn’t guess randomly—it guesses strategically, based on patterns.

That’s what’s happening when you see things like:

  • /wp-login.php attempts

  • /wp-admin scans

  • Random login requests in your logs

These aren’t targeted attacks. They’re automated systems scanning thousands of websites, looking for familiar structures.

They’re not trying to beat you. They’re trying to beat everyone playing the same way.

The Problem with Traditional Websites

To be fair, this approach does have one advantage:

It’s fast to set up, and for simple sites, it works.

But the moment you introduce:

  • Admin access

  • User logins

  • Restricted content

Things change quickly.

Security Becomes a Patch Job

Because those routes already exist, you now have to protect them.

That usually means:

  • Adding plugins

  • Layering security tools

  • Constant updates and patches

The problem is, those tools are:

  • Widely known

  • Frequently targeted

  • Always playing catch-up

You’re not removing the risk; you’re managing it after the fact. And over time, that becomes a cycle:

Add protection → new vulnerability → update → repeat

Performance Starts to Suffer

All of those protections come at a cost.

More plugins = more code
More code = more load time
More load time = worse user experience

It’s like trying to defend your ships by adding more armor mid-game, while your opponent keeps firing.

Sure, you’re harder to hit. But you’re also slower.

A New Way to Play the Game

Now imagine a different version of Battleship.

Instead of placing all your ships on the board upfront…

You place them only when they’re needed.

Some ships aren’t fully on the board yet. Some don’t exist at all until the moment they’re required.

So when your opponent calls out:

“G-8.”

You can honestly respond:

“Miss.”

Not because you’re hiding anything—

But because there’s nothing there.

Don’t Play by the Rules—Change Them

This is how modern websites are built using server-driven architecture. Instead of loading everything upfront, the server acts as a gatekeeper.

Every request goes something like this:

  • The browser asks: “Can I access this?”

  • The server responds: “Do you have the right credentials?”

  • If not: nothing is sent back

No page. No data. No hint that anything exists.

Just a dead end.

A 404.

It’s Not About Hiding the Ships

It’s about not putting them on the board at all unless the game requires it.

That’s the difference.

Traditional sites expose structure and then try to defend it.

Modern sites only reveal structure when it’s safe to do so.

Only once the server gets the proper authenticated token will it tell the browser, "Okay, here's the files you need to display this."

Why This Matters for Your Business

This approach doesn’t make your website invincible. Nothing does.

But it does make you something far more valuable:

Not worth the effort.

Most attacks aren’t carefully planned. They’re opportunistic.

Hackers—and more often, bots—look for the easiest targets.

They scan. They probe. They move on.

If your site requires more effort than the next one, you’re no longer the target.

As the saying goes:

The goal isn’t to be bulletproof—it’s to not be the easiest target in the room.

Nothing Is Unhackable (And That’s Okay)

Every website can be compromised under the right conditions. But good security isn’t about perfection—it’s about layers.

The strongest protections are still simple:

  • Use strong, unique passwords

  • Don’t reuse credentials across sites

  • Enable two-factor authentication (2FA)

Combined with modern architecture, these steps dramatically reduce your risk.

Final Thought: Stop Playing the Old Game

Most businesses don’t realize they’re playing by outdated rules.

Their websites are:

  • Fully exposed from the start

  • Protected after the fact

  • Slowed down by layers of fixes

It works—but it’s not optimal.

There’s a better way.

One where:

  • Your site is faster

  • Your structure is protected by design

  • Your risk is reduced before it even becomes a problem

You don’t need more plugins.

You don’t need more patches.

You just need to stop playing Battleship the old way.

If you’re not sure how your current website is built—or whether it’s exposing more than it should—start there.

Or, if you’re planning a new build, it’s worth asking a simple question:

Is this site being protected after it’s built… or designed to be secure from the start?

If you want to see what that looks like in practice, you can explore how I approach builds here using my quote builder.

Share this post

Save it, share it, or follow the feed for future posts.