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

Why Do We Fail?

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 but 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.

Traditional vs Low-code: A Practical Example

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.

1) As a user I would like to have an integration to Dropbox so that I may store the customers’ documents in the cloud.

2) As a user I would like to have an automatic address lookup so that I can easily find the customer’s address.

3) As a user I would like the ability to scan important documents, using the device’s camera.

4) 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.

1) As a user I would like to have an integration to Dropbox so that I may store the customers’ documents in the cloud.

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.

2) As a user I would like to have an automatic address lookup so that I can easily find the customer’s address.

Once again Team 1, had a module available for download and was able to hook it up quickly, focusing on rounding out the functionality and documentation.

Team 2 had some trouble deciding on which address lookup service they should use. They all had a preference on which one would be best and lost time deciding. Eventually, they managed to get it working using Google, but once again it was no match for team 1.

3) As a user I would like the ability to scan important documents, using the Devices camera.

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.

4) As a user I would like to ability to digitally review and sign documents.

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.

Decision Time

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.

The team also mitigated any rework to future changes in the modules they used. For example, if the DocuSign library requires changes, they will be handled by the Marketplace creator of the Module, and the agile team will only have to refactor code if there are breaking changes after updating the module, which should have been handled by the connector’s creator.

It’s okay to rely on others’ work. It’s progress. The people and organizations that built these modules and libraries of code want you to use them. They want to save you the headaches they experienced, so you can concentrate on solving bigger problems. The beauty is, you can use these to revamp your customer experience and build digital customer onboarding processes. Or you can leverage these to innovate and modernize any number of systems and apps at a pace you never could before.