Gremminger
Designing System Logic in Early-Stage Operational Products
The product was created in a start-up context without existing UX, UI or system structures. I was conceptually involved right from the start and was responsible for both the technical structure and the visual system logic. The aim was a B2B application used at high frequency to manage time-limited resources, including pricing logic, role models and operational conditions.
Abstraction
The sports club domain used here serves as an abstract visualization of a real infrastructure and resource management system.
Challenge & Problem
The central challenge was not to build a visual design system, but to model a consistent operational logic.
The product needed to:
- clearly model limited resources (abstracted: sports halls, courts)
- Map time allocation based on rules
- Dynamically manage states
- Calculate price logics automatically
- Enforce roles and access rights across the system
UI was not a goal, but an expression of this logic. Without clear system logic, every new function would have become a potential special case — with increasing implementation costs, growing complexity, and falling speed.
Key decisions
System logic before UI
The structure of data, states, and dependencies was defined before visual decisions were made. UI components followed logic — not the other way around.
- Resources are clearly identifiable operational units: time-limited, condition-driven and referenced across systems.
- System states act as a central tax authority. A time slot is never “just occupied”, but is in an explicit state that determines visibility, interaction, authorization, and pricing logic.
- Spools are structural restrictions: They define which states are allowed and which actions may exist.
- Rates are not awarded, but calculated. They arise from time segments, type of use, role and tenant-specific rules.
Modular resource models and early scaling logic
The core operational structure of the product was not built around specific resource types, but around an abstract resource model. A resource was created as an operational unit from Location × time defined – supplemented by clearly defined system states and rule-based derivations. Pricing logic, role rules and usage types were not anchored in individual UI components, but placed over this model as an independent rule layer.
This did not create a feature-driven structure, but a system-driven architecture.
This understanding of resources had concrete structural consequences:
- New resource types (abstracted e.g. tennis, squash, beach volleyball) require no new logic, just configuration
- Price changes are controlled based on rules, not implemented visually
- Roles act as a constraint layer, not as special case code
- Statuses remain consistent across the system and can be interpreted across modules
Scalability was not treated as downstream optimization, but anchored as a structural design decision. Expansions based on resource type, pricing model, or role structure are made through rule adjustment – not through redesign or component-based exceptions.
The result is an operational system that can absorb complexity without fragmenting its internal logic.
The model separates operational unit, state logic, and commercial rules into clearly defined system layers.
UI as an expression of system logic
Condition-controlled operating units
Each visual unit acts as a state carrier and represents an explicit, systemically defined state.
Prices as a deterministic reaction
The price is derived from rule-based derivation and is calculated as a deterministic system reaction.
Roles & booking classification
Roles act as a constraint layer and determine allowable states and actions across the system.
Resultierende Wirkung
Strukurelle Wirkung
Wachstum über Modell-Erweiterung statt Sonderstrukturen
Zustände bleiben systemweit interpretierbar
Rollen wirken als Constraint-Layer
Keine Fragmentierung der Kernlogik
Operativer Impact
Reduzierter Implementierungsaufwand bei neuen Modulen
Konsistente Geschäftslogik über Module hinweg
Einfache Integration tenant-spezifischer Anforderungen
Stabilere Weiterentwicklung bei wachsender Produktkomplexität
Frühe architektonische Entscheidungen bestimmten nicht nur die Oberfläche, sondern die Skalierfähigkeit des Produkts. Dadurch bleibt das System mit wachsender Komplexität stabil – ohne Re-Design, ohne Modellbruch.