There is something to which I will be eternally grateful to our project managers for and that is: they refuse to give guarantees

I am sure this drives our clients a little crazy. I know intuitively it doesn't make sense; after all, we're professionals right? We should know exactly what we're doing, and have done it 100 times before. It's a little like going to a builder and saying "Yes, I'd like this house" and them replying "How about you give me 150.000 € and I'll build you the best house I can".

Well, this post is to explain why we take this approach whenever possible, and to explain that it's designed to deliver a better website, faster and with less risk. It's kind of like building a house, but also a little different.

Let's build a website

The nice, house like parts

When building a house, there are certain decisions that are basically made for us. We should use cement foundations and a concrete slab for the foundation, prefabricated cement blocks for the walls and tile for the roof. It's cheap, well insulated and the manufacture cost is quite low.

It's much the same with a website. There are a whole series of things that are simply answered - finding the website at a specific address (, verifying that it's actually your website (TLS), managing the computer on which your website runs (The LAMP stack), the basic design and logical language (HTML and PHP respectively) and most of the e-commerce business logic (Magento). Each of these things solves difficult technical challenges, and I cannot overstate the amount of man hours that went into solving those problems initially. However, because they are so easily and consistently solved it's easy to take them for granted.

Building the same house many times over

Building a house is a large, up front investment. However, once built that house is probably going to be okay for the next 30 years. It might require small bits of maintenance, but largely it's okay.

With a website, it's a little different for a couple of reasons. Firstly, the web is fundamentally new, having it's birth only 30 ago (the time of a single house!) In that time, it has undergone a radical transformation from a small network used by the US military to ensure command and control can operate in the event of nuclear war to a fundamental part of our daily lives, connecting us each to each other through social networks, business systems and e-commerce. This rapid rate of change imposes some peculier design constraints on our development; namely during the construction of a website we are already planning how it can be remodelled easily in future. A website will be changed 5, 10, 100, 1000's of times in it's lifetime!

In addition, occasionally the entire landscape of the web can shift around us. The most trivial example is the release of the early iPhone, and the advent of mobile browsing. Now, the majority of web traffic is driven through mobile. These landscape shifts are constantly happening; the next perhaps being the release of conversational experiences such as Alexa or Google Assistant. During development, we optimise to be adaptable in the face of these changes, rather than for a fixed constraint that may not occur.

Building a house that's better than all the other houses

Mostly, houses are the same. Your house is probably not dissimilar from my house and houses can be mass manufactured fairly easily.

Websites, and in particular e-commerce, cannot. These websites are among the most competitive industries in the world and those who have the first well implemented solution often have a disproportionate advantage of their competition. These solutions are inherently bespoke; they have never been built before, or where similar solutions exist the requirements are often wildly different. To implement these solutions we must first understand the problem that this solution is attempting to resolve, understand the solution put forward by the business to help resolve the issue and understand the technological constraints under which the solution must be implemented. It is only with a sound understanding of these factors that such a new feature can be successfully published.

Taking over the maintenance of a badly built house

In the case of owning a house, it's usually fairly straight forward to diagnose and repair an issue. Indeed, it is a subset of construction - make a large, up front investment, resolve the issue and rep the benefits for the next 30 years. Excellent!

Taking over a website poses a few complications.

First, we usually only take over a website if the website is not matching the expectations of the client. For this to occur, there must be a fundamental problem in the workflow that produced this website. These problems range but some examples are:

  • The previous implementers did not have the skills to implement the solution they designed
  • Constantly shifting requirements before delivery meant that the solutions developed did not match the expectations the client has, and are built in a fragile way with a series of ad-hoc changes
  • Some budget constraint (time or money) ran out during the development of the site, and sacrifices were made to the implementation to deliver on time.

These problems must be reconciled before continued development on the site will meet with success. However, we have quite some experience helping people through these problems, and are usually quite successful improving a project.

Reconciling software difficulties into a manageable, profitable project

When building a house, it's usually pretty easy to see the risk vs reward. Invest a chunk of money, get a house for the next 30 years.

Building is website is inherently less predictable, for the reasons defined above. However, we have much experience dealing with these inherent complexities and have settled on a project model that allows balancing the profitability of delivering improvements against the risk of sinking too much cash for too little benefit. The model is in reasonably common use with software development, and is called "agile software development".

Each company interprets the process in their own way I'm sure, however in our case it means breaking down the problems that are defined into small manageable chunks, and delivering fixes to help things in an incremental way (usually about 1 - 2x per week). Broadly speaking, as a developer a project works roughly as follows:

  1. Establish a delivery model that allows software to be regularly deployed in a fairly risk free way
  2. Fix any urgent issues that are breaking the site in a fundamental way
  3. Deliver small improvements to the site, addressing any ongoing issues additionally as they arise and affect the site goals
  4. Repeat step 3

That's it. By undertaking this model we can help the clients realise a number of benefits:

  1. Improvements (even of partially complete) are published much sooner than they would otherwise be. Faster improvements means more time with larger return on investment (ROI)
  2. Where tasks are more difficult than initially imagined, losses can be cut earlier and budget reallocated to higher ROI
  3. The site is adaptable to change and ROI continually reevaluated for maximal profit from the site.

In summary

So, building a website is kind of like building a house. But it's also kind of not. While conceptually it makes sense to think of it in the same terms, we need to understand the limitations of the "up-front design" model of project management, and instead prefer to opt in a more agile model. We are firm believers in it and have seen it adopted successfully many times before. While it's quite different than the standard project management, we feel it suits the inherently malleable nature of the web and are confident it is the best model for client success.