Spoiler. It’s not the technology.
We’ve been building websites since 2000. In that time, we’ve seen technologies come and go and worked with businesses of every size. A lot has changed. But some things, the things that actually determine whether a web project succeeds or fails have stayed remarkably consistent.
Here’s what 26 years of building websites has taught us.
The spec is never the spec
Every project starts with a brief. Sometimes it’s a detailed document, sometimes it’s a conversation, occasionally it’s a single sentence email at 11pm. But whatever form it takes, the brief is always a starting point, never the destination.
This isn’t because clients don’t know what they want. It’s because websites are abstract until they’re real. People discover what they actually need when they start seeing screens, clicking buttons, and imagining their customers doing the same. The best projects have room for this discovery built in. The worst ones treat the original spec as sacred text and resist every deviation.
We learned early on that flexibility isn’t scope creep, it’s how good work happens. The trick is distinguishing between changes that make the project better and changes that just make it different.
The problem behind the problem
A client says they need a new website. But why? Sometimes the answer is obvious, e.g. their current site is outdated, broken, or embarrassing. But often there’s something else going on. Sales have dropped. A competitor looks more professional. The business has evolved and the website hasn’t kept up. A new marketing manager wants to make their mark.
Understanding the real driver changes everything. It impacts what you build, how you prioritise, and how you’ll measure success. A website that’s technically excellent but doesn’t address the underlying business problem is still a failure.
These days we spend more time on discovery than we used to. Not because we’re slower, but because we’ve learned that an hour asking the right questions saves weeks building the wrong thing.
Content is almost always the bottleneck
In 26 years, we’ve never seen a web project delayed by code. Not once. It’s virtually always content. Copy that isn’t written yet. Images that need sourcing. Product descriptions that exist in someone’s head but not in a spreadsheet. Stakeholders who need to approve things but are travelling until next month.
This isn’t a criticism, businesses are busy, and writing content is harder than people expect. But it’s why we now talk about content on day one, not halfway through. Who’s writing it? When? What happens if it’s late? Get this sorted early, and the project flows. Leave it vague, and you’ll be chasing PDFs in week eight.
Technology matters less than you’d think
The industry loves its debates. WordPress versus headless CMS. React versus vanilla JavaScript. This framework versus that one. We’ve been guilty of caring too much about this stuff ourselves.
But here’s the truth. Most business websites have similar needs, and most modern tools can meet them competently. What matters more is choosing technology that fits the client’s situation. Their budget, their team’s skills, their plans for the future. A technically “inferior” solution that the client can actually maintain beats a cutting-edge build that falls apart the moment we’re not around.
We’ve seen beautiful, sophisticated websites abandoned within a year because nobody internal could update them. And we’ve seen simple WordPress sites run successfully for a decade because someone in the office could add a blog post without calling a developer. The right technology is the one that works for everyone, not just the one that’s most interesting to build.
Relationships outlast projects
The best professional decision we ever made was prioritising long-term relationships over short-term revenue. Not every project is profitable. Not every client is easy. But the ones who stay, who come back year after year, who refer their contacts, who pick up the phone when they need help, they’re the foundation of a sustainable business.
This changes how we approach the work. We’ll tell a client when they’re overcomplicating something. We’ll push back on ideas that won’t serve them well. We’ll occasionally recommend they don’t do a project at all, if it’s not the right time. This honesty costs us some immediate work but builds something more valuable. Trust.
[katatomcyears] years in, most of our work comes from people we’ve worked with before, or people they’ve sent our way. That’s not an accident.
Done is better than perfect
We’re perfectionists by inclination. We like clean code, polished designs, and elegant solutions. But we’ve learned, sometimes painfully, that a live website beats a staging website stuck in and endless refinement loop.
Businesses need their websites to do a job. Generate leads, sell products, inform customers. Every week spent tweaking and polishing is a week the site isn’t doing that job. There’s a balance, obviously. Launching something broken or ugly isn’t the answer. But “good enough to launch” is a real milestone, and hitting it matters more than most developers want to admit.
The sites we’re proudest of aren’t necessarily the most technically impressive. They’re the ones that launched on time, did what they were supposed to, and made a genuine difference to the businesses behind them.
What stays the same
The tools we use have transformed completely since 2000. The browsers, the devices, the expectations, the speed at which everything moves. But the fundamentals of project success haven’t shifted at all.
Listen properly. Solve the real problem. Communicate clearly. Deliver what you promised. Be honest when things go wrong. Think long-term.
None of this is revolutionary. But after all these years, we’re more convinced than ever that it’s what actually matters.