Back to blog


If you have any awareness of the insurance market, you’ll know that major disruptions are happening all the time. This prospective client I met with had a new innovative product they wanted to bring to the market in specialty insurance. The idea was to build a digital experience where a person in a specific industry with a specific role could fill out a few forms online, pay immediately through the process, and start coverage within 10 minutes. This sounded absurd just 10 years ago.

I listened to their ideas and laid out how we would utilize low-code to build this solution in months. ‘Speed to market’ was critical because other competitors were working on their own solutions and they wanted to get out there first. We also looked at traditional app dev as a comparison, but the process and speed to deliver was going to take too long. They decided to invest and give us a shot despite only having worked with a few clients previously.

They took a chance on an unproven partner in us and a new platform and approach in low-code. That’s a lot of risk! What made them take that chance?

Our Service Approach

We weren’t the only partner they considered, but there weren’t many Mendix partners at that time to consider in the USA if I’m honest. My company, EPI-USE, is well established with 40 years of history today, so there was confidence that because we were so well regarded in the SAP community, we must know how to consult and deliver with whatever service offering we chose to build. I also was a Financial Planner prior to my technology career so I was able to speak their language quite well. I understood the underwriting process, the binding, the taxes, and so on, so I could articulate the underlying model that we needed to build. Make no mistake, though; We were going to build this innovative solution together. We didn’t have well-built requirements and we didn’t know all the challenges we were going to face.

The business team had thought through the questionnaires with the underwriters, but it wasn’t just a matter of putting forms on a website. There had to be SEO incorporated on the pages, state coverage and tax rules, payment processing via various digital methods such as Credit Cards, reporting and analytics for web traffic and routing, and a completely styled UI. At that time and sadly to this day, many think of low-code as using premade templates and template apps. That’s a part of the use case, certainly, but in my nearly decade of leading a low-code consulting business, we’ve never delivered one of those. They required features that we couldn’t find any evidence of existing in the Mendix app store at that time, so we built custom widgets and solutions.

Each sprint, we came in with a basic outline of what needed to happen per the schedule I had originally presented, but any app development project member will tell you that often, until you see it, you don’t really know what you want. That’s where low-code is so useful, and it made all the difference here. Short, focused sprints enable adjusting to evolving requirements, and the Mendix platform provided the tools needed to support implementing Scrum and Agile principles that bring that together.


They were evaluating low-code platforms and had decided that Mendix was the most appealing for their specific needs. Mendix was one of the most successful low-code platforms at that time and continues to this day, but at that time, they had just come over to the USA and were an unknown. Their background was mostly all in their homeland, The Netherlands. The sales executive teamed up with me to consider their use case and while he worked on the licensing needs and building a flexible model that scaled with them, I focused on what needed to be built, the project team I would assemble to build it, and the support we could offer.

Mendix came in clutch for several reasons:

  • Their Sprintr solution is what we used to manage the entire project. It comes with a project management tool for capturing requirements (stories), comments and details about the stories, progress, sprint planning, and more.
  • The feedback loop was vital. There is a Feedback widget that you can place in your app that appears as a side button and out of the way. Testers or Users can press that and submit feedback, and that feedback goes into a separate organization tool that the Product Manager uses to either respond to directly or send to the backlog to be picked up in future Sprints.
  • The pipeline for deploying and managing the app in the Mendix Cloud, where this app deployed, was all there and easy to navigate. Nowadays clients can choose to even use that tool for their private cloud hosting solutions.
  • The Mendix Marketplace (known as the App Store back then) was vital to help find widgets and modules that the team could bring into the project for use in the app. For example, they brought in a “Community Commons” module that brought in a bunch of custom functions that were needed such as SHA256 encryption for document transfer over RESTful services.

Disrupting the Market in Months, Not Years

Despite vague requirements and tight timeline, our MVP launched successfully on schedule, validating the concept, and attracting customers immediately. First-mover advantage went to the innovator, not the competition. This early success paved the way for expanded low-code adoption across 150+ apps and counting. But it started with the client’s vision and trust in unproven technologies to achieve it. The results speak for themselves - low-code flexibility empowers meeting business needs at the pace of change.