Findaly — designing clarity in a complex market
Building a calm, trustworthy marine marketplace by treating structure as the product — and carrying it through UX, visual language, data modelling, and production code.
Findaly didn’t begin as a startup idea. It began as friction — the kind you feel when an industry with global reach, high-value assets, and deeply human decision-making is still mediated through interfaces that feel accidental.
The marine world is rich, international, and nuanced — yet most digital platforms around it are fragmented, visually dated, and structurally unclear. You’re expected to already know how things work. If you don’t, the product doesn’t help you learn.
I designed and built Findaly end-to-end as a solo lead product designer and builder — from product definition and system design through to UX, visual language, data modelling, and production code. There was no handoff phase. Design and implementation happened inside the same loop.
The ambition was not to modernise a listings site. It was to design a marketplace that feels legible, trustworthy, and calm — even when the underlying data is complex.
A place where browsing a yacht, considering a charter, exploring a destination, or engaging a broker all feel like coherent parts of the same experience, rather than separate websites stitched together by habit.
The marine world already contains the drama. The product’s job is to reduce the cognitive load — and make decisions feel grounded, not exhausting.
Marine listings carry a lot of meaning: year, size, engines, condition, tax status, location, documentation, equipment. Most platforms respond by showing everything at once, flattening importance and forcing users to scan dense blocks of text with little guidance.
The result is comparison fatigue and quiet distrust. If everything looks the same, nothing feels reliable.
So the first design challenge wasn’t visual. It was structural: what information matters at each moment? What needs to be seen immediately, what should wait until intent is clear, and what only becomes relevant once a user is invested?
I treated the listing as a narrative rather than a database dump. The interface stays quiet, but the hierarchy works hard — surfacing signal, reducing noise, and preserving context as the user moves deeper.
This approach carried through the entire product. Findaly had to serve multiple intents without collapsing into a directory: buyers browsing, sellers publishing, brokers managing leads, users exploring destinations before they even know what they’re looking for.
Instead of building separate products for each, I designed a single system with shared foundations — one that can flex depending on intent, but always feel consistent.
A good example of the system-first approach is the listing creation flow. In most marine platforms, publishing a listing feels punitive. Forms are long, unclear, and unforgiving — designed around internal data needs rather than human behaviour.
I designed a progressive, multi-step flow that balances structure with momentum. The system asks for information in a deliberate order, validates quietly, and never makes the seller feel lost.
Underneath, the data model remains strict enough to support filtering, comparison, and future scale. On the surface, the experience feels composed and humane.
Because I was also building the backend, these decisions weren’t theoretical. Every UX choice had technical consequences: how listings are indexed, how optional data behaves, how missing information is handled, how performance scales as media increases, and how URLs remain predictable.
Design and code informed each other continuously, which kept the product honest. There was no gap between intention and implementation. When something felt unclear, I couldn’t defer it. When a decision introduced complexity, I had to carry it through the entire system.
Visually, Findaly is intentionally restrained. The marine world already provides the drama — materials, water, light, photography, aspiration. The interface exists to frame that, not compete with it.
Typography, spacing, and rhythm do more work than decoration. The goal was to feel premium without being ornamental, modern without being trendy, and international without leaning on clichés.
Trust, in this context, comes from clarity and consistency, not visual noise.
One of the most important decisions was to design Findaly as a platform that could grow in scope without changing shape. Boats for sale, charters, brokers, shipyards, services, destinations — these aren’t separate products in real life, so the system shouldn’t treat them as such.
The underlying taxonomy and architecture were designed to expand laterally, allowing new listing types and discovery modes to plug into the same foundation without breaking the experience.
Findaly today exists as a coherent, working marketplace platform — not a concept, not a redesign, not a speculative UI. A real system with real flows, real data, and real trade-offs.
More than anything, this project reflects how I approach senior product design: system-first thinking, deep attention to information architecture, and a refusal to separate design from delivery.
The interface is only the visible layer. The real work happens underneath — in the decisions that make the product understandable, scalable, and durable over time.
Findaly wasn’t about shipping fast or chasing trends. It was about designing clarity where there usually isn’t any, and proving that thoughtful product design can meaningfully improve even the most traditional industries when it’s carried through end-to-end.