The Website Isn't the Hard Part

The code took two days. The content took two weeks.

That ratio surprises people every time I mention it, because when someone hires a developer, they assume the code is the expensive, slow part and the words are just something you fill in on day one over coffee. In practice, for most of the projects I’ve built, it’s almost exactly backward.

Building the wrong thing quickly is not a win

I could have written generic copy for that homepage in an afternoon. “We help businesses grow.” “Quality service you can trust.” Words that mean nothing because they could sit on literally any competitor’s site, in any industry, with zero edits.

That’s not a website problem. It’s a clarity problem, and no amount of good code fixes it.

A fast, beautifully built site full of vague copy converts worse than a plain site that says something true and specific. I’d rather ship something unpolished that’s honest about who it’s for than something gorgeous that says nothing.

Where the two weeks actually went

Most of that time wasn’t spent typing. It was spent figuring out:

• Who the actual buyer is, specifically, not “small businesses” but the exact owner, in the exact situation, who’s actually going to read this page
• What they’re worried about before they’ll trust a stranger with their business or their money
• What makes this offer different from the five other options they’re comparing it against
• What proof actually moves someone from “interested” to “ready to book a call”

Those aren’t code problems. They’re research and positioning problems, and they don’t get solved by writing faster. They get solved by asking better questions before you write a single sentence of homepage copy.

The build is the easy part now. Anyone with the right tools can ship a site in days. The part that still takes real work is knowing exactly what that site needs to say, and to whom.

Why this matters more, not less, now that builds are fast

Here’s the part that’s counterintuitive: as AI makes the technical build faster, the strategy work becomes the entire bottleneck, not a smaller piece of the project. When the code took six weeks, the content work happening in parallel didn’t feel like the critical path. Now that the code takes two days, the content is very obviously the critical path, because everything else is waiting on it.

If you’re thinking about a new website and assuming the build is the expensive part, it’s worth reconsidering where the real work, and the real value, actually lives. That’s usually where I start every project, and it’s the conversation worth having before anyone touches a line of code.