beat the competition 
posted in Websites: Templated and Patchable v Bespoke
I am still amazed at how slow the web design industry moves. Even in 2002, it was obvious to me that web development and software development are pretty much the same thing - complex scripts that are prone to bugs, security issues, or simply becoming out of date (or demanding new features) as the world and technology moves on, and therefore such scripts absolutely have to be easy to update.Software developers have long since cottoned onto the idea of automatic updates. Well, most have. You don't even notice when your Chrome browser is updated, whereas some people are still stuck using IE6. The difference between those two browsers I've mentioned is huge - the former browser supports the latest technologies like HTML5 and you get a very good browsing experience, the latter struggles to render the most basic of websites and "features" huge security issues, and half the web has stopped making sites for the browser you use. That's the difference between being on an update path, and not being on one. Being up to the minute, or actually being obsolete.
What about websites? Well, the likes of Joomla! and WordPress etc of course update their core codebase and offer updates to those running sites with these platforms. The problem is these updates are either too difficult to do, or website owners don't feel compelled to update. There's millions of unpatched sites out there.
Actually, the most common scenario is where a web developer will create a truly bespoke site - normally a mashup of one of the aforementioned templates mixing in their own code, or perhaps modules they've written themselves that they re-use and manually meld together various scripts to create something unique. They're web developers after all - they design, they code, they create. A client tells them their brief, and they shape their code around the requirements. The end result is what I call a "snapshot" site - one that's frozen in time, not possible to update automatically. Unless there's a developer out there who continually writes flawless code (there isn't), these sites will feature a multitude of issues that aren't apparent on launch date, but surely will rear their ugly heads later down the line. Of course, the developer will realise these issues as time goes by - but then he realises - I have 100 sites that have this inherent bug(s) in them - what's the cost/benefit of spending an entire day manually patching 100 sites? How serious is the bug? And then if he patches all 100 sites, 10 of them have new issues because the patch doesn't quite work right on some of the sites due to their unique nature. The developer becomes horribly familiar with the nature of unintended consequences. Suddenly he realises he isn't dealing with one codebase, but a hundred of them. Another job, another codebase. Compare that to a software developer who has one codebase and 10,000,000 customers.
That's the simple part of the problem. It gets more complex. Every web design company with several employees has the same problem EVERY company has - employees leave. So a web developer leaves, and a new one takes his place and manages the sites the departing web developer created. It's quite rare to find two developers who have near-matching scripting habits, capabilities, and philosophies - everyone's different. Even if the new developer spots a problem with the existing websites he's taken over, it can take so long to track down the causes because he's unfamiliar with the codebase. He may even introduce new bugs inadvertently. Another example: a new developer may not be as SEO aware as the previous one, and so the SEO friendly sites a company based its reputation on suddenly are no longer being built because a new developer has taken the helm. Maybe the new developer is more SEO aware than the previous developer. He wants to apply SEO updates to the existing portfolio of sites. Then he realises his updates just cannot be practically done across hundreds of sites without spending 3 or 4 days work, and so the sites are left in their current state while he gets on with more profitable work. I've seen all these scenarios first-hand when I worked at a number of web design companies between 1998 and 2004.
The general point I am making here is that there's a terrible inconsistency with "traditional" web development that does not treat its websites like software. And if you're choosing a company to make you your website, surely you need to know what you're going to get (just like you do with software). The problem a lot of developers have is that they deliberately see each site as unique purely from an aesthetic angle - they are not separating the design from the functionality. Of course there are sites that absolutely demand unique functionality, but they are actually few and far between. Most sites require a generic set of e-commerce and content management features. All sites tend to live or die on "the simples" in any case: if nobody can find it, it's dead. If people can find it, but few people can use it, it's dead. If people can find it and use it, but the products/services it offers aren't in demand, it's dead. It's a very rare site that actually succeeds because of some bell or whistle or unique feature or gizmo or fancy-pants splash page animation or dazzling slideshow. These aren't to be discounted - they can aid in conversions depending on your target market - but quite often it's the more peripheral decorations that force a site into a bespoke status when it doesn't need to be.
While the puresilva template certainly isn't a "one stop solution" for all businesses - we even say so here - you will get a site that uses 100% mirrored codebase that is used by literally hundreds of sites that have proven to be successful, so it's not going to be a sloppy error (like non-unique HTML titles, missing H1 tags etc) that you have to worry about, or a new developer imposing his own preferences onto your site. There is the consistency you get when you use any software, and what's more because it's used across so many sites, bugs are much faster to identify. I write this as if this is all innovative - of course, it isn't. We're using a tried-and-tested model software companies have used for a long time now.
Share this article:
view my profile on Google+