Domain · Design and architecture
What it covers
How platform changes are designed before they get built. Shared data model, integrations, the external product surface, and technical debt management.
Activities
- Data model design — ensuring shared data structures are coherent across loops.
- Integration architecture — how Rentiful connects to operator systems, payment providers, third-party services.
- Product architecture — the coherent design of what the external product is and how it evolves.
- Technical debt management — keeping the platform maintainable as it grows.
Operations
Data model design operation
Queued spec needing data model change → impact on consuming loops assessed → design drafted → reviewed with each consuming loop → committed to documentation → handed off to build.
Integration architecture operation
Queued spec requiring integration → options evaluated (API, feed, manual) → failure modes and fallbacks designed → handoff to build.
Product architecture operation
Queued spec affecting external surfaces → coherence with existing surfaces assessed → multi-brand implications considered (owned surface vs White Label partner surface) → handoff to build.
Technical debt management operation
Velocity indicator flags or specific debt surfaces → impact assessed → debt item scheduled, parked, or worked into the next relevant build → outcome tracked.
Notes
Design is where multi-loop implications get surfaced. A change that seems local to one loop often has ripple effects on others — data model additions, event contract changes, and product surface changes should always be reviewed with every consuming loop.
Multi-brand concerns (surfaces can be Rentiful-branded or operator-branded) are a permanent design consideration now that White Label exists. "What does this look like on a partner surface?" is always a question.