HablaBA: From Local Research to a Working Beta
Turns Buenos Aires language-exchange research into an invite-only web product for finding small local sessions and coordinating them in real time.
Project overview
HablaBA: From Local Research to a Working Beta overview
A short overview of the problem, solution, and result.
Starting Point
Language learners in Buenos Aires had plenty of places to browse profiles or attend large events, but those options often made focused practice harder to arrange.What Shipped
Research-backed product direction from a group interview, an 11-response survey, and six usability sessionsWhy It Mattered
HablaBA reached a working web beta that covers invitation, profile setup, discovery, session creation and joining, private chat, and notifications.Summary
HablaBA is an invite-only language-exchange product for people in Buenos Aires who want smaller, more intentional ways to practice in person.
I took the idea through research, an interactive prototype, usability testing, and a working web beta. The final product covers invitation, profile setup, exchange discovery, session creation and joining, private chat, and notifications.
The Problem
Buenos Aires already had language-exchange apps and large events. The gap was not access to more profiles or another crowded meetup. It was a practical way to find a small group, agree on the language and place, and make the session happen.
The first research round was a three-person, 90-minute group interview. I followed it with an 11-response survey and six usability sessions. Across those stages, the useful product shape became clearer: organize around a specific exchange, keep groups small, make neighborhood and timing visible, and give participants one focused place to coordinate.
Research Into Product Decisions
Make the exchange the main object, not the member profile.
The prototype started from a simple question: what if people browsed concrete practice opportunities instead of browsing people?
Each exchange sets the languages, neighborhood, start and end time, one-to-one or group format, participant limit, and description. That gives learners enough context to decide whether a session fits before they join.
Use real identity where people are planning an in-person meeting.
An early concept used generated avatars to reduce the dating-app feel. Usability feedback exposed the cost: people wanted to see who they might meet in a one-to-one or small-group setting.
The beta moved to real profile photos and paired that choice with invite-only registration, verified email, profile completion, and optional two-factor authentication.
From Wireflow to Product
Before the full build, I mapped the host journey from exchange type and language through time, place, review, and confirmation. That made the session itself the product’s organizing unit before the implementation changed underneath it.
Exchange Discovery
The Explore view keeps the decision tied to the session. People can compare the format, languages, neighborhood, timing, host, and available places without entering a profile feed.
The Product Loop
Keep coordination inside the exchange.
Joining creates access to that exchange’s private chat. Participants can discuss topics, timing, and the meetup without starting a separate social thread or losing the original session details.
Live messages use private WebSocket channels. In-app and browser notifications cover new participants, chat activity, and canceled sessions, while an activity heartbeat avoids notifying someone who already has the chat open.
Model the session as a lifecycle, not a static event card.
The exchange data model represents active, canceled, and completed states alongside join and leave records. That gives the beta a domain model for the session lifecycle without implying that completed meetups were measured.
Those states matter because the product is trying to help a group complete a real-world plan, not collect passive interest around an event listing.
Private Coordination
Each exchange has one chat for turning interest into a concrete plan. The screenshot uses seeded demo accounts and synthetic conversations from the repository’s development data.
Engineering Direction
Consolidate the maintained product into one web stack.
The implementation began as a Rails 8 API with a separate React Native/Expo client. I later built a Flutter client and migrated mobile notifications from Expo Push to Firebase Cloud Messaging. A separate React web client followed. Both mobile clients lived outside this repository and are not part of the maintained codebase.
I eventually consolidated the maintained product into one Laravel 12, Inertia 2, and Vue 3 web application. That kept the product rules, typed routes, Vue pages, real-time events, queues, and deployment configuration together.
PostgreSQL stores product state, Redis supports cache and real-time infrastructure, and the production setup separates the app, queue worker, WebSocket server, proxy, and data services in containers.
Build the trust and operating surfaces with the core experience.
The beta includes admin-issued invitation links, invitation revocation, a throttled interest form, email verification, password recovery, two-factor authentication, profile deletion, notifications, and light and dark themes.
Together, they moved the product beyond a clickable prototype and into the surrounding work required to test a real community product.
What Shipped
HablaBA reached a working web beta with the central invitation, discovery, session, and chat flow implemented. The honest outcome is the product and the decisions it made testable; the project did not establish adoption, retention, or completed-meetup results, and it is not presented as a currently live service.
Research
The product direction came from three rounds of evidence.
A three-person, 90-minute group interview, an 11-response survey, and six usability sessions shaped the beta before the full build.
Core loop
Exchange sessions replaced open-ended profile browsing.
People could create or join one-to-one and small-group sessions, then filter them by language, neighborhood, date, type, and open seats.
Trust
Access and identity became part of the product.
Invite codes, verified email, guided profiles, real photos, two-factor authentication, and admin invite controls supported a more intentional beta.
Coordination
Each exchange carried its own plan from discovery to meetup.
Private real-time chat, in-app notifications, and browser push kept the work of coordinating attached to the exchange.
What I Learned
The most important decisions came from testing the product model, not adding features. Research moved the experience away from profile browsing. Usability sessions changed the identity approach. Building the beta showed that chat, notifications, invitations, and session states were all part of the same coordination problem.
The architecture also changed as the product became clearer. That history is useful evidence in its own right: I could preserve the product loop while replacing the implementation underneath it, then leave a public repository that shows both the final system and the decisions that shaped it.
Tech Stack
Have a workflow ready to become software?
I design and build internal tools, automations, dashboards, integrations, and AI-assisted workflows around the people who need to use them.