Owners · fractional property platform

What was actually there

Owners.gr brought me on as founding product designer. The MVP, on the day I arrived, was a poorly designed mobile landing page with no real functionality behind it. No booking system, no role logic, no actual product. The team had a vision and a domain. What they did not have was the thing itself.

I owned the product strategy, the user research, the design, and the roadmap. The brief was open, in the way that is equal parts gift and terror. Take co-ownership as a category, and build a product that could genuinely serve five different people, owners, co-owners, guests, property managers, and admins, without splitting into five different apps.

Five roles, one product, no fork

Most products solve this by forking the codebase or building parallel apps. For a self-funded Greek startup that was never an option, and the constraint forced a better answer than money would have. One coherent product, with a surface that adapts to whoever is holding it.

Each role got its own home screen, its own navigation, its own set of actions. Underneath, every one of those screens drew from the same component library, the same tokens, the same interaction rules. Different on the surface where it mattered to the person, identical underneath where it mattered to the system.

What was broken at the start

Three things needed fixing before anything new could be built. The booking flows had no awareness of role, so owners, guests, and managers all landed on the same surface with no sense that they were different people with different rights. The colour palette failed contrast across the board, which in a product people use to manage property they part-own is not a small thing. And the co-ownership rules, which are genuinely complicated, were dumped on the user all at once, so people either got confused or gave up and ignored them.

The My Property module, and the booking engine

I designed the My Property section from nothing, a single management surface that reshapes itself around the role using it. The drag-to-select booking engine took the most iteration by far. I prototyped five different interaction models before one survived testing. The version that worked let people select their range first and then surfaced the availability constraints, rather than forcing them to understand every rule before they could even try. Context comes after the reach for it, not before.

Testing what actually mattered

Twelve participants across three groups, owners, guests, and managers, tested the booking and request flows, round after round. Two findings changed the design. Filters before context is backwards, people want to reach first and be corrected second. And the "Add Request" action was effectively invisible until I aligned it with the toggle pattern people already knew from the rest of the app.

What I keep from it

Five roles designed and validated. Twelve people tested it. A drag-to-select booking engine shipped as the core of the product. But the thing I carry from Owners is not the count. It is what a good constraint does. No budget to fork meant I had to find the harder, better idea, one product that adapts instead of five that drift apart. The times I have been handed less money and more limits are often the times I have done my clearest work, because a real constraint does the deciding that taste alone will argue about forever.