Employment, Roboost
Sira 360
An AI customer-experience app for restaurant chains: dashboards, AI ticketing and a customer inbox.
- Google Play
- App Store
- Sira 360The product’s website
Overview
Sira collects reviews from Google, delivery apps and social media, and uses AI to turn them into sentiment, incidents and tasks. The mobile app gives managers the dashboards on the move and gives support staff an inbox to answer customers from.
In the recording
Sign in, the Executive Overview dashboards, switch to Community from the drawer, open a customer thread, polish a reply with AI and send it.
Recorded from the real appRecorded from the real Flutter app in the iOS Simulator. The app ran from a throwaway copy pointed at a local mock server with made-up data, with crash reporting and analytics switched off; nothing reached the production backend. The AI-polished reply is fixed text served by the mock.
The app’s source is private to Roboost. The brand, branches, reviews and customers in the recording are made up.
Screens
9 stills from the recording above. Select one to see it larger.
01Choosing between the two products after signing in 02Executive Overview: CSAT, sentiment and top negative topics 03Category distribution across the brand 04Branch performance against the brand average 05The drawer switches between Reputation and Community 06The Community inbox, with SLA, sentiment and tags per thread 07A customer thread 08The draft after “enhance with AI” 09The reply sent
Context
Sira is Roboost’s second product. I started the mobile app from an empty repository in February 2026 and I am still its only developer. It is now about 100,000 lines of hand-written Dart with more than 200 test files.
Two apps in one
The user picks a section and the app remembers it:
- Sira: executive and location-manager dashboards, AI review summaries, incidents with SLA tracking, need-attention lists
- Community: inbox threads, chat with public and private replies, internal notes, reactions, attachments and voice notes, cases and customers
Sending messages on a bad connection
A reply appears in the thread as soon as it is sent and is reconciled with the server when the next poll comes back. Voice notes are the hard case: the server accepts the upload and settles it in a background job, so a note is pending first, then sent or failed.
After a note is queued the app polls again at 4 and 8 seconds, which covers the backend’s usual 2–5 second settle, and leaves slower retries to the regular poll. The server has no retry-by-id, so the recording is kept on the device until its message is confirmed, and a failed note can be sent again from the same file.
Guard rails
I wrote the CI checks the project depends on: analysis that fails on any warning or info, a Dart script that fails the build when one feature module imports another, and a 55% coverage gate. Errors go to Sentry with debug symbols, usage to Mixpanel. About 4,800 lines of feature documentation live next to the code so someone else can take it over.
Problems worth telling
Optimistic UI without duplicates
Optimistic bubbles, a paged message list and periodic polling all write the same list. Each poll is merged by message id and track id: local bubbles the server hasn’t seen yet stay, the server’s version replaces everything in the fresh window, and older pages are kept. A retry puts the failed bubble back in flight instead of adding a second one, and the voice-note store forgets a recording once its message is confirmed sent.
Stack
- Flutter
- Riverpod 3
- Freezed
- go_router
- Dio
- Hive
- record
- Sentry
- Mixpanel
- Shorebird