3 Tips to Rethink and Greatly Improve your Business Processes

Business process improvement

Together with our customers we have made quite some interesting process changes over the years. I wanted to share some of the most important insights we have gained and give a few examples that might help you rethink your processes.

#1 Simplification

It may seem superfluous to say, but many processes can be simplified. Many companies are doing things the way they do just because they have always done them this way. A good way to start, is at the data that is used in the process. Look at every field of data used in the process such as for example employee number, customer social security number, etc. For each of these fields find out why you need it. If you can’t find out why, simply cross it out.

We have noticed that many times data is used in a process that is needed by law. However, laws change and it is easy to then forget that the data in a process is linked to it. One of our customers was once still storing customer’s identity information while that was no longer needed by law. We changed the process to a much simpler one, which got rid of everything related to the customer’s identity information.

#2 Automation and exceptions

One of the most interesting changes to make in a process is to automate it so that it becomes manageable by exception. This means that most of the times the process is executed, it can be handled completely automatically. Only if there is an exceptional case should a human employee intervene. This may sound a little bit abstract so let me give you a real world example.

A customer had a process where they hired external people on a regular basis to supervise exams. Those supervisors would declare their travel costs and time they spent. All this information was sent by regular mail. The information was then typed into SAP after being checked. Before paying the amount the entire declaration was checked again. This took a lot of time obviously and was seriously error-prone.

What we designed together with our customer is a process that is almost fully automated. From their online exam booking system we get all the information needed to determine the declaration; home address of the supervisor, address of the exam location, the duration of the exam and whether the supervisor was present and the financial information to transfer the money to the supervisor. With this information we use an internet service to automatically calculate the travel expenses. The duration of the exam is used to calculate the declaration for the exam.

All declarations for a month are combined for the supervisor, who can then simply download the declaration for his administration. The declaration is automatically transferred to the supervisor, who has an option to file a complaint if he thinks something is wrong (which is an exception, because most information is provided by the supervisor in the first place through the online exam booking software).

In this example the success rate is higher than 95% which is a good rule of thumb to aim for when designing such processes. You want to be able to achieve as close to 100% automation as you can, but certainly not lower than 90%. The process in this example eliminates a lot of copying of data manually, almost fully automates the process and provides time saving for both the company and the supervisor. Win-win.

#3 – Responsibility and self-service

A final tip on automating and rethinking processes is to take responsibility into account. Some processes require some input from a customer, supplier or employee. It helps enormously if you can design it in such a way that the person who has most to gain, is the one responsible for supplying the information. This creates a natural pressure to perform, which can then be further helped by sending a reminder if the data is not yet supplied after a certain amount of time.

One example of such responsibility is when we designed a process for an educational institute where the participant could indicate his company would pay. In this case, we would send an email to the company asking them to sign off on paying for the education, which would expire after 7 days. This places the responsibility to make sure the employer will sign off right where it is best put: at the participant who wants to take the course.

This step greatly reduced the amount of time spent handling requests, both because the educational institute no longer had to call after the employer, but also because there were far less issues with people trying to get a course paid by their employer without permission.

The real reason your software projects cost more than quoted

Software project costs

It was the summer of 2001, when I walked into the office of a small student recruitment agency. They were in the business of finding exceptionally talented students for part-time jobs working in the IT industry.

For students, it meant bringing their knowledge into practice, while for the companies it was both an opportunity to get work done at a low price, as well as a recruitment channel. But I was there for a different reason.

The breakdown

The recruitment agency had asked me to custom build their website. Nowadays you wouldn’t build your own CMS, but in the early days of the internet, this was more common. So, there I was, ready to talk requirements on a hot summer day, in the souterrain of a canal house in Amsterdam.

Across the table from me was one of the owners of the agency. They explained in detail what the goal of the site was, which functionality he wanted and how things should look. We made a few changes to the sketches he had already made, and I was good to go.

To give an accurate quote, I broke down the work into smaller pieces. Designing the database, writing code to retrieve and store data, and code to handle the functionality. Finally, writing HTML and CSS to make sure the site would look nice in all browsers.

I then estimated each piece separately, making sure no single estimation was higher than 1 day of work. If that was the case, I would break it down into smaller pieces. Grand total: about 10 days.

Doing the work

With the estimation and the work in hand, I started coding. I already had considerable experience at the time, since I was used to doing a lot of similar coding, so I was confident in my estimations. As I was coding, I continuously checked how much time I had for each piece. This forced me to work quickly and effectively.

After I had finished coding and testing I had spent exactly 4 hours less than I had estimated. The site was now ready to be tested by the agency.

Big surprise

When I entered the office of the recruitment agency again, the owner was already there. He had tested the site and, apart from a few minor pointers, it was completely to his liking. Then he told me that he didn’t expect me to finish this quickly. He had actually anticipated the project to take 1.5 to 2 times longer!

I was perplexed, I had given him a very detailed quote, which he’d accepted and he expected me to take longer than I told him? What did he know about how fast I can work!? So I decided to ask him why he thought I would take so much longer.

In his experience, he had never had a project done in the estimated time. It usually took at least 1.5 times longer than projected, which is why he had already factored in this number. He then told me that he did the same towards clients. A student would give him a quote, he would double it, and present that to his customer.

It all seemed strange to me, these were people that were good at what they did, had some experience with it, yet couldn’t estimate a simple project correctly… I didn’t give it much more thought then; my customer was happy and I was happy having done a good job.

Estimating is key

Years later, I encountered similar situations in software projects where I wasn’t the one making the quote. It only then occurred to me that there was something that most quotes have in common, which leads to the estimation being incorrect.

Where I had broken down all my work into neat little pieces that were easy to estimate, this is not always possible. There are several reasons why this is the case. The most common one is that not all requirements are known when the quote is requested, making it very hard to give an accurate quote. Estimating for uncertainty is something that is bound to be inaccurate.

Another reason is that usually the work isn’t broken down into smaller pieces that are each estimated separately. Rather, the project is estimated as a whole, or in big chunks of work. Humans are notoriously bad at estimating, which means that the larger the chunks are, the bigger the difference between the quote and the actual effort will be.

The final reason is the most important one. You have requested a quote. But you have not requested a single quote. Usually, you request multiple quotes. And the most important decision factor is price. This means that companies will often leverage the fact they don’t know all requirements. They will estimate everything that is known, but leave all other points open. This will of course be ironclad in the fine print.

Getting good quotes

To get a good quote, it is very important to have someone who can judge the details of the quote. And I don’t mean the financials, that’s the easy part. It’s about the technical details. You will need to involve one of your team members who can identify what has been left out, even if it’s not specified.

The most overlooked aspects are usually security and testing. Testing should simply be part of the quote, as well as fixing any issues that emerge from testing. Security is a very costly aspect if not done right. And getting it right, is hard. So, make sure to get a security expert involved in all of your software projects, as early as possible.

And the last thing you can do, is to ask for a fixed price for the entire project. This can identify the points of the quote that have intentionally be left open. Because when the company knows they cannot charge you more if it costs more time, it is suddenly in their best interest (instead of yours) to get the quote right.

How the Rolodex was digitalized and what you should learn from it

Rolodex digitalization

There used to be a time, which I hope many of you have forgotten about, that the Rolodex ruled the desk of every manager around the world. Being in someone’s Rolodex and having important contacts in it, was a sign of accomplishment in the business world.

Since then, this analog way of storing contact information has moved into the museum as digital alternatives have completely taken over. The process of how the Rolodex was digitalized, provides important lessons we can put into practice today when digitalizing our business processes.

What first came to mind…

The first version of a digital version of a Rolodex I used was Outlook 95. It allowed to save contacts, along with the same information that people would put on their contact cards such as their address and telephone number. And of course their e-mail address, although almost no-one had an e-mail address back then.

At the time, I thought it was brilliant. Searching for contacts digitally was much easier than physically.

Looking back, being honest, it really wasn’t an improvement. I had to type over all the information on every card I got, instead of just sticking the card in the Rolodex. That lead to typos, which meant I had to call the company the person worked at to get the correct information.

Also, this process took way more time than simply adding a card to a Rolodex. And while we’re being honest … searching digitally was cool, but back then not really much faster than the Rolodex…

Digitalizing analog processes

The problem with digitalizing a process in a straigh-forward way, like the example of the contacts in Outlook versus the Rolodex, usually leads to less efficient processes. There are inherent differences between analog processes and digital processes. These differences can either be good or bad, depending on how you utilize them.

Analog Digital
Paper is hard to copy Digital data is easy to copy
Easy to secure Hard to secure
Hard to access data Easy to access data
Hard to scale up Easy to scale up
Easy to change process Hard to change process
Hard to ensure compliance Easy to ensure compliance

Let’s take a quick look at some of the aspects and how they can be used in a good way and a bad way. For example, paper is hard to copy. This can be an obvious weakness when we are trying to provide information on a contract to a different location of the company for example. Digital information can easily be copied, for example simply by mailing the document to a person that works at the other location.

But you can also leverage this aspect of a paper process. Things being hard to copy, means they are harder to steal or leak for example. A signed physical document is much harder to falsify than its digital equivalent. Similar arguments can be made for accessibility and security.

Even compliance being hard can be a positive. Paper processes are notoriously hard to comply with simply because there is not a real restriction on executing the process. No matter how specific your paper form is, someone can scribble something extra on the paper or fill out a field completely incorrectly.

For digital processes, these steps can be made in such a way that only the exactly correct information can be entered. In many cases this is a positive, but there are cases where this leads to edge cases not being possible. When the process is very strict, it is easy to comply with, but it loses flexibility.

What today’s digitalized Rolodex looks like

Today’s version of the Rolodex completely leverages the advantages that can be achieved by going digital. However, it also has some weaknesses that come along with going digital. Weighing the pros and cons though, I would say that LinkedIn is a huge improvement over the analog Rolodex. But it works in a completely different way.

LinkedIn leverages the fact that digital information can easily be accessed and copied. Instead of relying on every person to maintain their own copy of someone’s data, LinkedIn simply allows you to link to the data of a person.

This means that when the person’s phone number or address changes, it is effectively copied into your contact list. Much easier than the digital Rolodex example I gave earlier.

Because LinkedIn is digital, it is very easily accessible. This means I can access my digital Rolodex from home, work, while on the road, and via any device that I am using at that particular moment.

Accessibility is one of the most powerful aspects of digital processes. But it becomes even more powerful when combined with the ease of copying data, as the LinkedIn example shows us.

A big downside of digital, is that it can be hacked. People can steal your password, or they can hack into the system (after all, it’s easily accessible), and get your personal data out of it. This is a big downside, admittedly. That is why we are always stressing security so much when considering digitalizing processes. And security is hard for businesses, as witnessed by the many data leaks we are confronted with every week.

Digital is better

All things considered though, I wouldn’t want to go back to my old Rolodex. LinkedIn has many benefits added to my old Rolodex that were simply impossible in the analog age. Perhaps you found this article through LinkedIn because I or someone else shared it. Or you found a new employer, business partner or customer through your 2nd line or 3rd line connections.

These are all advantages that were impossible before the Rolodex went digital in the right way. So when it comes to digital processes, always remember to leverage the correct aspects of digital to make sure your new process blows the old one out of the water!

5 tips to foster creativity in your team

Foster creativity

Over the past years working with the amazing team at Triggre, I have learned a few valuable lessons on how to foster creativity in a team. Just because your team consists of the best people, doesn’t mean that they will be creative. And while it is absolutely true that some are more creative than others, stimulating creativity will nevertheless make a huge difference.

Define a clear goal

One of the most important things to do when increasing a team’s creative output, is to define a very clear goal. A clear goal doesn’t mean something that is defined in detail. Rather, it provides a guideline for the team to decide what to do. This means that a complete design document with all kinds of technical specifications is not a clear goal in the sense that I am talking about. “Making the world’s most efficient solar panel”, however is.

So a clear goal is a little bit further into the future, allowing for more ways to achieve it and doesn’t define details. Let me give you an example. Our product, Triggre, allows users to make software without technical knowledge. Our goal is to make our Designer as easy as it can be for those users, while still being able to make complex business applications.

This high-level goal has led our R&D team to come up with some fantastic solutions, including ways to prevent users making infinite loops in processes and a fantastically simple way of showing the user where something is wrong in his design.

Stupid ideas are good

The more stupid ideas, the better. This may sound counter-intuitive, but this is absolutely vital. As a team, when you’re trying to find a different way to do something, you need as many ideas you can come up with. Even if it is a blatantly obvious stupid idea, it needs to be shared.

While designing a new concept for our Triggre Designer, we would often brainstorm on some of the challenges. These brainstorms were often full of ideas that we knew wouldn’t work because they directly contradicted some part of our design philosophy. Still we shared those ideas and we would laugh at the funniest of them, all together. So how did that help us?

Well, the nice thing about ideas is that, even though they might not completely satisfy all the aspects you want in a solution. They usually embody a new way of solving the problem, if you have a clearly defined goal. Even if the idea doesn’t solve the problem, having a new perspective, no matter how silly, will trigger other ideas that may very well be the breakthrough you are looking for. So whatever you do, embrace stupid ideas. They’re worth way more than you might think.

Trust is absolutely vital

It takes a lot of guts for someone to share an idea, let alone one that is guaranteed not to be the solution. Especially if they’re not the one who’s in charge. On the one hand, saying you have a silly idea helps, but what’s more important is that someone actually gets to the point where they feel they are allowed to come up with ideas that won’t work in the first place. This requires a very high level of trust.

One of the best books I have ever read on creating a team, is The 5 Dysfunctions of Teams by Patrick Lencioni. It is a must-read for everyone who works in a team, leads a team or aspires to work in or lead a team. Yes, basically everyone, except hermits.

The trust needed ultimately comes back to the goal. Everyone on the team must understand that whatever idea is presented, it is done with the intention of reaching the goal. And that presenting an idea will never place them in a position of ridicule, but instead, the idea is highly valued no matter how wrong it may seem. This is perhaps the most important aspect of getting people to share.

As a leader, this means you never make fun of people’s ideas, never raise your voice because you think an idea is stupid, and definitely never take a shared idea as a personal attack. Because if you do, that sets an example for the rest of the team and trust will fade faster than an ice cream on a hot sunny day.

Kill your own ideas

If you are a team-leader, you will have to set an example. Not only by refraining from the negative, but also by showing the positive. One very good way to do this, is to go first with presenting an idea that won’t completely solve the problem, but gets people thinking. And then killing it, saying “Okay, that will never work. Can anyone else come up with another solution?”.

Do this frequently. Make sure you show your team that it is good to offer any idea, and that any idea can be dismissed, no matter who it came from. Keep doing this until you hit that one idea that simply nails it. You’ll know, because everyone agrees it’s the best way to do it.

Creativity is a process

Any solution is always just a step towards a goal. In one of my first blog posts, A guide from complexity to simplicity, I discuss exactly this attitude. It doesn’t matter if a decision you make turns out to be a step in the wrong direction. Just trace back your steps, and take a different approach.

If you want creativity to succeed, you will have to be open to the process of iterative improvement. That means sometimes you’ll find out something doesn’t work (anymore). Don’t get discouraged. A team that’s built on trust, is creative, and is willing to view everything as a prototype, will ultimately come up with a solution that is far superior to anything you can otherwise come up with.

The Triggre Academy: Goals, approach, plans

Triggre Academy

At Triggre, we are always looking for more ways to let people experience how easy it can be to create their own software using our platform. We want to take away the threshold which many consider impassable. Of course, Triggre is an easy-to-work-with tool in itself, but that doesn’t mean it doesn’t have a learning curve.

From simple mechanical actions to advanced tricks – you’ll need to learn them, preferably in the simplest possible way. Out of this principle, a brand-new training program was born: the Triggre Academy! Its goal: to teach you how to work with Triggre independently, at your own pace, in a fun way.

Step by step and hands on: which level is right for you?

What makes the Triggre Academy a strong concept is our step-by-step learning approach. You don’t have to master an abstract theory first. Our teaching is based on showing you best practices and adopting a hands-on method. Right from the start, you will get to work on practical assignments, so you can quickly see the results of your efforts. At first, these assignments will be small and relatively uncomplicated, but their level of complexity will rise along the way.

Since everyone has their own learning goals, we distinguish between three levels:

  1. The Explorer: create applications of your own that are simplistic in nature.
  2. The Ranger: build all types of applications, including larger, more dynamic ones.
  3. The Guide: acquire the knowledge required to train others, so they can become Explorers and Rangers.

Vision of the future: what to expect?

Our training program aims to teach people how to work with Triggre. But it is also meant to bring them together. Currently, we are working hard on building a creator community. Here, people who use our platform to create software can exchange thoughts and ideas.

Want to know if the Triggre Academy would be of added value for you? Be sure to read our next blog or just come to our next session!

Introducing: The Triggre Academy

Triggre Academy

Amersfoort, June 26, 2018 – In the past few years we have trained many customers, interns and employees to be able to use Triggre. Learning Triggre only takes a short time, because we focus on keeping Triggre as simple as possible, while providing a lot of functionality at the same time. Interns at Triggre have been able to turn a complex process into an application many times over, and customers are happily working with Triggre day-in-day-out. Now it is time for the rest of the world to get access to these resources as well. Enter the Triggre Academy!

Ranks and abilities

Those who have come to know our company culture know that we take an informal approach, value high quality and like to have fun at the same time. This is reflected in our blog posts, emails, even our product. And in the Triggre Academy.

The Triggre Academy consists of 3 different levels that can be achieved:

  • Triggre Explorer
  • Triggre Ranger
  • Triggre Guide

The first level, Explorer, provides base knowledge of how to use the Triggre Designer. Simply put, we’ll show you what all the buttons do and how to use them effectively for your own custom applications.

Ranger level provides more in-depth knowledge of advanced techniques, which can be applied by using the options the Triggre Designer offers in smart ways. Once you have reached the Triggre Ranger level, you are familiar with all the concepts that Triggre offers. This results in being able to make any application with Triggre.

The final level, Guide, focuses on translating business processes into applications and the best practices that we have used with customers over the years. At this level, you are allowed to train others to the level of Ranger as well.

First class

This summer, on July 10th, 2018, we will host our first ever introduction to the Triggre Academy. The introduction is free of charge. You’ll learn everything about the Academy and what being a Triggre Explorer, Ranger or Guide can mean for your business, company and customers.

If you are interested in joining, sign up for the Triggre Academy introduction now. Spots are limited!

Implementing a digital strategy despite the immense skills shortage

Every year I get the CIO Survey by Harvey Nash / KPMG. While the full report isn’t available until June 26th, some of the key findings are. In my opinion, of all the key findings, one in particular stands out. The immense skills shortage.

Skills shortage

The CIO Survey is conducted amongst about 4,000 IT leaders worldwide. Therefore, it gives a very adequate overview of the current state of businesses around the globe.

And while there are many interesting facts every year, the skills shortage is one that has been steadily growing over the past years. This year, 65% of all respondents claimed to have a problem with finding the right IT skills. This is the highest it has been since 2008, which is very alarming indeed.

The result of not being able to find the right skills leads to difficulties implementing a company’s digital strategy. It is therefore no surprise that 78% of all respondents said their digital strategy is only moderately effective, or worse.

Especially taking into consideration the fact that failing to correctly implement a good digital strategy is one of the main reasons companies fail to compete nowadays.

Let go of the faster horse

I believe that companies should actively look for different ways to solve the problem. Many are still trying to find more specialists, where there are none.

While it is tempting to think that we can get everyone to code, the simple fact is that it takes a certain profile to like coding. Just like it isn’t for everyone to be on stage presenting to a large audience, coding and other technical skills simply aren’t for everyone.

Taking this into account, managers should actively search for different kinds of solutions. Henry Ford famously said that people think they want a faster horse, while they really want easy transportation. In IT we should stop looking for that faster horse and instead find other ways to reach our goal.

One way is to look for solutions that actually allow a different type of person to create the software you need, for example. Tools are quickly becoming available that allow business creatives to implement their solutions themselves, instead of relying on skilled technical staff.

This alleviates the pressure to find more skilled people and at the same time increases the effectiveness of the company. A true win-win situation, that only requires managers to think out of the box.

With the skills shortage as high as it is now, companies simply cannot afford to keep looking for more and faster horses. They need to find cars.

How much code can be used in no-code platforms?

No-code & low-code

Code in no-code platforms, that must not be possible, right? Because if you would be allowed to use code in a no-code platform, wouldn’t that make it a low-code platform? Well, the truth may surprise you.

What exactly is code?

This is a harder question to answer than you may think. Because the definition of what code is, depends a lot on who you ask. From a purely software engineering point of view, code is something that you can write, which is then translated to zeros and ones by a program called a compiler.

Only after the code has been compiled, you can use it. You can think of this as writing a letter in English, then translating it to Chinese in full, before handing it over to your Chinese colleague to read.

Over the years however, a lot of innovations have taken place in the field of coding. There are so-called Just-In-Time (JIT) compilers that don’t necessarily need to be run before using the code, but can compile on the fly, or ‘just in time’ for you to use it. I would still consider this code, but other experts might disagree.

In the analogy of the letter, you would let your Chinese colleague read while you are translating. Every time your colleague wants to read something, you make sure you translate it just in time. If your colleague suddenly jumps a paragraph, you do too, leaving the part in between un-translated until your colleague may eventually read it.

The real difference comes with languages such as JavaScript, which are mainly used in web-applications. JavaScript for example, doesn’t need to be compiled before you use it. Instead, it is ‘interpreted’.

Think of this as how the United Nations uses interpreters. They don’t translate any letters, but instead they interpret everything that is said on the fly.

This is distinctively different, because once you have interpreted it, the translation is no longer available. You’d have to translate again the next time the same text is spoken. In software engineering, this is called ‘script’.

Script isn’t code … or is it?

As a software engineer, there is a very big difference between scripting and coding. Mainly, script can be changed more easily than code, because code has to be compiled after it has changed. Script can just be changed and then used. From a technological point of view, scripting and code are very different.

The question of course is, though technologically different, how different are script and code to the person writing it? The answer is not all that different. JavaScript is, as the name suggests, script that is based on Java. And Java is code.

Today, the words are even becoming more similar in meaning, as it is now generally accepted to call writing JavaScript or HTML coding instead of scripting.

So whether we are talking about script or code, the act of writing it is more and more considered to be ‘coding’. And that is fine, because they are very similar to the person writing them. They often even look almost the same. You might be wondering why this difference is such a big deal. Good question.

No-code or no-script

Most no-code platforms are no-code because they don’t allow you to add any code. However, they will often claim that they can also be used for very versatile solutions. And one way of achieving that versatility is allowing the user to code, eh, script.

If the user can script certain things, such as the user interface by using HTML, then the platform is strictly speaking no-code. Whether as a user you experience it that way, is a different matter entirely of course.

I believe that the only real solution is to simplify the design process to its bare essence, eliminating a lot of the reasons to want scripting. For business users, a simple solution is often favorable over a more complex solution that has broader applicability.

Therefore, the option to use script for modifications should be considered to be coding. And should ultimately not be allowed in no-code platforms, in favor of a much better and easier user experience.

The difference between low-code and no-code platforms

No-code & low-code

In my earlier post I talked about the rise of no-code platforms as the next step beyond low-code platforms. We briefly looked at the difference between them, and in this post we’ll take a closer look at some of the distinct differences between low-code platforms on the one hand, and no-code platforms on the other.

Target audience

If you’ve read my other post, you already know that one of the major differences between low-code and no-code platforms is the target audience. Low-code platforms are aimed at developers.

These platforms require technical knowledge, and allow good coders to work faster. The more powerful the tools to speed up technical development, the better suited it is for coders.

No-code platforms on the other hand, target business users. These platforms provide no way of manually editing code, and instead focus on creating the best and easiest user experience possible, abstracting away from technical details. The easier the user interface is to understand, the better suited for business users it is.

This difference is a trade-off. Low-code platforms still require some code, because they are aimed at being able to create a very wide array of software solutions. To make sure the developer has the control they need, coding is still an important part of the development process.

No-code platforms however, abstract away from all the technical details. While being applicable for only slightly fewer use-cases, this makes no-code platforms much easier and faster to use.

Closed system

The other big difference between low-code platforms and no-code platforms is openness. A system that is open, allows it’s users to make changes to how it works. In low-code platforms this is done by allowing the user to change or add code, which affects how the application works.

The advantage is that this opens up the system to a lot of custom added code, making it applicable to more use-cases. The big downside however, is that this limits backwards-compatibility.

All low-code platforms suffer this problem, which is at the core of their architecture. Any new version that changes something in how the platform works, will affect customers who are using custom code that uses that functionality, because it now works differently.

This means that with any upgrade of the platform, all customers must spend time testing whether their software still works. If there are any problems, the custom code must be changed before they can upgrade to the new version of the platform.

No-code platforms on the other hand, only have a single version at any given time. When a no-code platform gets an update, customers need not worry about any breaking changes, because it is a closed system.

There are simply no points where custom code is permitted, which means that an upgrade cannot break an application. This is a huge advantage, as it gives users the ease of mind that any upgrade is simply immediately available, without having to spend any time testing.

The Triggre approach

Triggre has focused on these 2 aspects that set no-code platforms apart, from the beginning. We continuously update our designer to have more options, while making it easier and faster to use at the same time.

Triggre also has the advantage of being a completely closed system. Of course Triggre allows you to connect with other applications in an easy manner, but it keeps you from adding any code.

This provides our customers with the ease of mind of knowing that their application will still work, even when they want to make a change a year from now. But we take this even further. When we release a new update to our platform, we publish all of our customers’ applications, so they are sure to get any improvements without ever lifting a finger!

The rise of no-code platforms

No-code & low-code

Recent years have given rise to many low-code platforms. A low-code platform allows coders to gain a higher productivity, because a lot of the tasks they normally perform can be done in a visual editor, from which the platform generates code.

This process is about 2 to 8 times faster than regular coding, according to the many whitepapers on suppliers’ websites. The coder can then manually work with the code to make his own adjustments. Low-code platforms are like catalysts for coders.

No-code platforms, for lack of a better categorization, are platforms that do not require the user to write any code at all to create an application. In many ways, no-code platforms are seen as the next step after low-code platforms.

Because what is less than low-code? Exactly, no-code. It seems logical, but the truth is that low-code and no-code platforms are completely different.

Demand for productivity

Behind the popularity of both low-code and no-code platforms is a world-wide demand for higher productivity when it comes to creating applications. Globalization has had a very interesting effect in making the world seem very small.

A supplier in China can just as easily sell its goods in the US as it can in Japan, over the internet. Effectively this means that many companies have seen an increase in the number of competitors in their markets.

With more competitors, it becomes increasingly important to have a competitive advantage. And because an ever larger part of business processes are supported by software in the form of business applications, it means that companies turn to custom software development.

Standard software, in other words software that can also be used by your competitors, doesn’t provide a competitive advantage. If every company uses the same software, none of them are unique, thus none have competitive advantage. This is why the demand for custom software is growing with roughly 35% year over year.

Custom software is normally written by coders. The world-wide increase in demand for custom software, therefore leads to an increased demand in coders, or coders with higher productivity.

This is the driving force behind low-code platforms. They increase coder productivity, which means more custom software can be created.

Too few coders

The big problem, world-wide, is that there are simply far too few coders. It doesn’t matter if we make every coder 10 times more productive. It won’t be enough. Demand simply grows faster than supply in this case.

This problem is slowing down companies today, and will slow them down even further in the very near future. With too few coders available, companies simply cannot create the custom applications they need to stay ahead of their competition.

The risk is that many markets will see a winner-takes-all situation arise, where the company with the deepest pockets is the only one that can innovate quickly enough to gain a real competitive edge. Others will simply be bought out, or won’t survive at all.

Emergence of no-code platforms

If there are too few coders to fulfill the demand, we need a different solution. This is where no-code platforms come in to play. No-code platforms target a different user than low-code platforms.

While low-code platforms require technically skilled people to operate them, no-code platforms are made for business people. People who have the ideas for applications, but lack the traditional technical skills to make those applications.

The way you can distinguish a no-code platform from a low-code platform is fairly simple. Look at the user-interface. Is it as simply as possible, and does it aim to help you decide which option you should choose every step of the way in making an application? Or does it rely on knowledge you should have learned about how applications are built?

No-code platforms require zero technical knowledge and this shows by them have an extremely easy to use interface.The simpler the user interface of the platform, the more sure you can be that it truly is a no-code platform!