What is Custom Web Development
By Ralf Klis, FutureLab’s owner and technical leader.
This post was originally published on LinkedIn.
I work in an industry bursting with various options and solutions. There are hundreds of web development companies out there, providing thousands of solutions. From customising Wix websites, building entire CMS from scratch, WordPress, Magento, Umbraco – the list goes on and on. All of that falls under the broad definition of web development.
Defining Custom Web Development
There are as many definitions of custom web development as there are companies out there specialising in providing it. But what they have in common is providing some sort of customisation for the customer. The most popular ones include:
- Customising a closed source system for the customer’s needs
- Creating a completely custom solution for the customer
- Customising an Open Source theme for the customer’s branding
- Customising an Open Source CMS for the customer’s needs
The majority of custom web development companies out there would be developing one of the above solutions. Basically, these solutions are about making the experience of the website/web app unique on the market in some way. And there’s no single “right way” to do it; often the same result can be achieved in a number of different ways.
You’re probably wondering why I’m writing about customisation if it’s all the same. Why start the discussion in the first place? Because through my own journey of building a custom creation business, I discovered that we were all wrong. That the above definition is not what custom web development really entails.
What is custom web development
Here’s a hint. To get to the heart of what “custom web development” really means, remove the “web” part and what’s left over? Custom development: it’s the entire journey of the project, from the idea through to the result, which must be customised. My sales person once asked me to create a script for the initial meeting with a new customer. It was an impossible request. Because creating a script would ruin my definition of customising the experience. Customising the creation of something new. And it cannot be fully customised or innovative or unique if we aim to repeat any of the previous solutions.
The custom journey
We create custom solutions. In order to deliver them, we customise every element of the journey. It’s not a trademarkTM and it’s not a rocket science, but we make sure that the web journey is unique for every customer.
One of the most important elements of the first meeting with our customers is that we don’t do much talking. We listen. In the end, we’re not here to offer a pre-ordained solution, we’re here to find out what the customer needs and then come up with a solution to solve their problem. So once the customer tells you what they need, that’s when you can start the talking. Only then can you suggest the solution, discuss options and start the process of customising the journey.
Whatever the end goal, you can’t get to a perfect solution without measuring the current state. This is assuming that we have access to some kind of data. Even if the customer’s product is brand new, there are tools like Google Keywords Planner or Google Trends to do some initial competitor research. If your customer already has a web presence, Google Analytics is invaluable for measuring data. We also use Hotjar to create a User Experience (UX) report and Google Data Studio to assess all the most important data in one place.
Whether it’s a simple website or a web app with a complete business management system, the discovery phase is where the custom journey gets up to full speed. We divide this into visual and technical discovery.
Visual discovery is learning about and helping to organise all the information about a customer’s brand, brand guidelines, likes and dislikes. This is sometimes reinforced by very simple design presentations to find out what the customer likes.
Technical discovery is also called scoping. This phase gathers all the required functionality, describes it and puts it in one place (the scope document). This document also becomes your delivery goal as all the functionality described and agreed on by all stakeholders becomes an end-product checklist.
The design phase should use all the above elements to create not only a unique user experience and design, but also to provide a solution to the identified problem. This is often a struggle between the data and the customer’s needs. The ideal solution is a middle ground between what the user is looking for (UX report) and what the customer wants (scope). A great example I frequently bring up relates to the contact form on the top of the homepage. When we did a UX report on one customer’s old website, it turned out that no one ever filled out the form on the home page itself. All converted users automatically clicked on the menu element “contact us” before even looking below the menu. The solution was a middle ground – remove the “contact us” tab on the menu and replace it with a button “enquire” that pops up a contact form without leaving the page.
This part has been already described above. Whether it’s a fully customised CMS or customised Wix website, it’s important to focus on delivering the right solution for the customer. One customer may look for ease of editing; another prefers full automation. Whatever the needs and goals are, the majority of the web development work happens here.
This might be a somewhat unique approach of my business and my philosophy, but as much as I love our customers and love keeping in touch, the last thing any of us would like to hear is “can you please fix that typo on my blog”. It’s not just important for us that the customer has full control of their content and website; it’s also very important for every business to have full control of their product. This might be a landing page, eCommerce, or the web app of a startup fully built on the web. Whatever it is, the customer needs to be in control because otherwise, they become dependent on one developer. That is why we provide training on using the custom solution, plus a manual with full documentation, on every project we do.
Handover and go live
Having worked in the Internet industry for most of my life, I know well how things can go wrong. And there are no promises or guarantees in the world that will prevent it. Just like the development process, the handover and go live process need to be customised as well. If it’s a transactional website, the go live plan needs to cause minimal disruption to the system, purchasing, ordering, booking etc. Even with a simple landing page replacement, there has to be a plan for whether the links will change, any redirects, carrying over extra tracking tags from the old website or perhaps simplifying everything by switching to Google Tag Manager. Either way, this part is very important and the customer’s input is needed to ensure it’s as smooth as possible.
This often-forgotten step is an important part in customising the development experience. There is no golden rule and once your web solution is live there will always be something that goes wrong, has been forgotten, or even misspelled. A clear plan of responsibilities, action and support process is very important for every customer. That’s because their online journey hasn’t finished but just started: with constant changes in the Internet and in the industry, the solution that has been developed will constantly evolve. And there’s nothing more frustrating than not being able to deal with the problem.
Whoever knows me, knows that I’m a huge Open Source supporter. I’ve been co-organising WordPress meetups and WordCamps for several years. And I volunteer for one reason – to make the Internet a better place. That’s why when we provide a custom solution it’s a custom journey that we all take together. It’s a small but crucial point of difference, and at the end of the journey you can often end up somewhere completely different than you might have predicted at the beginning. That’s the beauty of a truly customised development process.