/// product case studies

    From building products to owning outcomes

    Three examples of how I frame problems, make deliberate choices, and use engineering to deliver a product outcome.

    01

    NicotinD

    A self-hosted music experience designed around one continuous path from finding a track to listening to it.

    Problem

    Self-hosted music listeners move between disconnected tools to search, acquire, organize, and play music.

    Context

    The underlying services were capable, but their separate interfaces made a simple listening goal feel like infrastructure work.

    Discovery

    Mapping the end-to-end journey showed that tool boundaries—not missing features—created most of the friction.

    Hypothesis

    A single experience could hide service boundaries while still giving advanced users control.

    Options

    I considered a thin launcher, a shared dashboard, and a fully unified workflow.

    Decision

    I chose unified search, optional acquisition, and cross-device playback behind one product language.

    MVP

    The first version deliberately left out social discovery and advanced library management.

    Execution

    I owned the concept, experience, architecture, and implementation, using working software to test each decision.

    Outcome

    The result turns a multi-service process into a coherent workflow where newly acquired music becomes immediately playable.

    Learning

    Integration is a product problem: technical orchestration only matters when it removes effort for the user.

    02

    Departure Board

    A focused information display that makes the next useful travel decision readable at a glance.

    Problem

    General transport apps contain plenty of data, but are poorly suited to an always-visible household display.

    Context

    The product had to work from a distance, update reliably, and show only information that could change a decision.

    Discovery

    The key need was not route planning; it was immediate confidence about the next departures.

    Hypothesis

    A deliberately narrow display would be more useful than reproducing a full transport application.

    Options

    I explored dense timetables, map-led views, and a concise ranked list of departures.

    Decision

    I prioritized glanceability, clear delay states, and a hierarchy built around time-to-departure.

    MVP

    Trip planning, account features, and historical data stayed outside the first scope.

    Execution

    I combined physical-display constraints, live data, visual design, and frontend implementation.

    Outcome

    The display makes live transport information useful in the environment where the decision actually happens.

    Learning

    A strong MVP often comes from removing valid features that do not serve the core moment of use.

    03

    Company Tours

    A white-label B2B travel product shaped around reusable customer journeys and distinct client identities.

    Problem

    Travel businesses needed tailored booking experiences without rebuilding the same product for every brand.

    Context

    The solution had to balance traveller clarity, client branding, itinerary complexity, and maintainable delivery.

    Discovery

    Separating shared journey patterns from brand-specific presentation exposed what truly needed configuration.

    Hypothesis

    A reusable product core with controlled variation could improve consistency and reduce repeated work.

    Options

    The alternatives were separate sites per client, unrestricted templates, or a governed white-label system.

    Decision

    I favoured consistent booking and itinerary flows with clear extension points for each customer.

    MVP

    The initial scope focused on the essential discovery, itinerary, and booking journey.

    Execution

    I translated client needs into reusable interface patterns and delivered the responsive experience.

    Outcome

    The product demonstrates how a shared foundation can serve different businesses without losing their identity.

    Learning

    B2B flexibility works best when product boundaries are explicit rather than infinitely configurable.

    ← KR_

    /// contact

    Let's Connect

    Kevin Roberts

    Have a project idea, want to collaborate on something cool, or just want to chat about tech and electronics? Reach out.

    © 2026 Kevin Roberts

    Built with React + Tailwind