Rentya is a SaaS platform designed by Softech for self-storage operators that need one environment for locations, units, availability, bookings, documents, payments and active rentals. The product core organises the rental lifecycle and exposes it through the operator panel, tenant self-service and a mobile application. The architecture separates shared domain logic from operator-specific configuration, allowing facility structure, pricing, branding and integrations to change without rebuilding the process. This case study describes supported platform scope and deliberately leaves out earlier percentage-based efficiency claims for which the repository contains no approved baseline or analytics source.
Business context and the situation before implementation
Self storage combines online sales with a long-running rental relationship and physical-facility operations. An operator must know which units are available, under what terms they can be rented, whether documents and payments are complete and the current state of every rental. Rentya was created as a product core that organises these dependencies and can be configured for different operator models.
- A facility consists of locations, zones and units with their own availability and attributes.
- A booking must reserve the correct unit and move into rental formalisation.
- Agreement, signature and payment belong to the same business process as the booking.
- After activation, the system continues to manage charges, documents and state changes.
- Operator and tenant need different interfaces but a shared source of truth.
- The SaaS core must remain configurable for further deployments and white-label use.
Before state
Without a shared domain model, an operator must connect availability, customer data, documents, payments and rental status across several tools or manual activities. Every additional channel — booking widget, customer portal or mobile application — increases the risk of inconsistency unless it uses the same booking and rental logic.
- Unit availability can be updated independently from the booking process.
- Documents and settlements can live outside the main rental record.
- Pricing and discounts are difficult to keep consistent across sales channels.
- A customer portal without a shared API can show a different state than the operator panel.
- Each operator deployment becomes more expensive if core logic is copied instead of configured.
Goals, success criteria and constraints
Discovery focused on separating self-storage concepts that are reusable from elements that depend on a specific operator. The team mapped facilities and units, availability, booking and rental states, formalisation points and operator-versus-tenant responsibilities. This made it possible to build a configurable platform rather than a set of screens tied to one implementation.
Product goals
- Define one model for facilities, units, availability, bookings and rentals.
- Connect rental formalisation with documents, signature and payment.
- Expose one backend to the operator panel, tenant portal and mobile layer.
- Build configurable pricing, discounts and rental rules.
- Give operators reporting across availability, occupancy, payments and documents.
- Separate the shared SaaS core from branding and deployment-specific configuration.
Success criteria
- The same unit cannot be simultaneously available and reserved through conflicting channels.
- Booking, documents, payment and active rental have an unambiguous relationship in data.
- Operator panel and customer self-service read the same rental state.
- Pricing and rules can change without rebuilding the core workflow.
- A new deployment can use the shared core with its own branding and configuration.
- Failure of an external integration must not leave the process in an ambiguous state.
Complex facility structure
Operators can use different location, zone, floor and unit structures, so the model cannot assume one facility layout.
Long-running lifecycle
A rental lasts longer than a single ecommerce transaction and includes charges, extensions, documents and termination.
Availability consistency
A booking must change unit state so different channels do not offer the same space inconsistently.
Payment and document dependencies
Payment, signature and file generation are external or asynchronous services and require controlled states and retries.
SaaS configurability
The product core must remain shared while allowing operators to change branding, pricing, structure and integrations.
Analysis and product decisions
- Mapping operators, locations, zones and units.
- Defining availability and booking transitions.
- Modelling active rentals and recurring charges.
- Separating operator and tenant interfaces from the shared API.
- Identifying white-label configuration: branding, pricing, rules and integrations.
- Identifying points where the flow must handle failure, retry or manual intervention.
Solution architecture
Rentya uses a shared domain backend as the source of truth for operator and customer channels. The data layer models facilities, units, availability, bookings, rentals, documents and settlements, while external integrations handle payments, files, communication and — depending on the deployment — facility access.
- 01Operator surfaces
Management panel
Management of locations, units, bookings, tenants, payments, documents, pricing and reporting.
ReactTypeScript - 02Customer surfaces
Portal and mobile
Search, booking, documents, payments and ongoing rental self-service.
ReactReact NativeExpo - 03Domain core
API and rental lifecycle
One place for availability, bookings, rentals, pricing rules and process states.
NestJSNode.jsREST API - 04Data
Transactional model
Persistent relationships across operators, facilities, units, customers, documents and settlements.
PostgreSQLPrisma ORMRedis - 05Integrations
Payments, files and external services
Services required to formalise and operate rentals, isolated from the core domain model.
StripeS3 / Blob Storagee-Sign / access integrations - 06Configuration
White-label and operator rules
Layer for branding, pricing, facility structure and deployment-specific integrations.
Product configurationFeature flags / rules
Problems, decisions and implemented capabilities
Unit availability can diverge across channels.
Keep unit and booking state in one model.
Shared availability for operator and customer channels.
Each channel uses the same source of truth.
The rental process is longer than the booking itself.
Define a lifecycle from availability to rental termination.
States for booking, documents, payments and active rental.
Operator and customer see a consistent process stage.
Pricing differs across units and operators.
Separate pricing rules from the core workflow code.
Configurable pricing, discounts and promotions.
The offer can evolve without rebuilding the rental lifecycle.
Documents and payments often run in separate tools.
Connect them directly with the booking and rental.
Document generation, signature and payment state in one process record.
Formalisation keeps the context of the selected unit and customer.
Operator and tenant need different interfaces.
Separate product surfaces but not domain logic.
Operator panel, tenant portal and mobile layer using the shared API.
A new channel does not require copying rental rules.
Each operator has different branding and some different rules.
Introduce a white-label configuration layer.
Configuration for branding, structure, pricing and integrations.
A deployment can use the shared core without assuming an identical business model.
An external integration can respond slowly or fail.
Model integration status independently from business state.
Controlled waiting, retry and error handling for payments, documents and files.
External-service failure does not have to create an ambiguous rental state.
Technology decisions
| Technology | Role | Rationale | Trade-off |
|---|---|---|---|
| React + TypeScript | Operator and tenant web interfaces | The component model supports complex workflows and shared domain types. | A complex panel requires discipline around state management and component boundaries. |
| React Native + Expo | Tenant mobile layer | One product codebase supports iOS and Android while keeping a shared lifecycle. | Device-dependent integrations require testing on both platforms. |
| NestJS + Node.js | SaaS API and domain logic | A modular backend structure maps well to facilities, rentals, payments and documents. | Module boundaries must be maintained consistently as the product grows. |
| PostgreSQL + Prisma | Transactional model and rental relationships | A relational database maps operator, unit, booking and payment relationships well. | Model changes require controlled migrations and compatibility with historical data. |
| Redis | Caching and supporting processes | It reduces repeated reads and supports short-lived technical state. | Cache must not replace the persistent source of truth for rentals. |
| Stripe and document services | Payments, formalisation and files | Dedicated integrations connect the business flow with specialised services. | The backend must handle webhooks, delays, retries and idempotency. |
Integrations and data flows
Stripe
Rentya ↔ payment providerOnline payments and settlement states connected with the rental.
Business state is updated after a confirmed event, with retry and idempotency handling.
Signature / document service
Rentya → document → signature / fileFormalising rental terms within the same workflow as the booking.
The process stores document state and does not assume immediate integration success.
S3 / Blob Storage
Rentya ↔ file storageStoring generated documents and rental-related files.
File references remain in the application model and access can be controlled separately.
Facility integrations
Rentya ↔ operator systemOptional connection of the digital flow with access or other deployment-specific automation.
The integration is deployment-specific and does not change the core unit and rental model.
AI, security and reliability
Data access control
Operator and tenant roles receive access only to functions and data required in their context.
State consistency
Availability, booking, payment and rental changes are controlled transitions rather than independent UI flags.
Integration idempotency
A repeated webhook or retry should not create a second payment, document or state change.
Data durability
Transactional data and document references remain in the persistent model independently from cache and supporting processes.
Configuration isolation
Deployment branding and rules are separated from the shared rental lifecycle, reducing the risk of accidental cross-configuration impact.
Implementation, testing and release
- 101 — Discovery
Define the reusable self-storage model and boundaries of operator configuration.
- Entity and relationship map
- Booking and rental lifecycle
- Operator and tenant surface scope
Result: A product model independent from a single screen or deployment was established.
- 202 — SaaS core
Build API, data and operator workflows for facilities, units, bookings and rentals.
- Data model and migrations
- Backend modules
- Operator panel
Result: Core self-storage logic operates from one source of truth.
- 303 — Formalisation and billing
Connect documents, signature, payments and recurring charges with the rental lifecycle.
- Document flow
- Payment integration
- Settlement states
Result: A booking can progress to active rental without losing data and settlement context.
- 404 — Self-service
Expose web and mobile customer surfaces using the shared logic.
- Tenant portal
- Mobile layer
- Shared API contracts
Result: Operator and tenant work with the same rental state through different interfaces.
- 505 — Deployment configuration
Prepare the core for white-label use, pricing changes, branding and operator integrations.
- Product configuration
- Pricing and promotion rules
- Integration points
Result: The platform can be adapted to a specific operator without copying the entire rental logic.
Lifecycle testing
Scenarios cover transitions from an available unit through booking, formalisation and payment to active and terminated rental.
Availability testing
Booking conflicts, unit-state changes and consistency across channels using the same API are tested.
Integration testing
Payments, documents and files are tested for delays, failures and repeated events as well.
Configuration testing
Branding, pricing and deployment-rule changes must not break the shared rental model.
Controlled releases
Domain changes and data migrations are released in a way compatible with existing rental records.
What confirms the project description
P1-E1 deliberately does not publish earlier percentage-based values attributed to Rentya because Polish and English labels did not describe the same metrics and the repository contains no approved baseline, measurement period or analytics export. Public outcomes are therefore presented as supported product scope, domain relationships and implemented system capabilities.
| Scope | Basis | Reference | Confirmation | Interpretation boundary |
|---|---|---|---|---|
| Rentya uses a shared architecture for operator and tenant channels. | architecture diagram | RT-01 — product architecture diagram | Confirmed in the product | The diagram describes logical layer responsibilities rather than the complete production infrastructure topology. |
| The process treats booking, formalisation and active rental as one lifecycle. | process diagram | RT-02 — rental lifecycle | Confirmed in the product | The diagram shows primary states and does not represent every operator-specific exception. |
| The data model distinguishes operator, locations, zones and storage units. | domain diagram | RT-03 — operator and facility model | Confirmed in the product | The public material simplifies relationships and does not disclose the full database schema. |
| Documents, signature and payment are part of rental formalisation. | workflow diagram | RT-04 — payments and documents | Confirmed in the product | The material does not claim one signature provider for every deployment. |
| Operator panel, tenant portal and mobile can use one data model. | surface diagram | RT-05 — product surfaces | Confirmed in the product | Interface scope can differ between specific product configurations. |
| The platform separates the shared core from operator white-label configuration. | configuration diagram | RT-06 — white-label model | Confirmed in the product | The diagram supports the product architecture direction but does not mean every possible configuration is already deployed in production. |
How to read this information
- No approved baseline for handling-time reduction.
- No analytics source for a percentage reduction in manual work.
- No basis for publishing 100% online process coverage as a business KPI.
- No approved testimonial attributable directly to the Rentya product.
- White-label deployments can use different modules and integrations.
Process change, decision consequences and lessons
| Area | Before | After | Business impact |
|---|---|---|---|
| Data model | Facility, unit, booking and settlement can live in separate tools. | A shared domain model connects them in one lifecycle. | Fewer inconsistencies across channels and operational state. |
| Availability | A sales channel may not reflect the current unit state. | Booking and availability use a shared source of data. | More consistent unit presentation to operator and customer. |
| Formalisation | Document, signature and payment are separate steps outside the main record. | Each formalisation element is connected with the booking and rental. | Clearer process state and less manual data reconciliation. |
| Channels | Each new interface can require a separate implementation of rules. | Operator, tenant web and mobile use the shared API. | Additional channels can evolve without duplicating the rental lifecycle. |
| Deployments | A new operator means copying product and rules. | The core is separated from white-label and configuration layers. | Greater potential to reuse the product architecture. |
Shared core instead of separate operator applications
- Alternative
- Building an independent system for each operator.
- Trade-off
- The core requires stricter configuration modelling and domain boundaries.
- Rationale
- It allows the product to evolve without copying core rental rules.
One source of truth for availability
- Alternative
- Separate availability in widgets and panels.
- Trade-off
- More operations must go through the central API.
- Rationale
- Unit consistency matters more than local simplicity of one channel.
Stateful rental lifecycle
- Alternative
- Loose set of flags and operator notes.
- Trade-off
- Adding a new state requires deliberate transition design.
- Rationale
- A long-running rental requires an unambiguous history and business conditions.
White-label configurability
- Alternative
- Hard-coding one operator’s rules directly in the product.
- Trade-off
- Configuration requires validation and testing of setting combinations.
- Rationale
- Separating product from implementation strengthens the platform as SaaS.
Key lessons learned
- In self storage, the unit and availability model should be defined before sales screens are designed.
- The rental lifecycle should cover the period after payment rather than ending at checkout.
- Documents and settlements belong to the rental domain rather than acting as context-free add-ons.
- A shared API for operator and customer reduces inconsistency between channels.
- White-label works best when it configures the operator model rather than copying the whole product codebase.
- Business metrics should be published only after baseline, measurement period and source are defined.
Which organisations this model is relevant for
Self-storage operators
Companies managing one or more locations that want to connect online sales with rental operations.
Networks expanding locations
Organisations that need a shared unit, pricing and rental model while preserving local configuration.
White-label products
Companies that want to deploy one core under different brands and operator configurations.
PropTech with recurring billing
Products combining a physical asset, booking, documents and long-running billing.
Related expertise and services
Web application development
Architecture of operational panels and SaaS applications built around business processes.
Mobile app development
Tenant mobile layer using the shared backend and product lifecycle.
MVP and SaaS product development
Discovery, domain modelling and iterative product growth from core to additional modules.
Next.js / React
Frontend technologies for operator and customer interfaces.
Node.js
Backend for API, integrations and platform domain processes.
GizoBOX — white-label implementation
A separate case study shows how the self-storage model was adapted to the realities of a specific operator and facility.
Gizo Rental
Another example of a system connecting customer self-service with the operational lifecycle of a physical asset.
Self-storage mobile app — search and booking
Article describing the mobile layer and offer discovery in the Rentya ecosystem.
Planning your own self-storage management platform?
We can help define units, bookings, rentals, payments and operator configuration and turn that model into a production web and mobile system.
Key confirmed facts
The following statements summarise the confirmed product scope and contain no unapproved growth data.
- 1
Softech designed and develops Rentya as a SaaS platform for self-storage operations.
- 2
Rentya models operators, locations, zones and storage units together with their availability.
- 3
The platform connects unit booking with documents, signature, payment and active rental.
- 4
Operator panel, tenant portal and mobile layer can use a shared API and domain model.
- 5
Rentya supports configurable pricing, discounts and rules connected with the rental process.
- 6
The product scope includes online payments and recurring-charge logic related to active rentals.
- 7
Documents and file references are connected with a booking or rental rather than maintained as a separate context-free process.
- 8
The architecture separates the shared Rentya core from white-label branding and deployment configuration.
- 9
GizoBOX is a separate operator implementation and should be presented as its own case study rather than as a synonym for the Rentya platform.
- 10
The public Rentya case study does not publish earlier percentage-based KPIs without an approved baseline and analytics source.
- 11
The platform is designed to extend with additional integrations, business rules and customer channels.
Visual evidence
The diagrams present confirmed product scope and workflows described in this material. They are not mock-ups or claims of undocumented outcomes.
FAQ
How is Rentya different from a single self-storage implementation?
Rentya is the reusable SaaS platform core. It models facilities, units, availability, bookings, rentals, documents and billing in a configurable way. A white-label implementation such as GizoBOX adds its own brand, facility structure, rules and integrations.
Does Rentya support multiple locations and different unit types?
The product model includes locations, zones and units with their own availability, attributes and pricing rules, allowing different facility structures to use the same rental lifecycle.
What does the rental process look like in Rentya?
The flow connects unit selection, booking, tenant data, documents, signature, payment and activation of the rental. Later events such as extension, charges or termination remain part of the same model.
Does the platform support recurring payments?
Yes. The product scope includes online payments and recurring-charge logic connected with active rentals and settlement status.
Can Rentya be deployed as a white-label product?
Yes. The architecture separates the shared domain core from operator-specific configuration so branding, facility structure, pricing and selected integrations can be adapted.
Do tenants have a portal and mobile experience?
Rentya includes tenant self-service on the web and supports a mobile layer. Both surfaces use the same booking, document, payment and active-rental model.
What operational data can the platform manage?
The scope includes unit availability and occupancy, rental states, payments, documents, pricing and operational or financial reporting.
Can Rentya integrate with access-control systems?
The architecture supports external facility-service integrations, including access-control layers when required by a specific operator deployment.
Can the platform be extended further?
Yes. Its modular architecture is designed to add business rules, reporting, integrations and channels without rebuilding the rental domain from scratch.
