MOVIT: How a Booking Tool Grew into an ERP
From appointment booking for a beauty studio (2018) to scheduling, CRM, point of sale and finance: the story behind MOVIT and the architecture lessons from my 2023 thesis, which used the system as its case study.
- MOVIT
- ERP
- Architektur
- Angular
- NestJS
- Nx
- Diplomarbeit
Project story · Looking back at my 2023 thesis
A quick note on the date: this article brings together two things that happened at different times. The product MOVIT itself goes back to 2018, which is why the article carries that date. The thesis, for which I used MOVIT as the case study, was written in 2023. The sources listed at the end were checked again in 2026 for this retrospective.
In 2018, I developed MOVIT for a few customers. It started with a concrete task: organising appointments for a beauty studio. During my apprenticeship, I built a booking tool for it. Step by step, it grew into software for other parts of the business, including customer and employee management, point of sale and finance.
In 2023, I used this ERP as the case study for my thesis. I examined how its architecture had changed with the product, where the structure helped and where it introduced complexity. This retrospective connects the product story with the technical decisions behind it and how I assess them today.
A real problem became a learning project
An ERP was never the plan. I wanted to make appointments bookable for a beauty studio, nothing more. Then the next requirement came, and the one after that, and at some point a single feature had turned into a system for several parts of the business.
I was learning on the side. Whatever I picked up in my apprenticeship, I tried directly in MOVIT and saw whether it held up in daily use. Some parts I rewrote two or three times, each time with the knowledge I had at that moment. That moved me forward, but it also cost me: some things were hard to maintain, some already existed as finished solutions, and some nobody needed in the end. Unclear requirements and too little research have a price, and I paid it.
With the first real users, the yardstick changed. A technically exciting extension only counted if it took a concrete task off someone's plate. In the thesis I openly noted that I put too much time into details that brought customers little. Today I would test a small, complete workflow with users much earlier and build out from there.
What MOVIT connects in daily business
The idea is easiest to explain along the path of one appointment: a customer books a service, the team schedules it, the customer data is ready, and the delivered service ends up in the point of sale and in reporting. Every tool works on the same information, because in a business that information belongs together.
MOVIT's four product areas show this connection:
- Online booking and agenda: book appointments, schedule staff, send reminders.
- Customer management: customer information and notes for day-to-day care.
- Point of sale: charge services and products, issue receipts, evaluate daily closings.
- Finance and reporting: keep an eye on income, expenses and reports.
On top of that come shift planning, links to services and custom reminders in the agenda, plus discounts, vouchers and QR/barcodes at the till. (MOVIT, Agenda, Point of sale)
For me, the real architecture question sits exactly in these handovers: how do modules share information without it becoming unclear who is responsible for what?
Modules and navigation: the structure has to help the users
I grouped the features into front office, back office, finance and administration. Individual modules appeared as "apps" and were assigned through user roles in identity and access management. Each person was supposed to see exactly the tools that matched their job.
The figure from the thesis shows this modular interface, and it also shows how broad the original booking tool had become. Navigation turned out to be a problem of its own: users asked me what "front office" and "back office" even meant. My internal order was not self-explanatory to them.
So the area structure became a suggestion. Anyone who wanted could switch to a simpler navigation with features shown directly, or adapt the structure themselves. I still carry that lesson: domain modules are good for organising software. The interface still has to follow the real work tasks, not my layer model.
Original figure from my 2023 thesis, p. 18: example of the modules.
The technical setup as of 2023
I chose technologies I already knew well and that could be reused across web, backend and mobile. Angular on the frontend. On the backend, NestJS gradually replaced my own framework structures on Node.js; TypeORM connected the data model to MariaDB. Mobile apps ran on Ionic. Nx kept applications and shared libraries together in a monorepo.
| Area | Approach | Reasoning |
|---|---|---|
| Web UI | Angular | Consistent structure and existing knowledge |
| Backend | Node.js and NestJS | Modular organisation similar to the frontend |
| Data access | TypeORM and MariaDB | Models and data access in application code |
| Mobile | Ionic | Reuse of Angular knowledge |
| Code organisation | Nx and NPM packages | Manage applications and shared building blocks |
| Operations | Linux, Nginx, Docker and Ansible | Deploy services and set up servers |
The structure distinguished apps, services, packages and shells. Apps covered business features like agenda or point of sale. Services handled jobs like SMS, email or document generation. Packages bundled reusable code. A shell provided the frame of an application and loaded the matching apps. The goal was that one module could be used in several application contexts.
Original diagram from my 2023 thesis, p. 24: structure of UI, API, services and shared packages.
Deployment and extensibility raised new questions
Everything ran on a single VServer. Ansible set up the Linux environment, Docker contained the applications, and Nginx routed requests by domain and path to the right service. A call to /api ended up at the API server. The figure shows the setup with several application contexts.
For extensions I looked at Module Federation: separate frontend applications that assemble into one shared interface. I wanted to develop modules independently and plug in new features later. In return I picked up new questions: shared services, compatible versions, service workers, updates.
Operations had limits too. Watchtower pulled new Docker images on the staging server; production updates I triggered by hand. Later changes to the server configuration no longer made it fully back into the Ansible setup. So the automation was not enough for a reproducible full rebuild.
A Galera cluster I had set up early on was removed again because nobody needed it. A good example of how additional infrastructure has to justify its effort. Today a new component only gets added once its purpose, its operation and its recovery are clear.
Infrastructure figure from my 2023 thesis, p. 19.
What I would judge differently about module boundaries today
In the thesis I mixed up repository structure, modularity and distribution across separate processes in a few places. Today I keep these questions apart: Where does the code live? Who owns the rules and the data? What gets deployed together? Which changes have to succeed together?
A monorepo is first of all just a shared place for several projects. A shared deployment does not follow from it. You can easily build and release independent applications from one repository. (Nx: What is a Monorepo?)
Microservices bring independent releases and targeted scaling, but the price is communication, data consistency, testing and operations. A split only pays off with its own business responsibility and a concrete benefit. (Microsoft: Microservices architecture style)
For a small team I would build a modular monolith first today: clearly separated responsibilities inside one application that ships as a whole. Booking, customer management, billing and notifications would be the obvious boundaries. One module must not simply change another module's data.
The 2023 state shows why this matters: the modules were separated, but the database stayed shared. The planned split would have required sorting out existing relations and how to handle changes or deleted data. More processes would not have resolved these business dependencies, only moved them.
One appointment shows what reliability means
An architecture design becomes tangible when you walk it through one complete workflow. My example: a customer books an appointment. The service is delivered later and only then released for billing. A booking alone does not create an invoice.
If a resource may only be occupied once at a time, two parallel bookings must not get around that rule. A free slot in the interface is not yet a binding commitment. The check belongs where the booking is stored for good.
An appointment can be confirmed while the confirmation email is still pending. For that I would use a transactional outbox: booking and send job are stored in the same database transaction, and a worker sends later. Retries are possible, so receivers have to recognise duplicate jobs. (AWS: Transactional outbox pattern)
For billing I would store a stable job key together with the invoice. A uniqueness rule prevents a reprocessed job from creating a second invoice. The interface shows clearly what already applies and what is still pending.
For external messages there is no "exactly once": if the mail server accepts an email and the worker crashes right after, the next attempt creates a duplicate. Failure cases like this belong in the design from day one.
Process graphic, newly drawn for this retrospective: this is how I would design the flow today.
Permissions, tests and operations belong to the same process
One statement from my thesis I would strike today: the readability of JavaScript says nothing about the security of an ERP. What matters is access rights, input validation, dependencies and protecting the runtime environment.
The real question is: May this person perform this action on this record? A hidden menu entry is no substitute for a check on the server. If several companies use the same application, each record's ownership has to be checked as well, including in search, export and attachments. (OWASP: Authorization Cheat Sheet)
The thesis says it in black and white: there were no tests. In a rebuild, these would be my first ones:
- Two simultaneous bookings do not confirm the same exclusive capacity.
- A repeated billing job does not create a second invoice.
- Users never receive data outside their permissions.
- After an interrupted send, the open job stays traceable.
Operations are part of this: versioned configuration, verified database migrations and a recovery that has actually been tried in a separate environment. Monitoring should show successful bookings, errors and jobs that stay open too long. A reachable server proves nothing about a working business process.
What MOVIT left me with
MOVIT taught me how closely product development, user guidance, data model and operations are tied together. And it gave me something no course offers: living with my own decisions in production for several years and re-evaluating them as my knowledge grew.
In 2018 I was at the very start of my career, with little experience. Building my own framework back then was an intense learning experience, but it ate a lot of time that would have been better spent elsewhere for standard tasks. NestJS came later. Today I would rely on established frameworks and existing building blocks early and put the time into business features, quality and user guidance.
The most valuable part was the full lifecycle: gathering requirements, designing solutions, building features, deploying and running the application, and turning feedback from daily use into the next version. All of it on a real product with real customers.
MOVIT is still in use today, but no longer under active development. The thoughts in this article describe how I would approach a rebuild with what I know now.
Sources
Thesis: Best Practices in der Entwicklung von Software-Architekturen für ERP-Systeme – Eine Fallstudie mit Vergleich (Best practices in developing software architectures for ERP systems: a case study with comparison), HF IPSO, 6 September 2023. Project history and modules: pp. 16 to 18; infrastructure and structure: pp. 19 to 27; technology decisions: pp. 29 to 30; evaluation: pp. 31 to 34. The three historical figures come from this thesis.
The product pages on mymovit.com and the linked technical sources were checked for this revision on 8 October 2026. The cover and the process graphic were newly created for this retrospective.