Building Bolvei X Javs: How We Scaled a Matatu Awards Platform to 7,400 Users in 7 Days

What happens when you launch a custom web app for one of Kenya's biggest street culture communities? You get 7,400 active users in exactly 7 days, constant phone calls, database limits collapsing, and an incredible crash course in real-time software scaling.

This is the raw, behind-the-scenes builder story of how I built and launched Bolvei X Javs (bolvei.com/javs) — a real-time voting platform for the Matatu Culture Awards, created in partnership with Javs of Nairobi (the leading voice of Matatu culture across TikTok, Instagram, and YouTube).

The Opportunity: Partnering with Javs of Nairobi

The Matatu culture in Kenya is massive, vibrant, and fiercely competitive. From custom sound systems to graffiti art, fans are deeply passionate about their favorite "Manyangas" (custom matatus). Javs of Nairobi wanted a secure, independent voting website where the community could vote on categories like Best Sound System, Best Graphics, and Best Driver.

From our first discussion, the client (*Javs*) was exceptionally nice, supportive, and placed absolute trust in my technical direction. They needed someone who could build a custom system quickly and handle the inevitable traffic storm. I agreed, knowing that the engagement would be explosive.

I was right. The moment Javs shared the link on TikTok and Instagram, traffic went through the roof. We registered 7,400 active users in 7 days.

The Reality: Constant User Feedback & Support Calls

With thousands of passionate fans competing to get their favorite matatus to the top, stakes were high. The moment the site launched, my phone didn't stop ringing.

I received constant calls and WhatsApp messages from users giving real-time feedback:

• "My vote isn't updating!"
• "Why is the leaderboards page taking too long to load?"
• "Is the voting secure? Someone is trying to cheat!"

While dealing with the pressure of live users, having a supportive client like Javs made all the difference. We aligned daily, triage-ing issues and communicating transparently with the community.

Technical Firefighting: 3 Problems We Solved Under Pressure

Building a high-traffic app in a sandbox is easy. Building one that survives thousands of concurrent Kenyan mobile users on various network speeds is a completely different ballgame. Here are the three main technical challenges we overcame:

1. Concurrency Bugs in the Voting Logic

To keep the voting fair, each user was restricted to one vote per category. However, when multiple users clicked "Vote" at the exact same millisecond, we faced concurrency issues (race conditions). Some votes were double-counted, while others failed to register.

The Fix: I rewrote the voting API to use database-level constraints. By adding a unique index on the combination of (user_id, category_id) in the votes table, the database itself rejected duplicate votes at the database level. I also introduced client-side optimistic UI updates and button debouncing to prevent users from spamming the submit button on slow networks.

2. The 1,000-Row API Limitation

As the votes climbed into the thousands, our leaderboard calculations began failing. The dashboard showed incorrect totals.

After digging into the logs, I realized the backend API was hitting the default limit of the database mapper (Supabase's API limits). By default, Supabase caps query returns at 1,000 rows to prevent server crashes. When we hit 1,000 votes, the frontend queries stopped seeing new entries.

The Fix: Instead of fetching all raw vote rows and summing them up in JavaScript (which is slow and memory-intensive anyway), I wrote a custom PostgreSQL database function (RPC) to run the aggregation on the server:

CREATE OR REPLACE FUNCTION get_category_vote_totals()
RETURNS TABLE (candidate_id UUID, vote_count BIGINT) AS $
BEGIN
  RETURN QUERY
  SELECT v.candidate_id, COUNT(v.id) as vote_count
  FROM votes v
  GROUP BY v.candidate_id;
END;
$ LANGUAGE plpgsql SECURITY DEFINER;

This allowed the database to return only the summarized counts (which were far fewer than 1,000 rows), making the leaderboards render instantly.

3. Supabase Database Connection Exceeded Limits

During peak hours, when popular influencers shared the voting link, thousands of users hit the site simultaneously. We quickly exceeded Supabase's free-tier database connection limit (direct PostgreSQL connections). The site started throwing 504 Gateway Timeout errors.

The Fix:

• Connection Pooling: I switched our database configuration from direct connections to Supabase's connection pooler (PgBouncer), which manages connection reuse efficiently.
• Caching results: Leaderboard totals didn't need to be calculated on every page reload. I cached the vote totals in the user's browser local storage for 60 seconds and only refreshed them when necessary, reducing database load by over 80%.
• Database Indexing: I indexed the votes table on candidate_id and category_id to speed up counting queries.

The Results and Lessons

By day 4, the platform was stable, lightning-fast, and running smoothly. Over 7,400 Kenyans cast their votes, crowning the winners in a transparent, tamper-proof system.

This project taught me two major things:

1. Client relationship is everything: Having a client like Javs who understands that software development is an iterative process allows you to focus on writing code rather than managing anxiety.
2. Design for scale from day one: Never assume traffic will be low. Always index your columns, use database-level constraints for business logic, and aggregate data on the server instead of the client.