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 · 30 seconds
From open-ended browsing to intentional exchanges
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 meetup needed a smaller unit of trust
Buenos Aires already had language-exchange apps and large events. The gap 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 made the exchange the product
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.
The wireflow made the exchange loop visible
Before the full build, I mapped the host journey from exchange type and language through time, place, review, and confirmation. That made the session the product’s organizing unit before the implementation changed underneath it.
People browse exchanges, not profiles
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.
Coordination stays attached to the exchange
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 chat turns interest into a plan
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.
The architecture followed the product loop
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 work required to test a real community product.
A working beta for intentional practice
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.
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.
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.
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.
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 the beta made testable
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: I preserved the product loop while replacing the implementation underneath it, then left a public repository showing the final system and the decisions that shaped it.
Have a product priority that needs an owner?
I join B2B SaaS teams on contract to ship the features, internal tools, and integrations already on your roadmap.