1. Which technology should I choose?

Perhaps the most crucial question when you have a website, webshop or app built. What technology should you use to make it? Are you going for an existing CMS or are you going to have everything custom built from the ground up? Do you want to develop your app natively or do you opt for a framework that allows you to create apps for Apple and Android with one codebase?

If all goes well, you have already discussed these questions with your internet agency at an earlier stage. As the strategy phase en functional design phase have been thoroughly addressed, then your web agency can tell you which technical solutions are the best for the realization of your site or app. Before arriving at the development phase, it is already known which technology, CMS or frameworks will be used.

Below we outline a number of rules of thumb that you can take into account when choosing the technology.

Which technology do I choose for my website?

If you want a website with a homepage, a blog, a few pages of content and, for example, a contact form, then it is almost always the best choice to choose an existing CMS. Having something custom made would be overkill here.

This changes when you want a website containing my environments, links to other systems or complex web shops. Sometimes you can solve all this in an existing CMS, possibly supplemented with custom code, but not always. Sometimes it is smarter to go for a 100% custom solution. Where that boundary lies is sometimes difficult to determine.

In any case, what you should pay attention to is what is possible as standard in an existing system and what adjustments you need to make to get it the way you want it. If a lot of time needs to be made available to adapt existing software, consider the alternative of making everything custom. Then don't just make a choice based on costs, but also look at the future-proofness of the chosen solution. If the cheapest solution saves you two years, but the custom (and more expensive) solution gives you five years, then customization suddenly becomes less expensive than it seems.

Which technology do you choose for an app?

The closer you get to the hardware, the more advisable it is to have an app built natively. Hardware in a phone such as a photo camera, gyroscope, speaker or microphone are quite complex and can be used in many ways in an app. You can control those functions best and most accurately with the original programming language. Native app development is then the best choice.

If the app makes less use of the hardware in a phone, then using a framework would be a better choice. Apps that mainly serve content with simple interactions with the user are very suitable for this. By using a framework you do not compromise on the functionalities you can build in, but you do save time in the development phase. And that makes the pricing of an app a lot friendlier.

2. Ensure a smooth process

No matter how good and complete your FO is, you will always notice that during the development process things go differently than planned or imagined. Perhaps because you come up with a brilliant feature in the meantime that still needs to be added or because the plan you devised turns out not to be entirely feasible in practice. That can and does happen part of the job. The question is how you deal with that. Below are a few tips:

  • Clearly record your first draft and stick to the plan: Work with your web agency to decide what the first version of your site will be (V1) that you will be working towards. New features that you think of later can always be created, but move them to V2 or V3. This way you create peace in the project and your web builder has the space to opt for a V1 that is of perfect quality. A focus on quantity (as many features as possible) usually leads to a compromise on quality.
  • Work in sprints and with tickets: record exactly what is being worked on for every week or every two weeks. Make sure there is a clear ticket for every task in, for example, Jira or Trello. The more detailed the ticket is, the better. It is better to describe a ticket like this: “Add a button on the news page with the text 'contact', preferably 100px below the content block and aligned in the middle, link to the contact page”

    then like this: “add 'contact' button”.

    Your web agency is in principle the party that creates the tickets, but always check them critically to see whether the list is complete and especially whether the tickets are explicit enough and clear.
  • Focus on the goal: sometimes you have come up with something, but you discover with your web builder that it is not entirely feasible. What a bummer but that can always happen. Look for an alternative together with your agency, keeping your goal in mind. If the button cannot turn green, look for blue or red. Maybe not what you initially had in mind, but it will probably achieve the same goal. And that's what it's all about in the end.
  • Ensure a good DTAP street: DTAP stands for Development, Testing, Acceptance, Production. Four different places for your site and each place has its own rules. Everything may be wrong and crooked on the development environment, but absolutely not on production. You put all your content on the acceptance environment to see if everything is correct, and then you publish it on the live environment (production). On the test server you can go all out and test all possible user scenarios and see where things go wrong or do not run smoothly.

3. Pay attention to the speed of your site

A beautiful and complex site or app is of course wonderful, but if it is very slow, it is not doing anyone any favors. During the development phase, keep an eye on how your website scores with a tool like Google PageSpeed. You want to achieve a minimum score of 7,5, but preferably an 8+, on both mobile and desktop.

When the speed is lower, you have to take action. Sit down with your web builder to see what possible causes are behind the poor performance. GIT and a good deploy tool are useful tools for this. You can then test speeds of different versions of your site. This way you can see at which point in the development phase the site has become slower. You can then search the codebase more specifically to find out exactly what is causing the slowness. And there are of course many tools available that developers can use to view the performance of the website and see where there are opportunities for optimization.

4. Ensure a secure website

The success of your site is also determined by how secure it is. And the way it is programmed has a major influence. Incorrect programming creates vulnerabilities in the site that hackers and other malicious parties can take advantage of.

Sometimes it is difficult to determine whether your website is completely safe in terms of code because you cannot always see whether your site is 100% safe. Often you only find out when it is too late. What can you do to check your website for safety and potential security risks? You have a few options:

  1. Make sure that your website and the server on which it runs are up to date at all times. Then you can be sure that the most obvious safety risks are covered.
  2. Perform so-called penetration tests (pen tests). There are many tools available that can scan your website for vulnerabilities. A penetration test tries to hack your website in all kinds of ways. If that is successful, the pen test can tell you where vulnerabilities are in your site.
  3. Have a third party do a code review. Although programmers – just like plumbers and carpenters – always have criticism of each other's work, it can sometimes be useful to have a third party look at the code.