REGENHU case study

Print a heart like a Polaroid picture

It’s the story of how we consolidated several REGENHU’s applications into one tool and added new features, creating SHAPER.
MedTech BioTech
software development refactoring R&D QA
.NET / WPF PLC / Beckhoff
Wondering how we can help refactor your app?
Contact Us

01 Let’s Revolutionize Medicine



REGENHU is a MedTech company from Switzerland focused on creating advanced bioprinting solutions in Tissue Engineering, Regenerative Medicine, and Drug Discovery. It creates both printing hardware and software.

REGENHU’s principal bioprinting management software is SHAPER, allowing users to design, compose and sequence objects for 3D printing.

It is configured explicitly for biofabrication and manufacturing of innovative medical solutions - all to help, according to REGENHU, “those who are at the frontlines of medical discovery and innovation push the boundaries even further.”

Regenhu SHAPER

01 The Challenge

The ultimate challenge was that the bioprinting material could build up in a unique incubator for several months. One wrong layer can destroy months of expensive work, so the software has to be extremely precise.

When we started the project, we knew what we wanted the outcome to be, but we didn't yet know how to achieve it. To do this, we both conducted user research throughout Europe and gathered insights from within the company.

During development we encountered several significant issues in SHAPER:

  • it consumed a lot of system memory,
  • the majority of the code of 2D and 3D printing modules were duplicated and common mechanisms were at that point difficult to extract,
  • fixes were time-consuming, implementing changes was taking much longer that seemed necessary,
  • there were multiple bugs in the application code.

The code duplicates were very similar but not identical. As a result, errors needed to be fixed twice because of the two separate components of the SHAPER application. All of the above were building up significant maintenance costs.


In the case of SHAPER, our analysis showed that refactoring would be the best option. Why?

  • cshark_case-study_nudge_vector (8)
    Modification of the code indeed took a while to implement, but, given that REGENHU was interested in further development of the app, it was the best move.
  • cshark_case-study_nudge_idea-1
    Building a new application from scratch would take even longer and exceed the budget, while implementing the new saving functionality on the existing code was unsustainable.

01 The Process


The entire development process involved transitioning from one stage to another: from the initial proof-of-concept to prototype and then from prototype to the actual product.


During the first transition period, we were looking for insights into the design of the best solution. This R&D phase helped us achieve what we needed: a validation of our proof of concept and prototype inside REGENHU, but we were also aware of the risk of creating a “non-fresh” code. During this transition, it became apparent that our solution was attainable, but it required refactoring the code during the second transition phase and avoiding “protoduction”.


Accordingly, we planned a thorough refactoring of SHAPER. As part of that process:

  • We modified about half of the application to improve the architecture.
  • We left the algorithms largely untouched, so the application functioned as before. At the same time, we analyzed them and made improvements in terms of speed and resource consumption.
  • We modified the core of the application. Instead of an omnipresent, pure inheritance model, we opted for a solution leaning toward composition and component-based system. It allowed us to gain flexibility, minimize the risk of code redundancy and avoid the risk of creating god-objects.
  • We made the application more independent from external software and more flexible for further development. Once we have tested our prototype, we knew where abstraction would be required to separate from 3rd party libraries. The component-based architecture made this move much easier for the development team.
  • We managed to unify the separate 2D and 3D subsystems, which means that any modifications to the code can be performed only once.


The entire process was broken down into several sprints. This allowed us to proceed with further development of the application itself simultaneously. This solution was necessary to enable adding new features, including the saving functionality, and we managed to achieve the set goals without problems. Without sufficient knowledge and experience in refactoring, applying modifications while simultaneously developing an application can lead to further problems.

REGENHU SHAPER tool gif v2

When we finished the refactoring process, we were able to add the new “save” feature to the application, which now allows users to save projects and come back to them later. In addition:

  • The application gained a new architecture, which was raised to the modern quality standards.
  • System memory use was cut by 90%, which helped to eliminate the need to use a swap file located on the hard drive, making the application run faster, smoother and without jittering.
  • The time required to generate various design shapes is now linear - it takes the same amount of time regardless of the complexity of projects and the number of its elements.
  • It makes greater use of the processor, which contributes to the overall better use of computer resources.

01 The Result

Depending on the state of your existing code, refactoring may be the best investment you can make.

If REGENHU didn’t opt to refactor the code, adding the new feature would be extremely difficult and time-consuming, and would likely make the application impossible to maintain. It already consumed a large portion of system memory, so new features would slow it down even further and make it more unstable. Most likely, it would prevent further development of the app.


Through refactoring, REGENHU gained:

  • greater system flexibility of SHAPER, which allows for adding further new features,
  • lower maintenance costs,
  • easier to implement modifications, with more predictable results,
  • greater stability of the application.
  • cshark_case-study_nudge_shuttle-3 (1)
  • cshark_case-study_nudge_location-1-1
    Switzerland, USA
  • cshark_case-study_nudge_money-1
  • cshark_case-study_nudge_calendar-1
    Dev. time

    12 600 hours

  • cshark_case-study_nudge_team-2

    2 WPF developers

    1 QA

    1 PLC developer

    1 electrician

  • cshark_case-study_nudge_magic-wand-1

    software development


    research & development

    quality assurance

The knowledge brought by CSHARK boosted the development rate and quality to an extremely high-level. The code quality increased drastically by reaching an 80% code coverage in just a few months of work, while the amount of feature implemented more than doubled since the arrival of the CSHARK development team. Throughout the different internal reviews that we often have, an unanimous feeling of wonder at the development has been expressed.

Samuel Gilleron
Samuel Gilliéron
Software Architect at REGENHU

01 FAQ

What is code refactoring?

Refactoring is a process of rewriting the code of an application to increase efficiency and quality without changing its functionalities. The result of refactoring is a new, refreshed version of the code (which is also usually brought up to current best practices) which performs the same functions but runs faster, smoother, and gains in terms of scalability and flexibility for further development.

When code refactoring is a good move?

Refactoring is a common response to accrued technical debt. The process helps increase the longevity of the code, which otherwise could quickly become outdated and legacy. In fact, refactoring is always needed when you’re writing code: as project objectives change with time and goals evolve, certain modifications may have to be introduced to allow for further development.

When code refactoring isn’t the best option?

Refactoring requires time, financial, and resource investment. These costs will always vary depending on the state of the code and software development goals. So, to understand whether to refactor or not, you always have to take the context and the state of the code into consideration.

If you have an old application with multiple bugs where you want to add new features, the chances are that the cost of refactoring would be greater than building the application from scratch. Or, you will be required to add new components to an app in a timeframe that won’t allow time for refactoring. You have to consider every scenario individually to understand whether refactoring is a good option for what you’re trying to achieve.

In addition, refactoring isn’t a good move when you are working with a product that will perform a specific function and will not be developed in the future (fire-and-forget types of apps). It’s also not worth investing in refactoring when working on a proof of concept.

Wondering how we can help refactor your app?
CONTACT US cshark_case-study_cta-background