Building Serin at Blink Analytics - What I Actually Do There

I work at Blink Analytics as a Full Stack Developer. The company builds product and service solutions, and the main thing we're working on right now is Serin - an AI-powered interview platform that automates candidate evaluation through voice and video interviews, integrity proctoring, and ML-driven analytics.

Serin is one of those products that sounds simple until you start building it. "Just run an AI interview" - sure, except you need real-time video, voice processing, proctoring to make sure nobody's cheating, analytics that actually mean something, and a backend that doesn't fall over when 50 candidates are being interviewed at the same time.

The Notification System

The first big thing I built there was the notification system. It sounds straightforward - send a notification - until you realize you need it across three channels: FCM (Firebase Cloud Messaging), in-app notifications, and email. Each with different delivery semantics, retry logic, and user preferences.

We landed on 30 event types with 7 live triggers. Every notification goes through a preference management layer so users can toggle what they care about. The background push uses a service worker, and there's deduplication logic so you don't get five identical notifications because a race condition decided to have fun.

The trickiest part was the deduplication. When you have multiple services trying to send the same event - say, "interview completed" triggers both an in-app notification and an email - you need to make sure the user doesn't feel spammed. We built a deduplication layer that groups related events within a time window and batches them into a single notification with a summary.

The Queue Service

This one's my favorite. We needed a job queue for background tasks - processing interview recordings, generating analytics reports, sending bulk notifications. The off-the-shelf solutions were either too heavy (Celery with Redis) or too fragile for our deployment target (Cloud Run, which scales to zero).

So I built one from scratch in Python with FastAPI. It's a middleware that sits between our API services and the actual job execution. The key design decisions:

• SQLite as the store - no external database dependency, works perfectly on Cloud Run
• Max 1 concurrent dispatch - prevents thundering herd when multiple instances wake up
• Linear backoff tuned for Cloud Run cold starts - if a job fails, it waits just long enough for the instance to spin up before retrying
• Docker deployment - containerized and ready to go

The result? Cloud costs dropped by about 70%. The original setup was burning through credits because Celery workers were sitting idle most of the time. Now we only spin up what we need, when we need it.

Landing Page Redesign

I also led the full redesign of Serin's landing page. The old one was fine - it existed, it loaded, it had text on it. The new one actually sells the product.

We built hero sections with animated illustrations, a feature accordion that expands on click, a testimonials marquee that scrolls automatically, pricing tables, a FAQ section, and a partner carousel. All of it with light/dark theme management via cookies so the preference persists across sessions.

The testimonials marquee was surprisingly tricky. Getting it to pause on hover, resume on mouse leave, and loop seamlessly without a visible jump required a custom implementation rather than a library.

Video Proctoring

The proctoring system is where things get intense. During an AI interview, we need to verify that the candidate is who they say they are, that they're not using external aids, and that the video feed is actually live (not a pre-recorded video being played back).

I integrated the queue service callbacks into the FastAPI backend, added liveness checks that run periodically during the interview, and refactored the session processing pipeline to handle edge cases gracefully. UUID validation was added to prevent tampering with session identifiers.

The Analytics Dashboard

The dashboard gives admins a real-time view of what's happening across all active interviews. You can see which sessions are in progress, which gates (proctoring checkpoints) are passing or failing, and overall stats at a glance.

There are stats pills that show key metrics, gate status banners that highlight issues, and API routes for pausing, resuming, or requeuing specific sessions. Everything is built to be actionable - not just "here's data" but "here's what you should do about it."

What Production Actually Teaches You

Before Blink Analytics, most of my experience was with side projects and freelance work. You build it, it works, you move on. Production is different.

Everything needs monitoring. Everything needs a fallback. If a queue worker crashes at 3 AM, someone needs to know about it. If a notification fails to send, there needs to be a retry path. If an interview session hangs, there needs to be a timeout and cleanup.

The biggest shift in my thinking has been from "does it work?" to "what happens when it doesn't?" That question changes everything - your error handling, your logging, your testing strategy, even your database schema design.

I'm still building. The work is far from done. But every week I'm shipping features that real users depend on, and that changes how you write code.