Case study · Customer messaging product · 2024 to present
One place for WhatsApp-first teams to manage customer conversations.
I took OnSync from an idea to a working web and mobile product. The challenge was turning different provider rules, user workflows, and technical constraints into one product that felt consistent.
For teams working through WhatsApp and other messaging channels, context could sit in different accounts, ownership could be unclear, and follow-up often depended on someone remembering what happened. I wanted to give those teams one inbox and one customer record, then add other channels without rebuilding the product each time.
OnSync was my product. I decided what to build, designed the workflows, wrote the code, connected the messaging providers, defined the product states, and took the web and mobile products to launch. I worked independently, so the product, design, and engineering decisions all had to hold together.
Decision 01 · Build sequence
The tempting first move was to connect WhatsApp and put messages on the screen. Instead, I started with authentication, organizations, memberships, profiles, and rules that kept each organization's data separate.
It was slower to show, but it meant the inbox, permissions, settings, and future product areas could all use the same ownership model later.
Decision 02 · One inbox, different rules
WhatsApp, Facebook, Instagram, and Telegram all have conversations and messages, but their rules and capabilities are different. Meta's integration also came with approval states, messaging windows, token lifecycles, duplicate events, retries, and delivery results that were not always certain.
I moved the common parts into shared conversation and message models, then kept provider-specific behavior inside adapters and clear product states. People could work in one inbox without being misled about what every channel supported.
Shared conversation concepts connect provider-specific messaging to one organization-scoped product. Provider capabilities are not presented as identical.
Decision 03 · Mobile scope
I kept the Flutter app focused on work that needed immediacy: signing in, triaging the inbox, reading conversations, replying, receiving updates, and responding to notifications.
Configuration-heavy work stayed on the web. Mobile had a clear job instead of a promise of feature parity, which kept the smaller product useful where a phone actually mattered.
Product outcome
OnSync reached launch with an organization-scoped inbox, a shared conversation model, provider adapters, media handling, assignment, status and priority workflows, templates, campaigns, real-time updates, and a focused Flutter companion app.
The strongest result was the structure behind those features: shared concepts where consistency helped, explicit product states where provider constraints differed, and a clear boundary between administration on the web and time-sensitive work on mobile.