- #flutter
- #firebase
- #revenuecat
- #ui-/-ux-design
talkAround
From a studio-owned idea to a cross-platform launch—and a production-focused modernization for its next chapter.

Project details
Better questions, less friction
Some of the most important conversations never happen because nobody knows how to begin them. talkAround started as an Indent Studio product venture around a simple premise: a useful prompt should bring people closer, then get out of their way. The app had to feel natural on a first date, during a quiet evening at home, around a table with friends, or between colleagues—without turning the conversation into a game with complicated rules.
That made content and interaction equally important. A thin catalogue of generic questions would not be enough, while an interface demanding constant attention would defeat the purpose. We needed a product that could offer the right amount of structure, invite a genuine answer, and leave the people using it focused on each other.
Designing the rhythm of the conversation
We designed the product, visual system, content model, and mobile experience as one whole. Nine themed packs move from easy icebreakers and playful hypotheticals to relationships, memories, and questions with more depth. A random mode removes the need to choose. The structured catalogue contains more than 600 prompts, alongside a complete cycle of 366 daily questions in English and Hungarian.
The product gives people several reasons to return without adding pressure. They can save a question for later, see their progress through a topic, build a daily streak, or jump straight into a surprise session. Guest access keeps the first experience lightweight, while social sign-in, subscriptions, and an ad-supported free experience give the product room to operate beyond a prototype.
Large content sets can become a maintenance problem of their own. Instead of hard-coding copy throughout the interface, source files and generators keep questions, daily prompts, categories, and localization separate from presentation code. That makes editorial changes repeatable and keeps one Flutter codebase responsible for both iOS and Android.
Modernizing without starting over
By 2026, talkAround was already a released product, but its foundations and visual experience needed another pass. We chose controlled modernization over a rewrite. The codebase moved to the current Flutter and Dart toolchain, Riverpod 3, AutoRoute, and maintained local-storage packages. iOS dependency management moved to Swift Package Manager, while parallel Android and iOS delivery workflows made signed builds and store uploads repeatable.
The interface was rebuilt around a documented design system rather than a collection of one-off screens. Color, typography, spacing, shape, motion, imagery, and accessible controls now have named rules and reusable components. Pages bind state to UI; view models own decisions; repositories and services isolate data, authentication, purchases, analytics, advertising, and monitoring. Targeted tests and pull-request checks cover the boundaries most likely to regress.
Repository-level architecture, state-management, page, and UI guidance also gives AI-assisted development a controlled context. AI can help accelerate implementation, analysis, documentation, and routine test work, but architecture, privacy-sensitive choices, product trade-offs, review, and release approval remain senior engineering responsibilities.
A shipped product with an honest release story
talkAround 1.0 reached the App Store in March 2024. The redesigned, modernized Android build reached Google Play in August 2026. At the time of publication, the original iOS release remained available and its public listing still showed version 1.0, so the case study distinguishes completed engineering work from public store status rather than implying release parity.
The result is a studio-owned product with a maintainable cross-platform foundation, a repeatable content pipeline, production monetization and observability, and a delivery system built for continued iteration. It demonstrates the full span of work behind a mobile product: defining the problem, shaping the experience, shipping it, and returning later to improve the parts that determine whether it can keep evolving.
Modernizing a mobile product without losing what already works? Discuss your product.








