Rental Force

Rental Force — Construction Machine Rental Marketplace (User App + Provider App)

Rental Force is a two-sided marketplace built with Flutter, consisting of two separate mobile applications published on the Google Play Store: a User App for contractors and site managers who need to rent heavy machinery, and a Provider App for machine owners who want to list their equipment and bid on rental requests.

The platform covers the complete rental lifecycle from request creation and real-time competitive bidding, through delivery coordination, active rental tracking, and machine return with issue reporting.

The Problem

The construction equipment rental market operates almost entirely through personal networks and phone-based negotiations. A site manager who needs three excavators and a crane for an upcoming project has no reliable way to broadcast that requirement to multiple providers simultaneously, compare bids side by side, or track the status of their rentals in one place. On the other side, machine owners with idle equipment have no structured channel to discover active rental demand beyond word of mouth.

Rental Force solves both sides of this problem at once. Users post structured rental requests and receive competing bids in real time. Providers get direct visibility into active demand, place bids competitively, and manage their entire rental business from a single mobile interface. The result is a transparent, efficient marketplace where pricing and availability are determined by the market rather than by who you know.

What I Built

User App: Request and Bidding Flow

I built the full request creation experience where users can generate rental requests for multiple machines in a single submission, specifying site requirements, machine type, and duration. Once a request is live, incoming bids from verified providers appear in real time. Users can compare offers side by side on price, provider profile, and availability, then accept the most suitable bid to confirm the rental. The entire flow from request to confirmed booking happens within the app with no manual coordination required.

Provider App: Listings, Bidding, and Rental Management

I built the provider-facing application as a complete business management tool. Providers can list machines available for rent with full details and pricing, receive incoming rental requests from users, and place competitive bids directly from the app. Once a bid is accepted, the app guides providers through delivery confirmation, active rental tracking, and the return process. I also implemented an issue reporting feature that allows providers to upload images or videos when a problem is found during machine return, creating a documented record of the machine's condition.

Real-Time Bidding System

The bidding layer is the technical core of the platform. I integrated real-time data updates so that users see new bids as they arrive without needing to refresh, and providers receive immediate feedback when their bids are viewed or accepted. Push notifications were implemented on both sides to keep all parties informed at every stage of the rental lifecycle, including bid placement, acceptance, delivery confirmation, and return.

Rental Lifecycle and Status Tracking

I built a unified status tracking system that moves a rental through clearly defined states: requested, bid received, bid accepted, delivery in progress, active, and completed. Both apps reflect the same state in real time, so users and providers always have a consistent view of where a rental stands. This was particularly important for the provider app, where operators may be managing multiple active rentals simultaneously.

Location Sharing

Both apps request and share location data, which I integrated to support delivery coordination and site-based context for rental requests. Location is surfaced where relevant in the rental flow without being intrusive to the core booking experience.

Technical Highlights

• Delivered two separate Flutter applications from a single development effort, sharing design patterns and business logic conventions across both codebases while keeping the apps fully independent at the package and release level.

• Implemented a real-time bidding feed on the user side and real-time request notifications on the provider side, requiring careful handling of live data subscriptions and UI state reconciliation when new bids arrive mid-session.

• Built a multi-state rental lifecycle engine that coordinates status transitions across two separate apps and a shared backend, ensuring both sides always reflect the correct current state without conflicts.

• Integrated push notifications for both apps covering bid events, acceptance confirmations, delivery updates, and return alerts, with notification-related bugs identified and fixed in a subsequent release cycle.

• Implemented media upload for issue reporting on the provider side, allowing images and videos to be captured and attached to a return record directly within the app.

• Both apps share location access (Shares Location declared on Play Store) for delivery and site coordination, with permissions handled explicitly at the Flutter layer for both Android and iOS targets.

• All data is encrypted in transit with no third-party data sharing, and both apps support data deletion requests per Play Store policy requirements.

• Shipped iterative updates including a full UI refresh, performance improvements, and stability fixes, demonstrating an active post-launch maintenance cycle on both apps.

Key Decisions

The most consequential architectural decision was building two separate Flutter applications rather than a single app with role-based switching. The user and provider experiences are fundamentally different in their mental models, navigation structures, and data needs. A contractor arriving to book equipment has completely different goals from a machine owner arriving to manage their listings and bids. Keeping them as separate apps allowed me to design each experience around its user without compromise, and it also simplified the Play Store release process, versioning, and targeted crash reporting for each audience independently.

For the real-time bidding layer, I chose to drive UI updates through a live data subscription model rather than polling. In a bidding context, latency matters: a user who sees a new bid 30 seconds late may have already made a decision based on stale information. Designing the state management layer to respond immediately to incoming bid events and reflect them in the UI without a full screen reload was a deliberate investment in product quality that made the bidding experience feel responsive and trustworthy rather than sluggish.

The issue reporting feature with media upload on the provider side was a decision driven by real-world operational risk. Construction equipment is high-value, and disputes over damage or wear at the time of return are a common pain point in rental businesses. By building structured issue reporting with photo and video evidence directly into the return flow, I gave providers a lightweight but legally defensible way to document machine condition at every handoff. This feature required careful handling of file size, upload progress feedback, and error states on potentially slow mobile connections at construction sites.