Shipping Fast + Shipping Right
In August 2025, Rently assembled a small cross-functional team to quickly validate a new product idea: Rently Pay.
The hypothesis was that offering the right perk could convince tenants to pay rent on our payment rails.
I was the product designer on the team. We had a few months, limited dev resources, and a mandate to get a signal fast — one we could communicate to investors.
3 months
Timeline
Sep 2024 – Dec 2024
Designer
My Role
Research, design, experiment design
P0 → P1
Stage
Prelaunch → Launch
2x CTR
Impact
Landing page to sign-up flow
01
The Problem I Walked Into
The team's first move was to build a landing page to test which perk resonated most with tenants. Before I could contribute a design, the developer had already vibe-coded and launched a page. When I reviewed it, I flagged an issue immediately.
The middle card in our Select Plan section had a "Most Popular" pill attached to it, with a green border and green-accented CTA button. The entire point of the landing page was to find out which perk users truly preferred. Labelling one option as most popular before we had any data would skew users toward it, and we'd walk away with results that told us nothing real.
I raised this with the team — the experiment bias issue was about data integrity. If we were going to run a test, it needed to produce a signal we could actually act on.
02
The Redesign
The experiment concluded after a short run, with limited traffic and inconclusive results, when our CEO made the call to move forward regardless, based on external conversations with partners and investors. The product direction was set: tenants would pay rent through us and earn credit card miles and/or Max Miles on their rent payments.
With a clear product to design for, I built out the product's V1 landing page, informed by best practices and early customer queries. My priorities were straightforward: explain what Rently Pay does, answer the questions we were already fielding from early customers, and give people a reason to trust us with their rent.
Landing page V1 was significantly more educational than the vibe-coded experiment landing page — but it was also presenting a lot of information at once.
That's where the user research interviews came in. As we continued onboarding more customers, I ran interviews and brought users back to the landing page to get their reactions. A few things stood out:
Users wanted to know what their miles could get them (concrete examples of flights, hotels), not the number of miles they'd accumulate. So I rebuilt the calculator to show redemption outcomes instead of mile counts.
Users weren't particularly reassured by photos of the Rently team or mentions of our market presence. What they actually wanted to know was whether we'd pay their landlord on time and handle their money securely. I replaced the team section with payment security and infrastructure trust signals.
Landing page V1
Removed in V2
The three pricing plan cards (which I'd hypothesised might overwhelm users) turned out to be well understood. But they were doing the same job as the calculator, so I removed them and let the calculator do all the work.
Mixpanel data showed that customers were spending the most time playing with the calculator anyway.
03
Outcomes + Reflection
Click-through rate doubling between v1 and v2 was a clear signal that user research was translating into real design decisions.
But in a team under pressure to move fast, I'm happiest about pushing back on a page design that was running a biased experiment from the get go. I'm a strong believer that data that isn't trustworthy isn't useful to anyone — it just creates false confidence. I think that's one of the most important things a product designer can bring to an early-stage team: making sure that in the rush to get results, we're actually getting real ones.
The initial experiment ultimately produced an inconclusive signal, but the product moved forward anyway, shaped by partner conversations and investor appetite. That was its own lesson, and gave me a lot more empathy for the pressures and inputs that sit outside the design process. It's something I can hopefully bring into every project moving forward — being able to evaluate a decision from the user's perspective and the business's at the same time.