Case Study · Dozr

Renting heavy equipment
in under two minutes.

As a Product Engineer at Dozr, I built and shipped Instant Booking. Took the rental flow from sales-assisted to fully self-serve, and cut transaction time in half with 86% faster page loads.

Engineering · PM Marketplace Performance Full-cycle
📖 ~5 min read · Company: Dozr · Role: Product Engineer · Year: 2024

The Company

What Dozr does.

Dozr is a construction equipment rental marketplace. Contractors across North America use it to find and book heavy equipment (excavators, skid steers, boom lifts) from a network of suppliers, without having to call around for rates.

I was a Product Engineer there, which basically meant I lived at the end of the software development lifecycle. Specs came in, I built them, and I made the real-time calls on what actually shipped.


The Problem

Booking was anything but instant.

Renting heavy equipment isn't like booking a hotel. You're dealing with delivery windows, insurance requirements, fuel surcharges, site conditions. Lots of ways for things to go sideways if the details aren't locked in. So it made sense that customers went through sales to book. Sales would get on the phone, confirm everything with the supplier, and close the deal. It was reliable.

The problem was that it didn't scale. As Dozr grew, sales was spending most of their time on completely routine bookings that didn't actually need a person involved. Contractors were waiting hours, sometimes a full day, just to get a confirmation on something that should've taken two minutes.

The core tension

"Sales was the safety net that became the ceiling. The goal was to move routine bookings to self-serve without breaking the trust customers had built up."

And the platform itself was slow on top of that. Listing pages, checkout, all of it was sluggish. So customers were waiting on the software and the sales team at the same time.


Before & After

What changed.

Before
  • Submit a rental request
  • Wait for supplier to manually review
  • Receive a quote hours later (or not)
  • Accept and provide payment details
  • Wait for final confirmation
  • Slow page loads throughout
After
  • Browse available inventory in real time
  • See upfront pricing with no negotiation
  • Click "Book Now" on Instant-eligible listings
  • Confirm with payment in one step
  • Booking confirmed immediately
  • 86% faster page loads

What I Built

The four pieces that made it work.

01 · Eligibility Logic
Instant-eligible flagging
Built the backend logic so suppliers could flag specific equipment and date windows as Instant-eligible. Gave them control over what got the self-serve flow.
02 · Availability Sync
Real-time inventory state
Built a sync layer that kept availability current so customers could trust what they were seeing, no sales rep needed to verify it.
03 · Checkout Refactor
One-step confirmation
Rebuilt checkout from a multi-step quoting process into a single screen. Pricing, delivery, payment, done.
04 · Performance
86% faster page loads
Dug into the front-end bottlenecks on listing and checkout pages. Lazy loading, consolidating API calls, asset optimization.

Cross-Functional Work

Who I worked with.

I was heads-down in implementation, but this touched a lot of people:

Being at the end of the SDLC means you're the last person before it hits real users. That kept me pretty honest about what was actually shippable vs what just sounded good in a doc.


Results

2x faster. 86% leaner.

2x Faster transaction
completion
86% Reduction in
page load time
Drop in booking
abandonment rate
Supplier-side
opt-in adoption

After launch, suppliers who opted in saw higher booking rates, which got more of them to enable it for their inventory. It kind of snowballed from there.


Learnings

What I took away.

Specs look clean until you're in the code. You hit edge cases and API limitations that nobody planned for. A big part of the job was making those calls fast and communicating them clearly so the team could keep moving.

Performance needs to be built for, not cleaned up later. The 86% improvement didn't happen by accident. We prioritized it upfront because slow checkout breaks trust just as much as a broken flow does.

Replacing a human in the flow means the code has to actually earn it. Sales was there for a reason. Customers trusted that process. Instant Booking only worked because the reliability was genuinely there underneath it.

Want to dig into the details or talk about the trade-offs?

Message me Back to projects