01 - Problem

The product ended at the offer letter. Everything after that, students figured out alone.

Edvoy had built a reliable international student recruitment platform. Universities, applications, offer letters — that whole chain worked. But the moment a student received their acceptance, the product experience stopped, and the student was dropped into a completely unassisted process of finding somewhere to live in a country they'd never been to.

The students who navigated it well usually had someone on the ground — a senior who'd studied there, a relative who'd settled nearby, a family friend who could vouch for a neighbourhood. Everyone else was working from Facebook groups, unverified agent recommendations, and listings that ranged from misleading to outright fraudulent.

"He arrived to find his accommodation was nearly 20km away — on top of a hill, barely reachable by public transport. He'd made a life-altering decision on a single line of misleading copy."

That's a friend of mine. He'd trusted an agent's claim that the property was "close to campus." When he got there, it wasn't even close to a bus stop. This is the thing about accommodation failures — they're not abstract. They compound. The wrong location affects whether you make it to lectures on time, whether you sleep properly, whether the first few months abroad feel manageable or isolating.

Inside Edvoy, none of this existed as a product surface. No workflows, no visibility, no support layer. The accommodation decision was happening anyway — it just wasn't happening with Edvoy's involvement. That's both a user problem and a significant missed business opportunity sitting directly adjacent to Edvoy's existing student and agent base.

So we asked

What if accommodation became part of the platform itself?

02 - The real scope

It looked like a marketplace brief. It was actually four separate problems wearing a trenchcoat.

Scoping this properly took time, because "build accommodation search" is deceptively simple as a brief. The surface problem is discovery and booking. But the moment you start pulling threads, you find that student trust, agent workflow, vendor infrastructure, finance automation, and lifecycle visibility are all load-bearing walls — and none of them can be deferred.

The first thing we discovered during early student conversations: accommodation terminology itself was a barrier. Terms like "ensuite," "studio," and "non-ensuite" meant different things — or nothing at all — across different countries and educational backgrounds. Rather than design around the industry's vocabulary, we changed the framing entirely. Students selected preferences in plain language: private or shared bedroom, private or shared bathroom, private or shared living space. A small shift, but it removed a layer of confusion that would have quietly caused drop-off throughout the funnel.

The vendor API problem was harder and couldn't be designed around — only designed with. We launched with three integrations: Casita, Amber, and University Living. Each exposed different data structures, booking window logic, and inventory coverage. Casita had the most flexible API, so it was prioritised. But even Casita enforced fixed booking windows server-side in certain configurations, which meant the interface had to dynamically adapt to constraints it didn't control. The UX wasn't just responding to user needs — it was being actively negotiated against infrastructure limitations in real time.

Team: 1 product owner, 2 engineers, 1 QA, 1 designer. The core booking experience was scoped and designed end-to-end in roughly two weeks. The systems surrounding it took longer.

03 - Solution

Discovery was the front door. The lifecycle engine, finance automation, and transaction layer were the actual product.

The discovery surface gave students and agents the ability to search near any university, apply preference filters, compare properties, shortlist stays, and export recommendation PDFs. Each property surfaced room configurations, distance to campus, amenities, and nearby context — pharmacies, supermarkets, transport options. That context layer wasn't cosmetic; it was specifically designed to help a student picture the lived reality of a location, not just its specs on a page.

The booking flow guided agents through student selection, deposit handling, pricing calculations, consent confirmation, and reservation submission. After booking, a lifecycle tracker visualised every state from enquiry to move-in, with vendor-side updates syncing back through APIs. That single surface replaced a fragmented chain of emails, external portals, and manual follow-ups that agents had previously relied on. Giving agents operational clarity over the accommodation lifecycle — without adding complexity to the workflow — was one of the more underrated design outcomes of the project.

Commission logic was the other challenge that grew into its own product. Payouts varied by vendor agreement, agent tier, student tier, and lifecycle stage. We designed for automated calculation, invoice generation, payout visibility, and finance workflows — all triggered by lifecycle progression rather than manual inputs. We also contributed to an architecture decision to mirror accommodation inventory locally and sync periodically, which reduced vendor API call volume significantly and improved platform performance.

The Flywire integration was the sharpest strategic move. Accommodation bookings created one revenue stream. But international student payments created a second, and the platform was already positioned to own that transaction layer. Integrating Flywire into the accommodation lifecycle meant monetising not just where students stayed, but how they paid. That wasn't in the original brief — it came from understanding the business model well enough to see what was adjacent to it.

04 — Outcome

~$2M in the first intake. But revenue was the measurement, not the goal.

Edvoy Stays launched as a net-new vertical. The first intake generated approximately $2M in profit through Stays alone, with additional Flywire transaction commissions on top. Adoption reached 4,000+ active agents on a platform serving 50,000+ monthly students.

Some things shipped differently from how they were designed. Downloadable PDFs instead of collaborative proposal links. Inventory gaps across regions. Booking states that were more rigid than we wanted due to vendor API constraints. These were real compromises — but shipping a slightly constrained version of the platform during the first intake was the right call. Waiting for perfect infrastructure would have cost the business the intake window entirely.

The outcome that actually mattered wasn't the revenue. It was that students going through Edvoy now had access to verified listings, honest distance data, and a structured booking process backed by a platform that was accountable for what it recommended. That's a fundamentally different experience from navigating it alone, and it's what the product was actually for.

05 — Reflection

This is the project that changed how I think about what the work actually is.

The interface is almost never the hardest part. Here, the hardest parts were earning enough trust from a student to make a housing decision through a platform they'd never used for that purpose, aligning agent incentives so the system rewarded good recommendations over easy ones, and building financial logic that could absorb the edge cases nobody anticipates until they hit.

None of that is a UI problem. It's a systems problem that UI has to express clearly. The designers who create the most value are the ones who can hold both — the user experience and the business architecture — at the same time.

The $2M gets the attention. The part I'm more proud of is that the experience exists at all.

Product strategy, End-to-end UX, Systems design, API-constrained UX, Finance automation, Commission logic, B2B workflow design, Transaction layer strategy