How to Build a Digital Customer Onboarding Process with Low-Code

In today’s workplace, it seems there is a never-ending parade of developers cranking out apps left and right. Almost every day you hear of some new app in development that will revolutionize work life as we know it, right? Right…

With all the fanfare around mobile and web applications, you might be surprised to find out that in 2020 between 66-70% of ALL software projects failed.

While this may be confusing to some, as a professional low-code developer myself, I can personally relate to the fact that projects–which were sometimes backed by billion-dollar companies–often fail. Either they never launch, are besieged by delays, or launch and—this is the worst—aren’t what users need. Where the failure rests is in our development methods.

In today’s web, we stand on the shoulders of those who came before us and build on what they’ve made.

Failure comes from not recognizing that.

If you ever enter the IT department for your company – go to the DevOps floor. You will be greeted by an understaffed team of developers, headphones on, eyes red from staring at screens. Chances are they will be so focused that they won’t even respond when asked a question.

Why are they so intense and bleary-eyed? I’ve experienced traditional developers finding pride in building apps from scratch and doing it by themselves. Preferring to do it yourself and build from scratch can be amazing with enough time and resources, but for small projects with limited funding, it’s often the project’s downfall. When tools like low-code present themselves, traditional developers tend to turn their noses down at them. Where’s the challenge!

Apps built from scratch take what feels like forever. An inability to rely on other people’s work can make a simple build needlessly complex. The irony is that there isn’t a real-world application today that doesn’t rely on some prebuilt library in Node.js or Java.

Using a low-code platform like Mendix, which allows you to source from a marketplace of Mendix- and community-built modules is the same concept as a prebuilt Node.js library. It takes the needless complexity out of the build and simply lets you deliver on the end result.

Sometimes there is nothing already out there for you to leverage. That’s when you have to do extensive and complex coding, and in those cases you want this to be reusable by the rest of the company. In this scenario, most companies would still invest time in making reusable components, and Mendix has tried to streamline this process even more by creating an internal company marketplace, where you can host every custom extension, your company creates and share features and functionality between your company’s websites and apps, safely with the knowledge your intellectual property is protected.

Let’s take the idea of creating a digital customer onboarding process to demonstrate the differences.

A business asks its development team to work on an app that will be used for customer onboarding.

The app needs to have the following features:

• An integration to Dropbox to store the customers’ data and documents
• An address lookup for the customers’ addresses
• The ability to scan important documents and extract information from them
• An ability to digitally sign and review documents.

Using these as a reference, the company’s Business Analyst creates four user stories for their DevOps teams to execute.

• As a user, I would like to have an integration to Dropbox so that I may store the customers’ documents in the cloud.
• As a user, I would like to have an automatic address lookup so that I can easily find the customer’s address.
• As a user, I would like the ability to scan important documents, using the device’s camera.
• As a user, I would like the ability to digitally review and sign documents.

As there are two teams in the department, with no other new active projects in the works, the company decides to allow both teams to create apps and have them face off in an internal hackathon.

Team 1 is a low-code team that primarily uses Mendix to build and host their apps. The team is made up of one highly skilled developer, an accountant from the finance department who is learning to code in their spare time, and a designer from the Marketing department who is gifted at styling websites and apps.

Team 2 is made up of three traditional developers: a Java developer, a C# developer, and a Node.js developer. In both scenarios, the teams also have access to the larger traditional scrum stakeholders like QA and business analysts.

Two weeks later both teams present their apps to the stakeholders, each taking turns to demonstrate how their apps satisfy the user stories laid out for the challenge. And there is a clear winner – Team 1.

Going through the submissions, the judges evaluated them against each user story. Let’s unpack what they saw.

Team 1 immediately recognized there was a prebuilt module available in the Mendix Marketplace. Using this to base their work on, they soon managed to set it up and focused their time on user interface and documenting their code, which they did in the video.

Team 2 spent most of their time trying to understand Dropbox’s doc pages, and while they did produce a working integration, the user interface was rough and clunky.

Team 1 immediately recognized there was a prebuilt module available in the Mendix Marketplace. Using this to base their work on, they soon managed to set it up and focused their time on user interface and documenting their code, which they did in the video.

Team 2 at this point knew they were behind, and tapped an expert in the field for some help. If you’ve worked in software project management you can sense the issue here. A famous law in software development is Brookes Law which states, “adding manpower to a late software project makes it later.” By bringing in a new team member to build the OCR feature the new member will need time to be caught up on the project, they will then also need time to understand the current codebase. As always this proved true and the project fell behind even more.

Team 1 was able to maintain their pace of development. They used a—yes, you guessed it–module available to them in Mendix, and the low-coders with no experience in Image recognition managed it quickly, relying on their most technical member to carry them through.

Both teams produced similar results for this user story, but as the low-code team was able to leverage their secret weapon (the accountant who knows the correct process this follows in the current system) they were able to avoid a mistake in complex user flow. They had so much time left over, they were able to make a video about this as well. Team B did not.

Mendix gave Team A the option to automatically model their apps domain model by uploading the existing spreadsheet, which is automatically read and recreated in their app’s domain model. Finally, Team A leveraged Mendix’s ability to generate generic overviews for all the required data, and because of this, they were able to focus on all the critical integrations for the app.

The judges easily selected team 1 as the winner–But why?

Fundamentally both teams met all the same requirements – this is the same technology, being processed by the same provider, and yet team 1 finished in half the time and spent the rest iterating and refining their product. Here’s what they were able to create.

If you’re interested in more information, do read How to Build a Digital Customer Onboarding Process with Low-Code blog from Mendix.

Post by Ryan Mocke