Edvoy Stays
Building the accommodation layer Edvoy never had, from zero to $2M in one intake
4.5 Months
Product Designer
Zero to $2M profit on its 1st intake
4,000+ Active Agents
50,000+ Monthly students
The accommodation layer Edvoy never had. Zero to $2M in one intake.
Edvoy Stays lets recruitment agents find, compare and book verified student homes for the students they send abroad. The brief said “add accommodation search”. What it turned into was vendor API limits, multi-tier commissions, lifecycle automation and a payments layer nobody had planned for.
~$2M
profit in the first intake
4,000+
active agents booking
50,000+
students a month on the platform
4.5 mo
from brief to launch
A live rebuild of Edvoy Edge with sample listings. It plays on its own. Click it to search, filter and shortlist.
02 - The 30-second version
A product that ended at the offer letter
The challenge
Edvoy’s product stopped the moment a student got accepted. Finding somewhere to live, in a country they had never visited, was on them. Agents helped over email, provider portals and WhatsApp. Edvoy sat right next to that decision and had no part in it, no data and no revenue from it.
What I did
Designed Stays end to end on Edvoy Edge. Search near any university, plain-language room filters, comparison and shortlists, a booking flow with deposits and consent, a lifecycle tracker that syncs with provider APIs, automated commissions, and Flywire payments inside the booking.
My role
Owned product design across the Edge agent portal, mobile web, student app and CRM
Ran the early student and agent conversations that reshaped the room-type model
Worked with engineering on provider API limits and the local inventory mirror
Designed the commission, invoice and payout workflows with finance
Proposed the Flywire integration as a second revenue stream
The constraints
Providers set the rules: each API had its own data shape, inventory and booking windows, and the UI had to adapt to limits it didn’t control.
The buyer isn’t the resident: agents book, students live there, and both had to trust the same screen.
One intake window: miss the intake and the business waits another year.
Money moves by stage: commissions depend on provider agreement, agent tier, student tier and lifecycle stage.
The key insight
It looked like a marketplace brief. Underneath were four separate problems: student trust, agent workflow, provider infrastructure and finance. None of them could wait for phase two, so the booking flow was the front door and the lifecycle was the real product.
03 - Key decisions
Three calls that shaped everything after
Decision 01
Ask in plain words. Map to room types later.
In early conversations, students kept tripping on “ensuite”, “studio” and “non-ensuite”. Those words mean different things depending on where you grew up. So the filter asks three plain questions instead: private or shared bedroom, bathroom, kitchen. The system maps the answers to each provider’s room type in the background. Small change. It removed a layer of confusion that would have quietly leaked users all the way down the funnel.
Decision 02
Design with the API, not around it.
Casita had the most flexible API, so we prioritised it. Even Casita enforced fixed booking windows on its servers for some properties. Hiding that would have meant bookings that bounced back two days later. The tenancy picker shows only the windows a provider accepts, explains why a date is closed, and prices the full stay up front.
Decision 03
One tracker instead of an email chain.
Before Stays, a booking lived across emails, provider portals and follow-up calls. Nobody had the full picture. The tracker shows every state from enquiry to move-in, and provider updates sync back through the APIs. Each state change also moves the money: commissions, invoices and payouts trigger from the lifecycle, so finance stopped working from spreadsheets.
04 - Context
Everything after the offer letter, students figured out alone
Edvoy had built a reliable international student recruitment platform. Universities, applications, offer letters: that whole chain worked. Then a student got accepted, the product went quiet, and they were dropped into finding a home in a city they had only seen on Google Maps. The students who got it right usually had someone on the ground. Everyone else worked from Facebook groups, unverified agent recommendations and listings that ranged from misleading to outright fraudulent. A friend of mine trusted an agent who said his room was close to campus. It was nearly 20 km away, on top of a hill, barely reachable by public transport.
Students decided alone
Without someone local, students relied on social groups and listings no one had checked.
Agents worked outside the product
Bookings ran through email, provider portals and manual follow-ups, with no shared view of status.
Edvoy had no visibility
The accommodation decision happened next to the platform, with no workflow, no data and no revenue.
Payouts were manual
Commissions varied by provider, tier and stage, which turned every payout into a spreadsheet job.
The problem
Give agents a way to find, recommend and book verified housing for their students, and give Edvoy visibility and revenue across the whole accommodation lifecycle.
05 - Try the product
The product, rebuilt as working components
Each tile is a real interaction from Edvoy Stays, rebuilt in code with sample data. They play on their own. Click any of them to use it yourself.
Filters that count back
The result count updates before you commit.
What’s nearby
Transport, pharmacy and groceries with walking times.
Property gallery
Swipe rooms, thumbnails keep your place.
Compare side by side
Best value per row, called out.
Shortlist with a heart
One tap saves, the count follows you.
Shortlist to PDF
A recommendation the student and parents can read.
Book for a student
Student, room, price and consent in one panel.
Deposit through Flywire
Students pay in their own currency, in the flow.
Commission by lifecycle
Payouts recalculate as the booking moves.
06 - Outcome
Revenue was the measurement, not the goal
~$2M
Stays launched as a brand new vertical. The first intake brought in about $2M in profit through Stays alone, with Flywire transaction commissions on top, and 4,000+ agents adopted it on a platform serving 50,000+ students a month. Some things shipped differently from the design: PDFs before shareable links, uneven inventory across regions, and stricter booking states than we wanted. Shipping a constrained version inside the intake window beat waiting for perfect infrastructure and missing the intake entirely.
07 - Reflections
Nine years in, this is the project that sharpened how I think
The interface was the easy part
The hard parts were earning a student’s trust for a housing decision, aligning agent incentives so the system rewarded good recommendations over easy ones, and building finance automation that survives every edge case. None of that is a UI problem. It’s a systems problem the UI has to express clearly.
The best idea wasn’t in the brief
Flywire came from knowing the business well enough to ask what else was true that we weren’t acting on. Bookings were one revenue stream. Student payments were a second one, and we were already standing on it.
What I’d do differently
I’d push for the B2C layer earlier, so students could book directly and not only through agents, and I’d invest in inventory normalisation up front. For a team of five in four and a half months, I think we chose well what to defer and what to get right the first time.