7 Deadly Mistakes which Kill Templated Medical Websites
Templated sites from WordPress (WP), Magento, and others have become popular. We at Body1 even deploy these for small healthcare clients launching their first sites. They are cheap. They are convenient. And they can be dangerous.
Here are seven common mistakes that we’ve seen. We’re often brought in to fixed “shattered” software projects, where a project starts and then cannot finish because of added complexity due to poor planning and unexpected scope creep.
1. Modifying a template without planning. Template-driven systems like WP or Magento are fine but customization adds considerable complexity. Adding or deleting features changes the overall code base. Separate parts of the site will break, suddenly incorporate random pieces of code, or reformat the page, among other unexpected issues. To address this, Body1 systematically scans the entire site in a staging environment after every major code push, with the ability to selectively roll back and adjust potentially problematic changes.
2. Ignoring QC and testing. The activities of quality control (QC) and testing actually are as important as coding. Coding is only 50% of successful website or marketing software deployment. Once a site is coded it has to be thoroughly checked and the code updated to fix issues. This step is often skipped on templated sites- and then the owner is surprised when the site breaks. Automated link checkers, load simulators, and browser emulators are useful tools. On sites Body1 builds we use such tools to check issues prior to launching but inevitably there are still issues which can only be caught by a smart pair of human eyes.
3. Not deploying a separate “stage” site. It’s easy to develop in a folder on the planned live site. It’s harder to set up a separate, password-protected “staging” site with a process to cleanly copy the files over to the planned live site. But that is best practice. Completely separating the development from the live code ensures that:
- all the functionality can be confirmed as working before deployment,
- code in the development & live folders does not conflict, and
- issues in deployment can be quickly and easily fixed.
4. Ignoring the hosting environment details. Understanding and control of the hosting environment is critical to successful programming. Issues in hosting often cause problems with the site performance that masquerade as software problems. This is why Body1 controls its hosting environment. We were called by a panicked customer with a Magento site (eCommerce web template from eBay) whose log-on was failing and their “Magento programmer” couldn’t figure it out. It turned out it was caused by the host running out of disc space (see below). Without disc space the programs will fail. This was especially acute for this eCommerce site where there was a 4gb catalog and multiple development folders.
5. Hiring a low cost developer to start with a quality development team on stand-by. This is the classic “penny-wise, pound-foolish” trap. Coming in to clean-up in a crisis situation is not ideal for anyone. Starting with a low cost developer (often one with heavily discounted rates who works out of state or overseas but is “always available via Skype”) is a sure way to slow or break your website. Such a process also ensures that a high quality development team will have to be brought in at the last minute, on a rush basis, to decipher code and re-architect a site under intense deadlines. Since it is always more complex and takes longer to unravel someone else’s code, problems are invariably missed. This results in the development process being more time consuming and expensive.
6. Retaining the cheap talent to work on perceived “easy parts” of the website while the top talent fixes the problems. This is the classic “Too many cooks in the kitchen spoil the broth” situation. We’ve seen firms do this to try to reduce costs on shattered projects. However it inevitably ends up not being cost-effective as the coordination needs increase significantly and the coding efforts end up conflicting. If the project is “shattered”, the cheap outsourced programmer costs, rather than saves, money. Using a top development firm on a templated site facilitates control of the hosting environment, properly staged projects, and leverage of automated testing tools and QC.
7. Eschewing site monitoring and maintenance after launch. A templated site is not a high-availability site, nor is it fool-proof site. Automated monitoring and planned on-going maintenance of websites is valuable. This is especially so for healthcare sites. Automated monitors can detect problems before they before obvious to the end user. Monitors even can be set up that follow every order through the purchase funnel for sites selling health products or services. Besides real-time QC, those monitors then provide a tool to analyze consumer buying behavior.
Maintenance plans allow these problems to be fixed proactively without impacting the their live environment. Because web browsers (such as Explorer, Chrome, Safari, and Firefox) and operating systems (such as Windows, OS, and Android) evolve, it is inevitable that the unmaintained templated website will break. A good rule of thumb is to allocate 20-25% of an initial web budget to ongoing maintenance.
Avoiding the 7 deadly mistakes of templated medical websites is not hard. A little forethought, a dash of prudence, and the willingness to invest initially is the best way. Besides on time and on budget website launches, there is an added benefit- maintaining one’s own emotional equilibrium.
Chris Messina
