Often site owners and agencies don’t deploy a new site until everything is perfect. This can add weeks, months or even years to a new site development project. But a better answer would be: Go live as soon as what you have in development is better than what you have in production.

One of the biggest killers of value in a web development project is a website that isn’t deployed. Web design and development is a large investment of tens of thousands of dollars in client money and time. Often, the deployment of a new site is delayed by months (or even years) because it’s less than perfect. But a website can not start earning a return on investment until it is deployed. It's like a retailer building a new store but unable to open for business due to a lack of lightbulbs.

The solution is to deploy as early as possible. For example, if a website project that has implement 10 out of 15 requested features and is error free and workable, then it should be considered safe to deploy to live. As additional features are completed, they can be deployed one-at-a-time until the site is "complete".

In agile development, this is known as iterative development.

A simple example

Here's how iterative development might work in practice: say there's a new organization that needs a website. The client thinks they'll ultimately need 12 features (pages, forms, etc.) in a "Complete" website. Then say their vendor estimates 12 weeks to build that feature complete website. But at the moment, they have nothing. If the client or vendor insist that the site be "Complete" before deployment, then it will be three months (and probably longer) before the organization has their site.

Critical Mash would start by building a simple, one or two page site. An attractive single-page site can be designed, coded and delivered in less than a week. The next week, we can start building the second feature. Then for each week for the remaining 10 weeks, we add a new feature to the site. And every week, the client is getting more and more value out of their site: more exposure to the search engines; more exposure to website visitors and feedback on how their site is succeeding and where it needs help.

For a client with an existing website, the process differs only slightly. Say a client has a website they want to replace, but they want to recreate 5 legacy website features and add 7 new features. Again, this is a 12 week project. We can't go live with just a single-page site, the client needs their 5 legacy features. But we'll still begin by creating a single page, that initial page will exist on a staging site were the client and selected stakeholders can review progress. Then just like with the first example, we implement features one at a time, beginning with one of 5 crucial features from the old site. After five weeks, we have a new website that offers enough functionality to replace the existing site. What we have developed is better than what's in production, and at this point we recommend to the client that we go live. In the following weeks, we complete the 7 new functions deploying each one to production as they're approved.

But wait. There's more!

This method has additional benefits: first, it reduces work-in-process. Keeping the client and team focused on doing a few things right at any one time.

Another benefit with this method is it spilts one large project into a series of smaller one to two week projects (known in agile as a sprint). Smaller projects are just easier to handle. It also gives our client contacts a crash course in our complete project management work-cycle, learning how we scope, design, build and deliver a project, and what they learn they can instantly apply to the next week's project.

The third additional benefit concerns a phenomenon that's seldom discussed but happens with alarming frequency: the client changes their mind! In the early planing stages of a web development project, the site owner comes to the vendor with untested ideas about what they need in their new site. That's OK by me, the best way to test those ideas is to build something and see if it works. The problems occur when there is a large time gap between when a feature is requested and when it's delivered. Building the site in short one-week segments allows the client to get results and provide feedback quickly.

So, if this is such a great way to build a website, why don't all web development firms do it this way?

Part of it might be many agencies past lives as print only firms. (You can't send half a catalog to press). But a large barrier to building sites this way is the use of database-backed content management systems, like Wordpress or Drupal. These databases not only store your site's content, but manage users, store site configurations, and much more. With these systems, copying over the entire staging database and overwriting the production database is the easiest way to move a significant number of changes. But this means loosing any data that is unique to the production site (like user accounts, blog posts, log data or leads collected by contact form). That's often the reason why such projects have large Phase I builds but never get to a Phase II.

But Critical Mash's JAMStack platform is all file based, copying and merging data from multiple versions of the same site is easy and painless when working with files. This makes the cost of weekly incremental updates much, much lower and enables us to start delivering value much, much sooner. As a matter of fact, we can even deploy multiple times in a day if needed, that's basically what we're doing in our staging environment.