Comu is a location-based social platform designed to help people discover what is happening around them, connect with nearby communities and interact with local places, events and people.

Most social platforms are organized around people you already follow, while local discovery is often fragmented across maps, messaging apps, event platforms and social networks.

Comu was designed around a different logic: proximity first.

A deeper dive into the Product Thinking behind Comu, exploring the problem, user needs, MVP strategy, UX decisions and product principles that guided the experience.

Before defining the product experience, I explored how people currently discover local information, events, conversations and communities, identifying behaviors, pain points and gaps across existing platforms.

The discovery process included benchmark analysis, user journey mapping, research questions and UX hypotheses, helping translate observations into clear product principles and opportunities.

The main insight was simple: local information already exists, but it is fragmented. Comu was designed to reduce that friction by making proximity and context part of the experience from the start.

The interface was built around a consistent and scalable design system, using reusable components, clear visual hierarchy and standardized interaction patterns across the product.

I defined colors, typography, spacing, states and components to keep the experience cohesive while making new screens faster to design and implement.

This component-based approach also helped connect design and development, ensuring that the UI remained consistent as the product evolved.

I took the product into implementation using FlutterFlow, turning static screens into a functional mobile experience.

The build involved functional prototyping, interaction design and app architecture, including reusable components, navigation flows, page and component states, conditional behaviors and dynamic content structures.

This workflow allowed me to validate not only how the product looks, but also how it behaves, how users move through the experience and how different parts of the application connect, while keeping the visual system and interaction patterns consistent throughout the build.

I connected the FlutterFlow front end to Supabase, creating a real data layer for profiles, posts, events, conversations and local content.

The interface was designed as a data-driven system: new records stored in the database are retrieved through FlutterFlow queries, filtered according to the product rules and rendered inside the appropriate reusable card through dynamic ListViews. The backend determines what content appears, where it appears and which component should represent it.

Security and privacy were treated as part of the product architecture, not as an afterthought. Using Supabase Auth, Row Level Security (RLS), protected views and backend rules, I structured the MVP so that users only access the data and conversations they are allowed to see.

Public and private profile data were separated, precise user location is not exposed to other users, and private conversations are only created after explicit approval. Product rules such as conversation permissions, event chat access and valid content types were also enforced at the backend level to keep the experience consistent and safer by design.