GUTENBERG · CASE STUDY
Gutenberg's diagnostic and modeling tools applied to a real billing domain — payment provider coupling, shared mutable state, multi-service coordination. The domain details are abstracted. The method is real.
A billing platform had structural problems producing measurable failure. The root cause wasn't missing features or technical debt — it was a modeling decision made early: internal objects mirrored the payment provider's objects. These pages trace how gutenberg's diagnostic and modeling tools were used to analyze the system, design the target state, and plan the transformation.
Three functional areas connected through shared mutable state. Internal models mirror the payment provider's models. When a second provider enters, it takes the wrong path at every seam. The diagnosis names the coupling and traces its consequences.
Three area transformations — blind to seeing, many paths to one path, handlers to engine. The target state after the current roadmap completes, with directional KPIs proving progress.
When a recurring payment fails and the customer isn't present, the recovery system takes over. State machines formalize the lifecycle. Graduated consequences replace binary flags. The method is the showcase.
Access granted before payment confirmed creates a revocation dilemma. The timing gap pattern, the three-outcome model, and the shift from subscription-driven to payment-driven entitlements.
Gutenberg didn't just document the analysis — it made the analysis possible. Seam maps named the coupling. State machines formalized the lifecycle. Specs captured the target architecture.