Yammat

Building a social platform for musicians in four months

Yammat was designed to help musicians find people to play with, build connections, communicate, and organize jam sessions. The MVP combined musician profiles and search, social content, user connections, real-time messaging, voice calls, location-based discovery, jam sessions, notifications, and moderation.

The founder came to AEX Soft with finished Figma designs, a defined feature set, and a four-month deadline for the MVP. One project manager and three developers were responsible for turning that scope into the backend, two mobile apps, integrations, and a web administration panel. With so many product areas sharing the same data and user flows, the main challenge was keeping them consistent as they were built: relationships determined who could communicate, session participants affected access and capacity, and event pages connected participation, organizer contact, and notifications.

The four-month deadline also meant making deliberate scope decisions early. Voice calls were limited to direct one-on-one audio through Twilio, while the social feed used simple chronological ordering. Keeping these interactions focused on their core use cases gave the team room to cover the broader product without expanding the implementation beyond what the MVP required.

The team used the first stage of the project to define these dependencies and establish a shared product model before implementation. This gave development a stable foundation for making product and technical decisions throughout the build.

Modeling the product before building it

The discovery phase focused on the objects and relationships shared across the product: users and profiles, relationships and permissions, conversations, jam sessions and participants, locations, invitations and notifications, user-generated content, and moderation.

The resulting model became the foundation for the API and database design. Each part of the product was connected through a small set of shared entities. A jam session, for example, had participants, invitations, a location, and access and capacity rules, all of which also affected other parts of the user experience. This gave the team enough flexibility to refine individual flows without changing the underlying structure.

Location discovery shows how that worked in practice. Because location was part of the session model from the start, the MVP could support creating sessions with a location and finding relevant sessions within a defined area. More advanced ideas, such as matching musicians with suitable venues or calculating travel time, could be left for later without changing how sessions stored or used location.

The discovery phase produced the core data model, API specifications, communication architecture, technical dependencies, implementation backlog, and delivery estimates. These became the working foundation for development and made the main sources of rework visible before the team committed to the four-month implementation schedule.

Designing the architecture around the delivery constraints

With three developers covering the backend, mobile application, integrations, and web administration panel, the architecture favored shared implementation and established infrastructure where they could reduce engineering overhead.

For mobile, the team used Xamarin to build a single codebase targeting both iOS and Android. Business logic, data models, validation, and API integrations were shared, while native UI and platform-specific behavior were handled separately where needed. This reduced duplicated implementation while preserving the flexibility to address platform differences.

The backend used .NET Core and MS SQL Server and ran on Azure, with SQLite providing local mobile caching. SignalR handled real-time messaging and Twilio handled voice calls. The application remained responsible for product-specific logic such as permissions, conversations, sessions, and notifications, while the underlying infrastructure came from established services.

The resulting architecture kept the implementation relatively small for the size of the team and the scope of the MVP. The trade-off was relying on the capabilities and constraints of the selected platforms and services rather than building equivalent infrastructure in-house.

The technology choice reflected the ecosystem at the time. Xamarin was subsequently retired by Microsoft in 2024; AEX Soft now uses .NET MAUI or React Native for cross-platform mobile development depending on the project requirements.

Keeping real-time communication reliable

Messaging was central to the Yammat experience. Musicians could connect with each other, exchange messages, and move between conversations and jam sessions without leaving the app. SignalR handled real-time messaging, while Twilio provided voice calls.

Mobile connectivity added another layer of state management. A user could lose their connection while sending a message, receiving an invitation, or joining a session, then reconnect after the underlying state had changed. The team kept the server as the source of truth and refreshed client state after reconnect rather than trying to merge independently modified local changes.

This worked alongside the mobile caching layer without turning the MVP into a full offline-first system. The approach kept synchronization predictable while avoiding the additional complexity of resolving competing local and server-side changes.

Handling capacity in jam sessions

Jam sessions were one of the places where several parts of Yammat had to agree on the same state. A session had a defined capacity, participants could join or leave, invitations could change who had access, and other parts of the product depended on the current participant list.

That created a concurrency issue around the last available spot. Imagine a session with five places and four musicians already participating. Two other musicians can see one place available and tap “Join” at almost the same time. If the availability check and participant update happen separately, both requests can pass the check and the session can end up with six participants.

The team therefore handled the capacity check and participant update as one server-side operation. One request could claim the remaining spot; once the participant state changed, the competing request would fail the capacity check and receive the updated session state.

The important part of the implementation was deciding where the rule belonged. The client could display availability, but the server remained responsible for determining whether participation could actually change.

Keeping location discovery focused

Location was part of the jam-session model from the start: a session had a location, and musicians could use it to find sessions nearby. For the MVP, the team implemented location-based search within a defined area around the musician rather than building a broader location service.

More advanced functionality, such as venue matching or travel-time calculations, was left for later. The underlying location model was already in place, so those capabilities could be added without changing how sessions stored or used location.

Building administration into the product

Yammat relied on user-generated profiles, connections, messages, and jam sessions, so the client also needed a way to manage the community behind those interactions. The web admin panel gave administrators a separate interface to review users and their content, manage accounts, and take moderation actions. It connected to the same backend and permission model as the mobile apps, so administrative changes affected the same user and content data used throughout the product.

That gave the client the tools to manage the community as soon as the platform was ready: review profiles and activity, moderate content, and handle user issues without maintaining a separate set of business rules for the admin side.

Keeping delivery on track

The discovery outputs became the working foundation for development: the product model, API specifications, technical dependencies, backlog, and delivery estimates. From there, work moved in small, testable increments, giving the founder regular opportunities to review working functionality and make decisions while there was still time to act on them.

The backlog was managed in a Kanban-style flow with limited work in progress. This kept blockers visible, prevented too much unfinished work from building up, and made dependencies easier to manage as different parts of the product moved forward. Regular client reviews kept priorities aligned with the agreed MVP and gave the founder a clear view of what was complete, what was next, and where a decision was needed.

When new requests came up during reviews, the team treated them as scope decisions rather than additions to the schedule. New work could be added by moving an equivalent item to the post-MVP backlog, keeping the four-month timeline and agreed budget intact while giving the founder flexibility to refine the product based on what they saw.

Continuous integration connected the backend, mobile apps, and third-party services throughout development. Features were reviewed as complete user flows, allowing integration issues to surface before the final stages of the project. The PM also tested working increments throughout the build, covering core flows and edge cases as functionality became available.

This kept scope, progress, and delivery risks visible throughout the project and gave the client a predictable path from the discovery plan to a completed MVP.

What was delivered

The agreed MVP was delivered within four months across iOS, Android, and a web administration panel, covering the core experience needed to launch the product.

Finding and connecting with musicians brought together profiles, search, social content, user connections, real-time messaging, voice calls, and notifications.

Organizing jam sessions covered session creation, scheduling and locations, invitations, participant management, capacity limits, and nearby session discovery.

Running the community gave administrators tools to manage users and moderate content through the web panel, backed by the same permissions and business rules as the mobile apps.

The product was supported by a .NET Core backend, MS SQL Server, Azure, SQLite mobile caching, SignalR for real-time messaging, and Twilio for voice communication.

What happened after development

The MVP was completed within the planned four-month timeframe and moved into soft launch with AEX Soft supporting the release on both platforms. For iOS, the team used TestFlight to distribute builds to a controlled group of testers and review sessions, crashes, tester feedback, and version adoption. On Android, Google Play testing tracks were used to control distribution and monitor installs, stability, crashes, and user feedback. The team worked through the release cycle by fixing issues found during testing, preparing new builds, and expanding the tester group.

The soft launch gave the founder an opportunity to test the product with real users and evaluate the response before committing to a wider rollout. The technical foundation was ready to continue, but the market feedback did not give the founder enough confidence in the business proposition, so the rollout was stopped before a full public launch.

For AEX Soft, Yammat added another practical application of the team's established experience with complex product workflows, real-time communication, state management, cross-platform development, and controlled mobile releases.