Our decision-making process on digital technologies used in a project
Regardless of which kind of digital build we are working on, the technology stack we use is not always the same. There are some core principles that we follow to decide what this will be.
Clevercherry has a diverse range of clients, meaning we build a variety of digital products and solutions. We definitely do not stick with the same old technology stack for every project. In fact, we have a process that we follow to decide on the technology stack – on a per project basis. We make sure the technologies we select are tailored to the project requirements and scope, so we are always using the best ‘tools for the job’.
The functional spec, always the spec…
It goes without saying that every project has a detailed functional specification. That always comes first.
Writing a specification gives us chance to see what the technology stack might consist of. Early decisions focus on the server. Our web-based builds often run on Cloud Linux on our own servers, for example. We ensure we are working with the right technologies, and that everything is set up early doors for the project.
Then, there are swim lanes
We use Trello to organise the project right from the start. We set up swim lanes when we are in the discovery phase. It helps us to reveal what the technology stack might consist of.
It also means we can establish who the internal stakeholders are going to be, and we can then share project documentation around the team. That way, everyone knows where to look for project status and documentation. It keeps everyone in the loop and helps ensure our projects are managed and administered in an efficient and effective manner, both internally and externally.
How are the users going to interact with the finished project?
The next question we try to answer early on, is how will people interact with the finished build or solution?
It is a given that if it’s anything web-based that we are creating, mobile responsiveness is a must. But it doesn’t end there, we have to also consider how users will be connecting to the web build. The Office of National Statistics report shows that 78% of adults access the web via their mobile devices. Mobile responsiveness is now more important than ever, so becomes something we develop and cater for as standard. That way, we get thinking about speed, optimisation and performance early on in the project timeline.
It’s all about the data
Next, we check what data requirements there are. Do we need to import data from legacy databases for example? Do we need to connect to remote services? Then we assess whether we need to build import/export tools, and what file formats those exports might need to be.
Not only that, we make sure that the website will be GDPR-compliant, as this is now something we adhere to as standard, to ensure our clients comply with the latest regulations, and the end user is well protected.
We also now only build in HTTPS, using SSL certification to ensure our websites are built on a secure framework, with an additional layer of security. In short, SSL security means having an encrypted connection to websites. Encryption with a digital certificate keeps information private as it’s sent to or from the website, so it helps protect the site itself, and indeed the end user .
We like Laravel but...
The Laravel framework does tend to come into our focus when we are planning a new project. It’s a good choice because:
1. It’s a secure, stable and robust framework
2. It has a huge ecosystem we can tap into
3. It's easy to extend and customise
Having said this, we are not stuck on one framework. We build on a variety of platforms - yes, even WordPress.
Staring into the future
Our technology stack decisions are also based on future issues, such as:
1. How well supported are the tools and services we are choosing?
2. What's the release cycle (for upgrades) like, and how often?
We also assess the long-term vendor support situation. This is so what we build doesn't run into legacy support issues.
Our front-end work is also assessed to make sure we have browser support across the board. We check that the typography and style rules are as future-proof as possible. Our solutions are built for use and function on all modern browsers and devices, as standard.