What Twenty Years of Building Websites Taught Us About Making Fewer.

We’ve launched more sites than we can count. Somewhere around year ten, we started to notice a pattern. The ones we’re proudest of aren’t the biggest, the flashiest, or the ones we won awards for. They’re the ones where we said “no” more often than we said “yes.”

That took us a while to figure out.

The early years

When we started Period Three in 2003, we said yes to everything. Yes to the five-page site for the local realtor. Yes to the e-commerce rebuild with the custom shopping cart we had to invent from scratch. Yes to the client who wanted a Flash intro, a splash page, and a hit counter in the footer. Yes to the deadline we knew we couldn’t hit. Yes to the scope that doubled halfway through. Yes to the brief that read like a stream of consciousness and ended with “and make it pop.”

For a long time, saying yes felt like the whole job. We were a studio. People came to us with ideas and we built them. That was the deal.

But a strange thing happened as we got better at building. The more capable we got, the harder it was to be useful.

The problem with capability

Here’s the trap. If you can build anything, every brief looks buildable. Every feature request has a path. Every “wouldn’t it be cool if” has an answer that starts with “yeah, we could.” Twenty years in, there is almost nothing a client could ask for that we couldn’t technically ship.

The client doesn’t need a shop that can tell they are a letterpress shop. They need customers to understand what they make and why it costs what it costs. The nonprofit doesn’t need a donor portal with seventeen giving tiers. They need people to care enough to click donate once.

The gap between what someone asks for and what they actually need is where the real work lives. Twenty years of building taught us that most of the time, the right answer is less. Less navigation. Less copy. Fewer features. One clear next step instead of six.

Saying yes to all of it is the easy move. The hard move is figuring out what to cut.

What we started saying no to

Over the years, the list of things we won’t do grew. Not out of laziness or snobbery. Out of experience. Here’s a partial inventory.

We stopped saying yes to projects without discovery. Discovery used to be optional for us. A nice-to-have for bigger engagements. Now it’s non-negotiable. If a client doesn’t want to spend the time to figure out what the site is actually for, we don’t want to spend ours building the wrong thing. (We wrote about this separately. If you missed it, read “The Discovery Phase Is Not Optional” next.)

We stopped saying yes to feature creep in the middle of a build. Not because clients are being unreasonable when they want to add things. They’re not. They’re just discovering, mid-build, what they actually wanted all along. That’s healthy. But adding it to the current build is almost always wrong. Phase two is a feature, not a failure.

We stopped saying yes to “we’ll figure out the content later.” Content is the site. Everything else is a container for it. We’ve seen enough gorgeous shells get launched with placeholder copy to know what happens next: nothing. It just sits there. If a client doesn’t have the content and can’t commit to writing it, we need to be in that conversation from day one, not day sixty.

We stopped saying yes to redesigns with no theory of change. “Our site looks dated” is a feeling, not a project. If the only thing driving the work is that it’s been a few years, the new one will look dated in a few years too. We ask what’s actually broken. Sometimes it’s the design. More often it’s the content, the structure, the way the business has outgrown the thing. We’d rather fix the right problem than redesign the wrong one.

We stopped saying yes to projects where we’d be the only ones who care. This is the quietest one on the list. If the client doesn’t have a champion internally. If there’s no one who will fight for the thing after we hand it off. If the whole project exists because someone at the top said “we need a new website” and nobody downstream agrees. That site is going to launch and die. We can tell within the first three meetings. We say no now.

The math of less

Here’s the thing nobody tells you about doing less. It’s harder than doing more. It’s a slower sell. It’s a longer conversation. Clients hire you because they want more, not fewer, and the first few meetings of “actually, let’s take some of this off the table” can feel like you’re arguing against your own interests.

But the math works. A site with eight pages that people actually read is worth more than a site with forty pages that nobody reads. A homepage with one clear path is worth more than a homepage with six. A navigation with five items is worth more than one with twelve. Less content is harder to write, which is why most sites don’t do it, which is why doing it is a competitive advantage.

We don’t always win this argument. Plenty of clients still want the sprawling thing with every bell and whistle. That’s fine. They can hire somebody else. But the clients who hire us because of this philosophy are the ones who stick around. They’re the ones whose sites are still working five, ten, fifteen years later. They’re the ones who come back for the next thing, because the first thing actually delivered.

What this means for how we work now

These days, our first job on any project is to figure out what the project should be about. Not what the client said in the RFP. Not what the deck said. What the project is actually trying to do, underneath all the wrapping.

Sometimes that means we build what they asked for. Sometimes it means we build something smaller. Sometimes it means we tell them, kindly, that they don’t need the thing they thought they needed, and here’s what we’d suggest instead. Sometimes they take that advice. Sometimes they don’t. Sometimes we lose the project because of it.

Twenty plus years in, we’re done building sites nobody uses. We’d rather build fewer things that work than more things that don’t.