Bigg Boss Vote: a seasonal app built around one night a week

The user and the job

Bigg Boss is a reality show where the audience decides who stays. Each week some housemates are nominated for eviction, and fans vote to save their favourites, officially on the broadcaster’s app or by missed call. Around that vote sits a weekly routine: find out who is in danger, cast the official vote, see what other fans think.

Bigg Boss Vote: Telugu & Tamil serves that routine on Android, and telugubiggbossvoting.com serves it on the web. Neither is affiliated with the show; the site says so on every page and links the official voting method. I built both alone, with AI coding tools writing the code. The decisions were mine.

Why a seasonal audience

The demand runs on a calendar. Season 10 of the Telugu show premiered on Sunday 6 September 2026, and from the first nominations night the show hands the app a new reason to be opened every week. Most consumer apps have to invent a return trigger. This one gets a fresh list of names weekly, for free.

The calendar also cuts the other way. A release that misses the premiere misses the season, and in August there was a hard gate in front of it. Google Play required app updates submitted after 31 August 2026 to target a newer Android API level, which forced a framework upgrade before any feature work. The upgrade stayed on a branch until a signed build booted and the critical flow passed. I cut v1.1.0 on 9 August.

Scoping the Season 10 release

The app already existed from earlier seasons, so I started with a full review in early August. Some findings would have broken launch night. An empty season filter fell back to showing every season’s content, so Season 9 material would have appeared on Season 10’s opening night. The push broadcast function published to a topic no installed client subscribed to, so anything it sent would have reached nobody.

I scoped to the season: fix what breaks it, leave the rest of the plan on paper. On 8 August I settled two calls. Telugu and Tamil would both ship, each with its own activation date, and the admin panel would stay on my machine.

The backend rules needed the most care. Clients on the old version didn’t send the queries a strict rule expects, so tightening reads in one step would have blanked the app for everyone who hadn’t updated. The first phase closed anonymous writes and kept legacy reads open, with tests behind it. Tighter reads wait until the installed base has moved to the new client.

Retention is one push a week

The weekly notification is the retention mechanic, and it fires once a week, on nominations night. It goes out over Firebase Cloud Messaging in a fixed shape. The title names the week (“Week N Nominations Are Out!”). The body opens with “Vote now”, gives the number of housemates in danger and closes on “Who will you save?” It carries no names, because a list of names truncates on a lock screen. Every send is a dry run first, and nothing goes out on a timer. Weeks 2 through 7 each got one.

On Week 7’s night the ballot grew from nine names to twelve after the push had already said nine. I didn’t resend. One push per nominations night is the rule, and a correction would have broken it.

The companion site

The site went live in late July 2026, in English and Telugu, on Astro and Cloudflare Pages, and updates every week of the season (Week 9 shipped on 3 November). Four rules shape it.

The poll is an embed. Voting runs on a Crowdsignal poll, and the app’s vote tab loads the same poll in a WebView. App and web share one ballot, and no vote touches my backend.
Standings are copied verbatim. A time-stamped copy of the poll’s own numbers, refreshed five times a day, labelled unofficial, never re-sorted or rounded. I hold the same rule for prices on motomotar.
Only confirmed outcomes are printed. An early eviction section predicted the leaver from the poll’s trailing name. I removed it, because a fan poll shouldn’t pose as a forecast of the official vote.
The list follows the ballot. From the first nominations night, 7 September, the scheduled refresh reads the week’s nominees from the poll itself, so a ballot change updates the nominee list without a deploy.

Comments run on Waline under the poll. A nominations hub with who-nominated-whom records for Seasons 1 to 9 keeps the site useful between nights.

Monetisation

The app runs AdMob alone, with no mediation. It has three placements: a banner, an inline unit between the tab row and the poll, and an interstitial after a vote. I turned down app-open ads. The typical session is open, vote, leave, and an ad at the door would block the one thing the user came to do.

What I chose not to build or ship

A custom voting system. The embedded poll brings one-vote-a-day limits and a shared ballot with no voting infrastructure to run.
An email list. The plan ruled one out from the start; search is the distribution.
The Chrome extension. On 14 September I built a small popup linking the poll, the official vote and the latest posts, for brand presence, with no users expected. It’s packaged and not uploaded. Publishing would mean store paperwork and a rename to match the Play listing, and with no users in the plan I left both undone.

Where it stands

Version 1.1.2 has been live since September 2026. The Play listing shows 10,000+ downloads and a 4.4-star rating from about 1,100 reviews. In late August the Play Console flagged a crash on relaunch after Android had killed the app in the background. I fixed it in 1.1.1, with a test and a build check that fail if the fix is removed, and chose a staged rollout for it.

There is no crash reporting yet. The after-vote interstitial loads on demand, so on a slow connection it can appear up to about 16 seconds after the vote. On the site, as of late October, several current housemates had no profile page and the elimination page was unbuilt.

Decisions I’d defend

Let the premiere set the scope.
One ballot for app and web, run by a poll vendor.
One push a week, on the night that matters.
No app-open ads.
Change backend rules in phases the installed base can survive.
Print only confirmed outcomes.

What I’d do differently

Install crash reporting before the premiere.
Commit before every release build. v1.1.2 was built from uncommitted changes, and I confirmed what shipped by unpacking the bundle.
Show the interstitial only when it has already loaded.
Do the store listing pass before the season. The listing copy was never written against the searches the site is built around.

Written from the project’s own records (release notes, decision logs and the weekly update log) and the Play listing.