Designing for Growth in
Flent Secured App
How we improved adoption and onboarding for a new rent payment product, growing the waitlist by 3.3× and monthly rent processed by 8×.
- Role:
- Sole Product DesignerWebsite Design & Development
- Team
- 1 Product Designer,1 Engineer
- Timeline
- Jan to Mar 2026
01 / A new product,
three weeks to launch
Flent Secured is a rent payment platform that gives tenants 1% cashback for paying rent on time, while landlords get free rental protection of up to ₹1.5 lakh. For Flent, it was also a way to build direct relationships with tenants and landlords, rather than relying entirely on brokers and listing platforms.
We had a pre-Series A announcement coming up, and Secured was one of the products we wanted to launch alongside it. The catch was that we had just three weeks to get something out.
We started with a waitlist app to gauge interest, followed by another three weeks to build out the experience. Since rent payments happen monthly, missing that window meant potentially waiting another month before users could make their first payment.
What I owned
I was the sole product designer, working closely with the founders on scoping, designing the app, and building the website. After V1, I worked with CX to understand where users were struggling and with engineering to refine V2 during implementation.
02 / People were interested. Getting them to use it was harder.
The first launch brought in over 200 waitlist signups on day one, with very little marketing spend. The 1% cashback was an easy hook. People were already paying rent every month, so getting something back made sense.
But once users started onboarding, we noticed a few problems.
55% dropped off
before uploading their rental agreement.
People didn’t understand
why we needed their documents.
Manual Verification & Approval Delays
left users unsure of what was happening.
Some assumed
Secured was only for people living in Flent homes.
For someone already paying rent through UPI, we were asking them to install another app, sign up, upload an agreement, and wait for approval. And we weren't explaining the process particularly well.
What did we need to fix?
After reviewing feedback with CX and looking at the onboarding journey, we narrowed our focus to two goals.
Comprehension:
Help users understand the product, verification requirements, and what happens next.
Adoption:
Reach more relevant renters and make it easier for them to get started.
There was a business constraint too. We needed enough rent payments going through Secured to make the payment gateway economics work. So the goal wasn't just to grow the waitlist. We needed more people to make their first successful rent payment.
03 / Looking at the journey differently
Before designing anything, I went back to how people were discovering Secured. Our main touchpoints were social media, physical events, merchandise, and the website. Most of these eventually led to the App Store.
Looking at this, I realised we were asking people to do quite a bit before we could even capture their interest. Someone could visit our website, understand the product, and leave without signing up. Even after installing the app, they still had to complete several steps before joining the waitlist. Two opportunities stood out.
Before the app:
Could we capture interest and identify eligible renters earlier?
Inside the app:
Could we make onboarding easier to understand and reduce uncertainty?
With a small team and a short timeline, we decided to focus on these opportunities rather than build entirely new acquisition channels.
04 / Making onboarding
easier to understand
One of the biggest drop-offs in V1 happened before users uploaded their rental agreement. From CX feedback, people weren't clear about why we needed it or what happened after submission.
In V1, verification was manual. Users would upload their agreement and wait, with little visibility into its status.
For V2, I added more context before the upload, explaining why we needed the document and what it would be used for. We also linked to relevant regulatory information for users who wanted to know more.
Alongside this, we introduced an automated parser that extracted agreement details and checked them against our eligibility criteria. I designed the experience to make the verification status visible instead of leaving users wondering what was happening.
And... Did it work?
After launch, the CX team followed up with the same set of users. We saw a 40% reduction in questions about why the rental agreement was needed. That was encouraging. The additional context seemed to help, but it wasn't a complete fix. Some users still needed clarification.
05 / Turning the website into a way to find eligible renters
While mapping the discovery journey, I noticed the website was already doing a lot of the work of explaining Secured. But we still asked people to download the app before learning much about them.
So I created an interactive map showing neighbourhoods across Bangalore. Users could find their building, enter their rent amount and BHK configuration, and check whether they were eligible for Secured. We could have used a regular waitlist form. It would have been quicker to build, but wouldn't have given us the same property-level context.
The map also made the experience more relevant. Instead of filling out another lead form, people were checking whether Secured was available for their home.
And... Did it work?
During V2's launch week, the map generated around 15 qualified leads who signed up quickly through invite codes. That group accounts for approximately 20% of our current active users.
For something we'd built to capture better-qualified interest before app installation, this was a promising result.
06 / A few other decisions
that helped us ship
Not everything needed a complete redesign. Some decisions were about making better use of what we already had, or deciding what could wait.
Keeping the landlord experience lean
We initially considered a fuller landlord experience with payment history, assurance details, and a dashboard. But when we broke down why landlords needed Secured, the immediate need was smaller: understand the product and complete the verification required to receive payments.
Around 80% of payments were through UPI, with 20% through credit cards. Given the timeline, we prioritised the landlord onboarding needed for the credit-card flow.
Tenants could invite landlords to a page explaining Secured and its benefits. I worked with marketing on the content, and landlords could then verify their phone number, confirm bank details, and complete the required onboarding.
We left the full self-service experience for later. That gave us more time to focus on the tenant journey.
Making the waitlist more useful
Instead of ending onboarding with a generic confirmation, we showed the waitlist count and what users could expect once they were approved.
Since we were rolling out to a limited number of users, this helped explain the wait and kept the benefits visible.
Using invites and referrals
We introduced invite codes to manage access and reach renters in targeted residential communities, which were also distributed offline at selected buildings. We also introduced referrals, hoping existing users would help us reach other renters.
But referrals gave us an interesting learning. Only around 10% of referred users qualified for Secured. Even with a good incentive, we didn't see as much participation as we'd hoped.
Looking back, we underestimated how much eligibility affected referrals. People could recommend Secured to friends, but that didn't mean those friends would qualify.
07 / What changed?
~1000
Waitlisted users
~60*
MAU (Product on Hold currently*)
~₹40 Lakhs
Monthly Transactions
~₹66,000
Average Rent
~₹2 Crores
Lifetime Transactions
These results came from a combination of product changes, marketing, acquisition, and operational improvements. I wouldn't attribute all the growth to design alone, but V2 addressed several of the problems we'd identified after the first launch.
08 / A few personal wins
Beyond the product and growth work, there were a few things I was particularly happy to have shipped.
A new design language
Between V1 and V2, I revamped the design language based on early stakeholder feedback, revisiting typography, colours, components, and the overall visual direction.
And yes, I designed in dark mode after it was unanimously voted for by the team :p
Design tokens for AI-assisted implementation
I built a design token library to help carry our design decisions into frontend development.
With AI becoming part of how we built the product, I wanted a more consistent way to define colours, typography, and other design properties instead of repeatedly correcting them during implementation.
Designing and building the website
I designed and built the Secured website, working across the visual direction, storytelling, interactions, and frontend implementation.
It had to explain a new product, make the benefits easy to understand, and give tenants and landlords a clear way to get started.
Live website: https://flent.in/secured
09 / Looking back
Getting Secured launched and getting people to use it turned out to be two different problems. V1 was about shipping within a very short timeline. V2 was about understanding what wasn't working and figuring out where to spend our effort.
Some decisions worked better than others. The agreement changes reduced confusion but didn't eliminate it. The website map brought in qualified users, while referrals showed us that reaching more people didn't necessarily mean reaching the right people.
What stayed with me was how much of the work came down to prioritization. With a small team and limited time, deciding what not to build mattered just as much as deciding what to build.