Product engineering across Flutter mobile, Next.js web, React admin, ASP.NET Core APIs, MariaDB data model, payments, notifications, media, and operations support
4
connected product surfaces
5
post-approval verification steps
2
regional currency modes
RBAC
admin and customer access boundaries
Timeline
Multi-platform modernization, transaction workflow expansion, and reliability hardening
A rental marketplace needed trust, payments, and operations in one flow
The product had to support item listings, purchase and rental intent, owner approval, identity and payment readiness, regional pricing, promotions, notifications, and administrative oversight without splitting the customer journey across disconnected tools.
Rental approval created multi-party follow-up work for renters and owners
Payment, payout, identity, email, and agreement readiness needed to be visible before handoff
Regional pricing and currency display had to stay consistent across mobile screens, APIs, and admin tools
Administrators needed operational control over items, users, promotions, content, transactions, and support diagnostics
A connected marketplace operating system for rentals and purchases
RentLoop coordinates mobile customer flows, public web content, back-office administration, and backend services around the same marketplace state so users and operators can move from listing to transaction with clearer checkpoints.
Flutter mobile app for discovery, item details, profile, referrals, pending requests, verification steps, and payments
ASP.NET Core API layer for marketplace entities, transactions, notifications, currency handling, authentication, and admin operations
React administration console for dashboard metrics, items, users, promotions, categories, content, and operational support
Next.js public website and resource content to explain the marketplace, safety model, earning potential, and app value proposition
Product surfaces
What the platform brought together
The work spanned core product operations, daily user workflows, data-heavy coordination, and resilient platform management.
Rental approval and verification flow
Once an owner approves a request, both parties receive clear next steps before the rental exchange moves forward.
Pending task records connect users to the active transaction and track agreement, payment, bank, ID, and email readiness
A unified status response combines task state with user verification data and completion percentage
Duplicate-prevention logic avoids creating repeated pending tasks when notifications are acted on more than once
Marketplace mobile experience
The customer app supports listing discovery, location-aware browsing, item detail actions, profile workflows, referrals, payments, and ongoing transaction state.
Flutter feature modules use clean architecture, Bloc and Riverpod patterns, typed models, and reusable services
Item creation, search, category filtering, pending requests, notifications, and profile flows stay connected to the API
Integration tests and test keys support repeatable validation for authentication, home, payment, and approval flows
Payments, currency, and promotion systems
The platform handles regional payment behavior, user currency preferences, plan access, discounts, commission messaging, and transaction totals.
Currency preferences flow from API to mobile state so supported prices display consistently
Payment and membership workflows were localized for regional gateway behavior and transaction rules
Promo codes, plan benefits, protection-plan pricing, and seller earning calculators support marketplace monetization
Admin and content operations
Operators can manage marketplace health from a back-office console instead of relying on manual database changes.
Management tools cover categories, items, promotions, static content, plans, reviews, disputes, and user controls
Operational diagnostics, logging visibility, debug tools, and migration notes make support work easier to investigate
Buyer priorities
What mattered most to the people evaluating the platform
Prospective buyers want to know whether the work solved real workflow, adoption, reliability, data, and operations problems. These priorities shaped the product decisions.
Trust before handoff
Rentals need more safeguards than simple ecommerce because two parties coordinate payment, identity, agreements, delivery, and return state.
Agreement, payment, bank, ID, and email readiness are tracked as explicit steps
Both renter and owner workflows stay tied to the transaction rather than generic account state
Completion status gives the app a clear way to explain what remains before final payment or handoff
Regional marketplace fit
The marketplace had to handle local pricing expectations, currency display, payment gateway behavior, and location-based discovery.
Currency utilities and API conversion fields keep supported amounts readable across screens
Location data supports discovery and item relevance without making users repeat the same choices everywhere
Gateway-specific payment behavior is contained behind service flows instead of spread through every UI
Operator control
Marketplace teams need high-confidence admin tools because item quality, user trust, promotions, disputes, and payment status all affect daily support.
Admin views give operators visibility into items, users, transactions, rentals, purchases, and dashboard metrics
Content and promotion controls let the team adjust marketplace messaging without a full engineering release
Logging, debug views, and migration records reduce guesswork during support and release work
System model
How the platform connects roles, workflows, and product surfaces
The product architecture brings every role into the same operating model, with shared data moving cleanly between web, mobile, media, and notification layers.
Four surfaces, one marketplace
Mobile app, public web, admin console, and API services coordinate item, user, transaction, payment, and content state.
Approval to handoff workflow
A rental moves from request and owner approval into agreement, verification, payment readiness, delivery, return, and completion.
Marketplace role boundaries
Renters, owners, admins, and support teams interact with shared records through role-appropriate workflows.
Technology
The Stack We Used And Why
The stack section is written for buyers who need to understand the product architecture, operational trade-offs, and long-term maintainability of the system.
Mobile app
Used for the primary customer experience where discovery, verification, notifications, payments, profiles, and cross-platform delivery matter.
The customer experience needed one codebase for rental, purchase, verification, payment, notification, and profile workflows across mobile platforms.
Flutter kept mobile UI patterns consistent while the product evolved
Bloc and Riverpod supported predictable state for auth, currency, home, and transaction flows
Patrol and integration-test helpers made critical customer paths easier to validate repeatedly
Why ASP.NET Core For Marketplace Rules
The domain depended on many stateful rules around approval, verification, payments, users, notifications, and admin actions.
Service and repository layers kept transaction rules out of UI clients
JWT and role checks supported customer and admin access boundaries
Hangfire, NLog, and migration tooling supported operational reliability over time
Why A Separate Admin Surface
The marketplace needed operator workflows that are denser and more permissioned than the customer-facing app.
React and Vite supported a fast, focused admin console for support and marketplace management
Dashboard and management services gave operators real visibility into marketplace state
Content and promotion tools reduced the number of routine changes that required engineering intervention
Delivery
How the product came together
The work moved from domain modeling to core platform delivery, mobile adoption, and operational hardening.
1
Model marketplace state
Clarify how users, items, rentals, purchases, approvals, transactions, verification tasks, and payments should interact.
2
Connect mobile and API flows
Build the Flutter screens, typed models, API services, authentication state, currency utilities, and transaction workflows.
3
Add operations and monetization
Expand the platform with admin management, plans, promotions, protection pricing, referrals, content, and dashboard visibility.
4
Harden critical paths
Improve payment handling, regional currency behavior, duplicate prevention, test coverage, logging, and deployment configuration.
Operational depth
What made the platform usable after launch
The strongest case studies are not only feature lists. They show how the system is operated, monitored, governed, and improved when real users depend on it.
Verification task orchestration
The rental approval flow coordinates account-level and transaction-level readiness before the handoff proceeds.
Pending task records connect each user to the relevant transaction
Status responses combine agreement, payment, bank, ID, and email readiness
Completion percentages and remaining-step lists give the UI a clear operating model
Admin diagnostics and controls
Marketplace operations were supported by dense admin tools rather than hidden scripts or one-off database changes.
Dashboard summaries for users, items, rentals, purchases, and financial activity
Management workflows for categories, promotions, static content, plans, reviews, and disputes
Debug and logging improvements for payment, notification, and location-related issues
Payment and currency safety
The implementation kept currency display, regional payment rules, and transaction totals visible across API and mobile surfaces.
Supported currency metadata and user preferences shape API responses and mobile formatting
Payment verification work protected realistic regional totals from schema and unit mismatches
Gateway behavior was localized so the rest of the product could rely on consistent transaction state
Results
The measurable and observable lift from the work
The strongest improvements are the ones a buyer can connect to daily work: fewer disconnected tools, safer operations, clearer workflows, and more reliable product behavior.
5 steps
Clear Rental Readiness
Agreement, payment setup, payout setup, ID verification, and email confirmation became trackable checkpoints instead of implicit support assumptions.
4 surfaces
Connected Product System
Mobile app, admin console, public website, and backend APIs were aligned around the same marketplace and transaction model.
2 currencies
Regional Price Display
The product supported user-preferred currency display for marketplace prices, protection plans, and payment summaries.
Admin-managed
Marketplace Operations
Items, categories, users, promotions, plans, content, and diagnostics became manageable through operator tools.
Outcome
A stronger operating system for rental marketplace and transaction platform
The platform reduced tool fragmentation and gave each role a clearer path from live activity to day-to-day action.
A connected rental marketplace foundation instead of fragmented mobile, web, admin, payment, and support tools
A clearer post-approval journey that explains verification, payment readiness, agreement state, and remaining steps
Regional pricing and currency behavior that stays consistent across API responses and mobile UI
Operational visibility for marketplace teams managing items, users, transactions, promotions, content, and support issues
FAQ
Frequently Asked Questions About RentLoop
Answers about the rental marketplace and transaction platform scope, platform model, technology choices, operational workflows, and related build patterns.
What Kind Of Marketplace Does RentLoop Represent?
RentLoop represents a rental and purchase marketplace with mobile discovery, owner approval, verification tasks, payments, promotions, regional pricing, public content, and admin operations.
Why Was Custom Software Needed For This Rental Model?
The product needed transaction-specific approval, identity, agreement, payout, payment, currency, notification, and admin workflows that would be difficult to keep consistent with generic marketplace tools.
How Did The System Improve Trust In The Rental Flow?
The platform made trust steps explicit by tracking agreement acceptance, payment setup, payout readiness, identity verification, and email confirmation before the final rental exchange.
Can This Pattern Support Other Peer-To-Peer Marketplaces?
Yes. The same architecture can support equipment rentals, local services, resale marketplaces, membership-led commerce, and multi-party transaction platforms that need approvals, payments, and operator controls.
Related services
Build a similarly ambitious product without starting from a blank page.
We can help scope the web, mobile, AI, media, and operating layers needed for your own platform.
