Product Engineering Roundtable: Building cross-channel analysis at scale

In this edition of our engineering roundtable series, we chat with Gautam Arora and Karan Singh from our Product Engineering team. Six months into joining us, they’ve moved from building standalone interfaces to designing systems that query billions of rows while keeping the UI intuitive. Here’s how they navigated that shift, and why every decision now carries real customer impact.

Clarisights Journal (CJ): Let's start with your backgrounds. What were you doing before Clarisights?

Karan: I was working at Trademarkia, an IP company dealing with copyrights and trademarks. My work was primarily frontend-focused. I built frontend for a copyright search engine that runs over all US copyrights, worked on patent filing portal, and even developed an e-signature platform similar to DocuSign. It was interesting work, but as I'll explain later, quite different from what I'm doing now at Clarisights.

Gautam: I was a frontend engineer at Headout, which is a travel marketplace platform where you can book tickets for experiences - think Burj Khalifa tickets or London theatre shows. I specifically worked on their microbrand sites, which were standalone websites for individual experiences, created primarily for SEO benefits and targeted advertising. I managed content through CMS systems, handled design aspects, and was in the middle of migrating our CMS from Prismic to Payload when I left.

CJ: Both very different scales and business models from what we do here. How has that transition been?

Gautam: The biggest shift for me has been the depth required in every project. At Headout, while the work was interesting, it didn't demand the same mental capacity that Clarisights does. Here, every project requires you to go deep, understand the entire system, and make decisions that have far-reaching implications. And you mostly have to figure things out on your own.

What really struck me is how every decision has gravity here. You can't just change one thing in the system without having joined-up thinking across frontend, database, and the entire product engineering stack. I'm still learning to adapt to this style of working: how to figure things out, how to take help from other engineers, and most importantly, how to make good decisions.

Karan: I faced similar challenges. The work I was doing at Trademarkia had more breadth. I built a lot of stuff, but it didn't have the depth I'm dealing with now. At Clarisights, the amount of planning you do before implementing anything is intense. You can't isolate a part and build on top of it. You have to understand the whole architecture before you can plan anything.

I made mistakes initially, pushed things that didn't land as expected, had to revert them, cover edge cases, and push again. You really need to know the entire surface area that can get affected because of the solution and how much damage it can do if it's not delivered properly.

CJ: Can you give us examples of projects where this depth really mattered?

Gautam: Let me talk about the Date Picker project I worked on. On the surface, it sounds simple, we needed to support future dates in our widget-level date picker to maintain parity with our global date picker. But the implications were huge.

Our customers, like Uber, create budget pacing reports. Say they have a $1,000 budget for August, and by August 15th they've spent $600. They need to project their daily spend for the rest of the month based on their current rate. For this, they need to select future dates and see projections. This is critical for their budget management.

What I thought would be a straightforward frontend task turned into a month-long project. I hadn't initially accounted for the backend changes needed: projection metrics, supporting all our date presets like "last 30 days" or "next month", ensuring everything worked with our projection calculations. The existing date picker code was six or seven years old, so I ended up refactoring it completely, making it modular so we could add new presets in the future without additional work.

When we finally shipped it to customers like Delivery Hero, seeing them actually use it daily for their budget planning - that's incredibly satisfying. You realise it is much more than just updating a UI component; you're changing how marketing teams manage millions of dollars in ad spend.

Karan: I'll talk about two projects. First, the refresh prompt: that notification you see at the bottom of Clarisights telling you to refresh when there's a new deployment. This might seem simple, but think about it: people open reports and might leave them open for days or even weeks. If we push changes and they're on an old version, their interactions might not give them expected results or, in the worst case ,affect our backend or database incorrectly.

The challenge was: how do you notify someone to refresh when they're not even interacting with the page? We couldn't use polling, that's inefficient. Instead, we used response headers from API calls. Every time the frontend communicates with the backend, we check the version in the response headers. If it's stale, we show the prompt.

We had extensive discussions about versioning strategy. Initially, I thought we'd use timestamps, but what happens when you roll back a deployment? Then we considered using Jenkins build numbers, but those could get reset. These small nuances required deep thinking about our entire deployment pipeline.

The second project I'm working on now is the Sanity Checker. This is crucial because we store metrics at different hierarchical levels: account, campaign, ad group, and ad level. If a job fails during ingestion, customers might not notice until they see mismatched aggregates across different levels.

CJ: Why should customers care about the Sanity Checker?

Karan: Right now, if there's a data mismatch, we manually create reports to check for issues. The Sanity Checker automates this completely. For example, A company with 7,000 metrics and hundreds of accounts connected - there's no way you can manually check all of those by creating reports. This tool will let us find sanity issues before customers even notice them.

Building this required understanding our entire architecture: how MorselDB works, how data is stored in Postgres, how metrics function, how we query Morsel. I discovered that certain campaign types like Performance Max don't follow standard hierarchies, so I had to make the system generic enough to handle these edge cases across different channels. Later I tested it on other channels like Facebook, Bing. And it worked perfectly because we built it to be channel-agnostic.

CJ: Both of you have had to work across the entire stack, not just frontend. Was that expected when you joined?

Karan: I wanted to do more backend-heavy work - I even mentioned this in my interview. But I didn't expect that in four to five months I'd be directly integrating stuff into Mozek. I thought we'd start with surface-level things and gradually go deeper.

Gautam: There are actually very few surface-level things at Clarisights. Everything is deep. It's like owning a car where you repair the AC and suddenly the trunk doesn't work: there's this weird interconnectedness.

CJ: What are you both working on now?

Gautam: I’m working on making our integration system config-driven. Currently, every new integration requires manual frontend code. We want backend configs to automatically determine how the frontend displays each integration, whether it uses OAuth flow like Facebook or form flow like Buzzvil. This will save enormous amounts of engineering time.

Karan: I'm finishing up the Sanity Checker implementation and working on integrating it into our Mozek pipeline. I'm also building a UI for on-demand sanity checks. On the side, I'm doing few API upgrades and planning a new integration.

CJ: Looking back, if the version of you before joining Clarisights met the current you, what would be surprising?

Gautam: I've developed critical thinking in a way I never had before. At my previous job, I just did what I was given. Here, even when a task is assigned, I do my own research and question why it needs to be done. That's the culture here: engineers ask the right questions before starting any project.

Karan: Similar for me. The expectation isn't just to complete tasks as assigned. It's to understand the actual problem and figure out the best solution. Recently, I had to integrate a metric, and the initial scoping was just a small part of what really needed to be done. That led me to dive into documentation, understand what the metric actually meant, and approach it from first principles.

CJ: Final question. Why should someone join the Product Engineering team at Clarisights?

Gautam: If you're willing to learn and have the capacity to absorb knowledge quickly, you should join Clarisights. It's not a comfortable job - you have to put in effort. You need to be self-driven. When I joined, I nudged Pratik, Bhupali, and Darshan in the Product Engineering team so much that I worried they'd get annoyed. (They didn't!) But that gave me crucial context about how our systems work. Someone who needs to be spoon-fed won't succeed here. You need to reach out, ask questions, and take ownership.

Karan: I'd add that you need general curiosity about how things work beyond just your assigned task, because everything is interconnected. What you learn in one task will help you in another.

CJ: This captures it perfectly. We've chosen to do cross-channel analysis at scale, which means even frontend engineers deal with multiple channels, sophisticated analysis, and massive scale. There are no simple surface-level problems here. Thank you.

For engineers who want to work on genuinely challenging problems where every decision matters, where you'll collaborate across teams, and where you'll see immediate customer impact, Clarisights offers a unique opportunity to grow rapidly while building systems that marketing teams at companies like Uber and Delivery Hero depend on everyday.