Today I’m going to look at three different ways to build a website or app. Not for the first time this is going to involve talking about houses.

Spec Builds

Group home builders are currently the most popular option for house construction in New Zealand. The customer can select from a range of set plans, choose a variety of options to suit their tastes and some months later they can move into their house, which has been built to those specifications.

Each room is documented with each option - from the flooring to doorknobs - specified and priced accordingly. At an early stage of the project the changes are locked in and there is no flexibility around future changes.

The main advantages of this approach is the customer knows exactly what they are getting, the builders know exactly what they are building and everyone knows how much it will cost. There’s further advantages that set plans allow for modular building, refined engineering and minimal surprises. This approach can be taken a step further towards prefabricated houses that are more or less identical.

In the digital world, websites can also be spec built. Each page is documented, priced accordingly and the website is built as per that specification. Website platforms like Squarespace allow for a modular approach where common components can be easily deployed onto a web page.

The downside of this approach is the lack of flexibility. People often don’t know what they’ve asked for until it’s been built and might want to make changes past sign-off. For most group home builders, changes after sign-off simply aren’t happening until the house is delivered as specified - at which point the changes move to post-build renovations.

In the digital world what counts as a change gets a bit murkier. The reality is that in many cases documenting an entire website in granular detail would take about as long as building the website - which is a huge waste of time. We also work with technology which is designed to be flexible - to a point.

Custom Builds

Sometimes people’s requirements fall outside of the norm, or maybe they just want something substantially different from everyone else.

For house building this tends towards an architectural designed house, built by experienced builders. Digital development takes a similar approach.

The first challenge of this approach is the cost. A significant amount of work is required to work out what the end project will look like and how it will meet requirements. In many cases external factors like a steep section for a house, or connecting to external systems have to be considered.

Not only will the architecture phase cost time and money but the solution will have to balance budgetary constraints and customer expectations. Factoring in the unknown adds additional uncertainty to the total cost of the project.

While existing components can be used in custom builds they will be built around the plan, rather than having the plan developed around existing components.

The advantage of this approach is the customer is not constrained by any existing plans, products or templates. Their dreams can be made reality and the end product can be highly personalised to their specific requirements.

The downside is the price, on a number of different angles. Not only is accurate estimation difficult but build costs can be at the whim of unseen issues, external factors, or changes in direction.

A Journey of Discovery

At this point I may have to leave the housing comparison behind. The flexibility of modern technology and processes gives us an approach which is not available to your average house builder.

Over the past eight years UpShift has been tending towards more and more complex projects. Rather than just websites we’re building applications that deal with everything from railway engineering to medical devices to legislation.

The traditional IT approach to application development starts with the documentation of a table bending scope describing in detail the exact functionality that will be delivered. I’ve talked about the dangers of “monkey paw development” in the past - where what you wish for is delivered word-for-word, while bringing a raft of detrimental unintended consequences.

Many complex projects start off with a defined problem looking for a solution. The development, architecture, development and delivery of that solution will change over the course of the project.

As I wrote here:

During development there will always be issues, hurdles, opportunities, discoveries, changes of direction and new requirements. Without the ability to change to meet challenges a project will hit them head on.

Complex problems often require solutions which are simultaneously complex under the hood, yet simple for the audience to understand. Balancing human factors with the technological development is always a learning experience as what might seem like the perfect technical solution may not work as planned when exposed to humanity.

Sometimes it’s best to accept that a project is a voyage of discovery which involves identifying an outcome and then breaking it down into phases - or legs - of that journey to that goal.

Think of planning a (pre-Covid) 6 month overseas trip - you will have an idea of the countries you want to visit and may have an idea of the order you want to visit them. But booking every night of accommodation 6 months in advance is locking you into a schedule you will probably regret.

As always price is a big issue. While it’s possible to cost the first phase of a project it’s difficult to put a price tag on the “end product” - especially when many digital products and services are in constant evolution with no genuine “end” in sight.

Phased work also allows prioritisation of resources. It may be that 90% of the requirements can be developed for $50k, but the remaining 10% would take another $50k to complete - which brings up a very worthwhile discussion on the genuine need for the remaining 10%.

Rather than trying to fix a price it’s better to work towards an outcome and a budget. If there’s transparency around available funds they can be factored into each phase of the project. Any decent developer is going to recognise that available funds are what they are and work with-in those limitations. But it will most likely lead to discussions about what requirements really are required.

Which Approach for Digital?

Spec builds can work for small simple projects - like a 4 page business website. But spec builds only work when there is a crystal clear view of the end product that can be documented in a digestible way.

In many cases a more flexible approach is needed. At UpShift we’re big fans of treating more complex projects as journeys of discovery. Having a clear idea of desired outcome is critical, but enabling flexibility for how to get there allows for the development of a far better end product.

Banner Photo by Ricardo Rocha