How To Reduce Total Cost Of The Website?

At a conference I attended a while ago, one of the CTOs noted that “these days you have to give an arm and a leg to get good software.” Looking at some project budgets, it indeed seems like it. So what should you do if you have a limited budget and still need to get a website out? Luckily there are many things you can do to reduce costs.

Spend time on research and planning

A good plan saves time down the line. It may seem like moving quickly is a great idea, but that is after you have done the planning. Planning is cheaper than execution and then re-doing things when it appears that there were better ways or things were not well thought through. 

Also, it is at planning that you can do a lot to reduce costs. The below items are achieved mostly thanks to detailed planning requirements and expectations management.

Avoid starting from scratch

Open Source is full of projects created by the community which can be a great starting point for your project. They will save you massive amounts of time and money. Depending on your requirements, things may be closer or further away from what you need, but still adapting them will often reduce cost.

For example, if you aim at building a website these days, it is quite typical to not create the whole thing from scratch but base it on an Open Source CMS like Drupal or Wordpress. This is a no brainer. 

But can you get more? YES! For example, both of these CMSes have dedicated communities which build fantastic ready to use websites built on top of the basic installation. 

In Drupal, we have built a starter for corporate and business pages. Droopler is super customisable, with a multitude of pre-built elements, it can save your team a massive amount of time by providing you with re-usable components, SEO optimistions etc.

Just looking around for available solutions can be an extreme time and cost saver. 

Do less

When planning a new project, the tendency is to write down all requirements - the must-haves, the could haves and the might-be-nices in one document and then try to implement all of them. This is expensive and unnecessary.

I suggest that in the first version you do only the must-haves. Everything else should be scheduled for further phases. An approach that works well is to list all the requirements and grate them with a P1 - P4 rating of priority and then plan to deliver only P1 in the first phase, where P1 means cannot launch without it and P4 means - we can live without even for 2 years.

It is important to ensure the P2 and P3 are possible with the software package and team you chose but not plan implementation yet. If something is a P2-P4, you should initially simply forget about it.

The benefit of this approach is not only reduced cost but:

• Increased time to market - You will be able to capitalize on your ne website quicker and will earn the money to do further phases.
• Ability to change your mind - Even the best plans have errors. After you launch it often becomes evident that the initial assumptions were not 100% correct and things that seemed P2 become P3 or a P4 but there are new things that become critical.

Once all P1 things are listed, consider if perhaps it would be possible to deliver them one after another, rather than all at once. This will get you your website even faster. As a rule of thumb, if your current website does not have something now, you probably do not need to in the first version of the new one.

Over the years, I have seen many projects ship super complex functionality which was supposed to be a must-have and was subsequently never really used. The smaller you make the initial project the better. This is the best place to save a ton of money.

Prioritisation as stakeholder expectation management tool

The approach of prioritisation and phased delivery is not only great for reducing initial workload and cost. It is also a fantastic tool to manage expectations and reduce project politics. Typically if you are building a new website, there are many stakeholders you should involve. They may have a lot of important and less important input. They themselves, however, may be important and their requirements may not be easy to drop even if they are not on the critical path to project success.

One way of keeping everyone happy is including all the requirements and then prioritising them in the correct order of phases in which they will be delivered. This allows each stakeholder to win his battle of adding to scope but it does not immediately raise the effort and cost of shipping version 1 of the website. Then, in my experience, on a typical project, stakeholders are extremely involved in the planning phase and the launch. Further phases, delivering the P2 and P3s get less publicity and are often left to the project team. Subsequent new and changed requirements that flow in after launch move the project in new directions and the initial lists of P2 and P3 are rendered obsolete and many requirements which would be difficult to exclude at the outset can be forgotten ;)

Now it is not to say that stakeholders' requirements are irrelevant. Many are critically important and stakeholder management is also paramount. We are just looking for a way to ship the website faster and cheaper. Also if something survives as a Phase 2 or Phase 3 requirement and then is implemented then it proves that it was really needed and could not be forgotten.

Simplify the must-haves

You have a critical list of items that you require. The nest question to ask yourself is “Can you simplify these?”. Is there a simpler way to achieve the exact same thing?

Replace great with quick, where it makes sense

Perhaps there is some tradeoff that makes sense and can reduce costs? Remember that the project is being delivered to achieve goals. It will not achieve them if it is super great technologically, but too expensive.

In web development, a typical trade-off is for example configurability. Some things should be configurable, but not everything has to be. Removing configurability typically drives development costs down.

Another tradeoff is between using something that is already ready but meets 80% of your expectations versus spending a lot of time building from scratch to eventually hopefully achieve the 100% (where 100% is hardly ever achieved in custom builds).

I, of course, do not mean a compromise on quality here, but on features. Features can be added later if you need them. Quality is difficult to improve.
Replace the first idea with an alternative, cheaper solution

Another simplification is to look at complex features and think if perhaps the goals they are to achieve, could be met in a different, cheaper way. The typical examples here are:

1. Careers pages with a whole application workflow, which can be easily farmed out to a multitude of available SAAS solutions available on the market. 
2. Feedback forms can be embedded from a SAAS solution,
3. Ecommerce - which can often be substituted by Shopify or the likes
4. Complex FAQ sections where people can add questions to be answered (typically better replaced with a simple, manually edited FAQ section and a form to “submit yours” which sends the question to email.
5. Complicated integrations with multiple services - these might be required but the way they can be integrated can vary. Sometimes an Iframe might get the job done better than a 2-way communication mechanism.

The more custom elements and inventions the more expensive to build and more expensive to maintain.

Finally, remember the 80-20 rule

As someone said, “Done is better than perfect”. The website should do its job, not be a work of art. If you can achieve 80% of the result with 20% of effort, it totally makes sense to choose the path. You can always work on the remaining 20% later, if you have more budget and time.