At HQS, we develop scientific algorithms to solve specific problems which occur in the scope of materials research. Amongst others, we develop quantum algorithms which we test by simulating small instances of them using high-performance classical computers.We start this talk with a very brief overview of quantum computing and explaining why the enormous computing power is no free lunch. While quantum computers do experience errors, similarly to classical computers, the rate at which these occur is much higher and must therefore be treated explicitly. Quantum algorithms simulate physical systems, so we can incorporate the errors into our computing models. We will ground this overview with an example quantum computing calculation, where we investigate the time evolution of a physical system. This system is turned into a quantum circuit, a series of operations called “quantum gates”, which can then be executed using a quantum computer. In materials research, multiple different fields of science intersect, making it difficult to write software which can be used by researchers from all relevant scientific backgrounds. To tackle this, we developed a way to encapsulate and deploy these programs as building-blocks and make them available to other developers. In order to develop applications on a higher level and reuse components across different applications, we write them as workflows and use Camunda, a business process management platform, to run them. The engine also helps us manage and orchestrate the hardware required to execute the single tasks on classical or quantum computers. For passing well-structured data between tasks of an application, we write schemas, a set of rules the data must follow, agreed on by the developers. This allows us to easily build user interfaces, where the user can enter the input for any application. Additionally, the end user can easily try out a new application, as most of our user interfaces are auto-generated based on the schema and therefore very standardized. Furthermore, the developer does not need to develop a separate UI for their applications, reducing the amount of testing required and the effort to implement form input validation. While developing a generic UI does not need any knowledge of the concrete applications, only of the types of inputs required, we maintain flexibility by writing UI components for typical inputs such as complex numbers.