EzyFlat · Live in production
A flatsharing marketplace built around the household, not the listing
Finding a room in Greece still happens mostly in Facebook groups. EzyFlat is the product I co-founded to address that, and the one where I own everything from the problem statement to the release decision.
A note on the screenshots
Every EzyFlat screenshot on this page uses demo data, for obvious privacy reasons.
The problem
Shared renting in Greece has real demand but no product built for it. Students and young professionals find rooms through Facebook groups, word of mouth, and generic real-estate portals designed to sell whole apartments. All of those channels share the same three weaknesses: you cannot filter properly, you cannot verify anything, and you cannot find out who you would actually be living with until you are standing in their hallway.
That third point is the one the existing products have not modelled. A room listing is a property record, but a flatshare is a household: a group of people, on a set of terms, for a set of dates, with different economics per room inside the same front door. I decided early that EzyFlat would model the household, and that this, rather than a nicer search page, would be the part that is difficult to copy.
The core product decision
Competitors model the classified ad. We model who lives there, on what terms and for how long, because that is the decision a renter is actually making.
What I owned
On a founding team the boundary between product and everything else is thin. In practice I own:
- Problem and scope: defining the problem, the need behind it, and how solving it connects to the business, plus what is in the MVP and, just as importantly, what is explicitly out of it.
- Requirements: product requirement and feature definition, the data model, entity relationships, status state machines, and the business rules that have to hold on every screen.
- Product documentation: the specs the team built from, kept current as the product changed.
- Prioritisation: sequencing features against liquidity, trust and launch risk rather than against what is most interesting to build.
- UI UX Design: the four primary user flows, states, wireframes and the interface design for every screen.
- Market research: the competitor landscape, target user needs, and where EzyFlat could be structurally different rather than simply better looking.
- Development: building the platform end to end alongside a small team, from data model to a fully functional product.
Scoping the MVP with a story map
A flat list of features tells you what someone wants built. It does not tell you what a person is trying to do, or which items have to exist together to be worth anything. So before writing a backlog I mapped the product as a story: the things people do, left to right, in the order you would explain them to someone who had never seen it.
The top row is the backbone, and it reads as a sentence. Someone lists a home, then someone else finds a home, then judges the fit, then they arrange a viewing, then they agree the tenancy. Two sides of a marketplace, one story. Under each step sit the individual pieces of work, stacked with the most essential nearest the top, and horizontal lines cut the map into releases.
Why the first release had to touch every column
The temptation with a marketplace is to build one side beautifully and the other side later. That does not produce a smaller product, it produces a broken one: excellent search with no way to actually agree a tenancy is a catalogue, not a marketplace. So the first slice takes at least one story from every column, even where that meant the thinnest possible version of it. The test it had to pass was a single sentence: can one renter go from searching to a confirmed tenancy in a real home, without anyone stepping in by hand.
The second slice is about trust, because a flatshare asks strangers to commit to living with each other, and nothing in the first slice earns that. Verification, messaging with boundaries, compatibility and the ability to leave cleanly all sit there. Its measure is the report rate in the next section, which is the number that says whether the trust work is holding.
The bottom band is the part I find most useful to show. Rent collection, deposit handling, contract signing and agency bulk import are all reasonable things for this product to do, and none of them are built. Each one adds regulatory and financial surface area, and none of them helps answer the only question the first release existed to answer, which is whether two strangers will actually agree a tenancy through the platform. Keeping them visible on the map, rather than deleting them, is what makes it a decision rather than an omission.
One clarification, since these artifacts get confused. This is a story map, not a journey map and not a process model. It has no emotion row and no satisfaction curve, because it is not describing how it feels to use the product. It has no gateways or actor swimlanes, because it is not describing how work flows through a system. It has release lines, because its job is to decide what gets built and in what order.
How I measure whether it works
I defined the metric set before the features shipped, so that "is this working?" has an answer rather than an opinion. None of them is a vanity number. Each one sits at a step in the funnel where a two-sided marketplace typically loses users.
| Metric | MVP target | What it tells me |
|---|---|---|
| Signup → profile completion | 70%+ | Whether onboarding asks for too much before it gives anything back |
| Listing completion rate | 50%+ | Whether the listing wizard is too long for the supply side |
| Viewing request response rate | 40%+ | Whether the marketplace is alive or just populated |
| Time to first contact | < 48 hours | The single number that predicts whether a user comes back |
| Report rate | < 5% | The quality floor, and the point at which trust work takes priority over growth |
How the pricing model creates liquidity
Competitor research started from one observation. Nearly every flatsharing platform in Greece stays small, with very few live listings, while the same search runs at real volume inside Facebook groups.
That gap was worth understanding. The listings and requests already circulating in those groups, on top of the research I had run, proved the demand exists and can be marketed to. It simply was not reaching the existing platforms.
Their pricing models explained a large part of it. Most charge the landlord side heavily, and the landlord is the side with the leverage, the one who actually brings the supply. A renter gets no value from a platform with nothing listed on it, so those platforms stay thin and users go back to the channels that have more rooms to search.
The base platform stays free for a renter. The paid packages are about standing out in a market where demand runs far ahead of supply: they exist to help someone win a competitive search, not to gate access to it.
- Renter subscriptions: optional tiers that give a genuine edge over everyone else chasing the same room. This is where most of the revenue comes from.
- Landlord packages: paid separately, for the extra capabilities that come with more complex portfolio management.
- Partner services: additional home-related services, outsourced to partners.
None of this runs from day one. It switches on once the user base reaches specific targets, the same sequence-against-liquidity logic that shaped what shipped and in what order.
What shipped
Following the map: search and filtering, listing creation as a multi-step wizard, room- and bed-level availability, viewing slots and requests, booking requests that create a real tenancy on acceptance, verification, listing-scoped and direct messaging, saved homes and saved search areas, notifications, household management with invitations and terminations, a lifestyle compatibility engine, and account lifecycle including GDPR deletion, all of it in two languages.
