Skip to main content
Back to selected work

Marketplace / Booking and Payments

Rent N Roll

A pre-launch marketplace that gives camera owners and renters one booking to follow from available dates and verification through payment, handoff, and return.

Rent N Roll browse page showing DSLR, mirrorless, camcorder, and action-camera categories.
Source: Live productThe marketplace starts with category-led discovery so renters can narrow the equipment they want to browse.

Public evidence

These reviewed public sources support the adjacent build claims; they do not imply adoption or unmeasured outcomes.

Problem

Target user
Camera owners listing equipment and renters looking for the right gear on specific dates.
Challenge
Both people need to know what gear is available, who has been verified, what has been signed and paid, and whether the equipment is ready for handoff or return.
Why it mattered
If any of those details disagree, the owner and renter can act on different booking information or lose sight of the next required step.

Constraints

  • The marketplace is still pre-launch, so the build proves feature coverage—not adoption or live rental volume.
  • PayMongo confirms payment and deposit changes asynchronously through webhook events.
  • The initial data layer contained 24 untyped database queries across a growing booking journey.

Solution

One booking connects the listing, renter, required checks, money movement, and physical exchange so each side can see what happens next.

  1. Owners publish equipment with photos, daily pricing, deposit details, and available dates.
  2. Renters choose available gear, complete the supported identity verification and contract steps, and request the booking.
  3. That booking carries PayMongo payment and deposit updates through handoff confirmation and return.
Rent N Roll equipment detail page with product photos, daily price, deposit amount, booking notice, and availability calendar.
Source: Live productThe listing view keeps product media, price, deposit information, booking constraints, and availability in one decision point.

Engineering Decisions

  1. Fix ambiguous database calls before launch

    Constraint
    Twenty-four untyped database queries made it easy for application code and stored data to disagree.
    Decision
    Move every identified query behind typed Supabase RPC patterns backed by generated types.
    Rationale
    Make booking-data changes reviewable and catch mismatched fields before they reach an owner or renter.
    Validation
    All 24 identified queries were migrated to the typed pattern.

  2. Let PayMongo confirm money movement

    Constraint
    The interface can start a payment, but it cannot prove that PayMongo completed it.
    Decision
    Integrate payment and deposit handling through PayMongo webhooks.
    Rationale
    Update the booking from provider-confirmed events instead of assuming a successful button click.

Outcomes

Product and delivery

  1. Full lifecycle

    One booking, end to end

    Connected listings and availability to verification, contracts, PayMongo payments and deposits, handoff confirmation, and return.

Implementation evidence

  1. 24 queries

    Safer database changes

    Moved 24 untyped database queries to typed Supabase RPC patterns so mismatched application and database assumptions can be caught earlier.

Learnings and Next Steps

What I learned

  • The difficult part of rental software is not the listing page; it is keeping two people aligned through every commitment and handoff.
  • A payment button shows intent, but the PayMongo event must confirm whether money actually moved.

What I would improve

  • Run the complete booking, payment, handoff, return, and exception paths with launch users before adding more marketplace scope.

What remains unvalidated

  • Because the marketplace is pre-launch, there is no verified rental volume, user adoption, or live payment history yet.