This is some text inside of a div block.
This is some text inside of a div block.

LowCode ERP tames complexity

Simplify Complex Furniture Design Projects


Joly Design is a family business with a history spanning 50 years. The company designs furniture for numerous brands worldwide, boasting a unique database of over 70,000 designs. Chances are, you've probably sat on one of their creations. Their business model is quite specific: they do not produce furniture themselves but instead earn royalties from their designs. The entire process, from initial sketches to actual sales reports, takes months and was supported by a 20-year-old on-premises software system. A freelance architect, who is a family friend, had maintained this system for the past decade. However, after receiving an offer from a startup, they could no longer manage the software. This posed significant risks for Joly Design, as the operations and historical data of 70,000 models were at risk. They needed to act swiftly to address these challenges.


Joly Design is a small business that couldn't afford traditional custom software, nor could they find any out-of-the-box SaaS solutions that suited their unique business processes. Therefore, we decided to leverage Retool and Supabase to rebuild and migrate their legacy internal business application to a modern, cloud-first technology stack. We managed to propose a fixed budget of only €80,000 to redesign, rebuild, and migrate all data. This budget covers support for the model design workflow, a client portal, exchanges, royalty reporting imports, invoicing, accounting, and user management.

How we design a legacy business application migration?

Migration of a legacy ERP system always relies on more or less the same steps.

  1. We go through all the user journeys with the end-users on the existing software.
  2. Take notes of every screen of the app: what are the fields, what are the actions, what is the flow.
  3. We start to design the new data model in Supabase (What defines a Model? What fields for a Customer? What workflow for royalties? What format for an Invoice, etc...).
  4. The next step is to design user flows and high-level mockups of the main interaction screens. Olga, our Product Owner, prefers using Miro boards, which are easier to grasp for non-technical clients like Joly Design. They can see the flow, screens, and ask questions and comment directly on the Miro board.

You might ask why we didn't start designing directly in Retool, with short iterations as we did on other legacy application migration projects?

Well, it seemed to us that we needed more time to fully design the whole process and workflow before rushing into application screens. The main reasons were that non-technical clients need more time to embrace the complexity of their own processes, which they are used to executing but have more difficulties synthesizing and building their own mental model. We usually add this first design step with very complex projects or very non-technical clients.

Part of the Miro board with all user journeys from Joly Design EPR

How went this legacy software migration to low-code?

Very well! We quickly designed screens to manage models. Handling high-resolution images was a challenge, as Retool isn't really made for artists, so a few tweaks were necessary. Integrating the Fidealis API was quite a task too. It’s crucial for patent deposition, where each model designed by Joly Design must be deposited and timestamped by this third-party service provider. We also ran into some back and forth trying to build a simple yet secure way to present designed models to clients. Previously, PDF pages were manually created with designed models and sent by mail to the client. This ended by creating customer portal pages where they can now select models like on an e-commerce site, add comments, and remove models they don’t like. An amazing way to communicate between designers and clients.

Client portal models management

Importing royalty files was quite a complicated task too, as we had to deal with many different formats. We ended up creating middleware that transforms those formats into a single pivot format, which was then imported into Supabase.

Oh, by the way, we forgot to talk about why we preferred Supabase to Xano for this project. The reason is that when we have a lot of financial reporting, direct SQL queries are way more efficient than writing tons of different complex endpoints with Xano. We can write complex SQL queries with a lot of variables and generate almost any kind of report with a few queries. Our rule is then simple: if we have a lot of JOINs and complex multi-table queries, it’s probably better to use Supabase. While if we have complex business logic with algorithmic crunching of data, Xano is way better.

Edit a model screen

Finally, the migration was a challenge too, as we needed to extract data from a 20-year-old, on-premises Windows 2000 server, with only TeamViewer access. No one had ever used Windows 2000 in our team. Oops, we had to learn with tears how awful Microsoft products can be :)

In the end, once we trained everyone at Joly Design, they were happy users of new powerful software. But more importantly, we saved their 70,000 models and offered them a way to continue designing furniture for your butts for the next 50 years.

Consumer App
Software Engineering
Mobile Dev
Content Migration
Business Apps
Conversional AI
Media and Publishing
Financial services
Large corporate

2024 Low-Code Benchmark: Top 50

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Book a free 30 min consulting call

Book A Call