Building RAMP: Turning a Reporting Vision Into a Real Platform

This summer I interned at Doppel and built RAMP, the Reporting and Metrics Platform.

At Doppel, we execute takedowns at scale, and a lot of engineering energy goes into making the product better. The side people don’t think about as much, but that really matters, is showing customers what that work adds up to. Without strong reporting, even great automation is hard to translate into clear customer value.

Going in, I didn’t want a one-off script that spit out a PDF and died. I wanted a foundation that could support multiple report types over time: reusable sections, a clear way to run them, and contracts so each piece could evolve without breaking everything else.

What I shipped is that foundation, plus the first real auto-generated report on top of it: the Digital Risk Report — a threat-intelligence report for digital risk protection. The platform is built so that adding new blocks or report types later means smaller, more contained changes.

Even as an intern, I got to drive the project forward. I owned the direction and design of RAMP. That work was sharpened by a lot of discussion and feedback from my mentor, manager, customer success managers, product managers, and others, and it will continue being shaped that way. The platform is an engineering problem, but the narrative is a customer problem. Getting that right meant working closely with the people who talk to customers every day.

The problem

Customer-facing reports are expensive to create by hand. Sales and customer success teams have to pull metrics, choose which threats are worth highlighting, write the narrative, format the output, and keep it consistent. That doesn’t scale as we grow.

The goal of the project was to generate a repeatable report. The stretch goal I really cared about was configurability — building a platform that could support different setups, and eventually more report types, without starting from scratch each time.

The design: blocks, orchestrator, contracts

The architecture is simple to say but hard to make real:

1. Blocks — modular report sections like metrics, threat highlights, and report overviews
2. Orchestrator — runs configured blocks in order and passes shared context between them
3. Contracts — define each block’s inputs, outputs, and dependencies up front, so a block can change internally — or a new one can be added — without rewriting the rest of the pipeline

The report configuration drives which blocks run, what filters and metrics they use, and in what order they appear. Execution order (dependencies) and render order (presentation) are deliberately separate. A block can run because something else needs it, even if it doesn’t show up as its own page.

The first report type uses three main blocks:

• Metrics — deterministic lifecycle counts and median times from BigQuery
• Threat Highlights — curated threat evidence, sample selection, and carefully constrained LLM prose
• Report Overview — coverage and metric facts plus an optional, tightly validated synthesis sentence

Outputs are rendered PDFs.

What building it actually meant

A report sounds simple. In practice, a lot of product and content decisions had to line up: content selection, evolving metric definitions, top patterns, presentability controls, sample alerts, LLM summaries, PDF rendering, and how design helps tell the story.

I started with an MVP for generating reports locally.

Then that local system had to become a real end-to-end production workflow: API and durable run storage, Cloud Run, IAM and gateway routing, callbacks, frontend polling, and artifact delivery.

Making the report visually on-brand and telling the right story mattered too. With help from marketing and our brand design tooling, I moved the output toward Doppel’s visual system. The goal wasn’t to put as much information on the page as possible; it was to decide what belonged, what did not, and how design could guide someone through the narrative. If the report is how we show our value, it shouldn’t feel like an afterthought.

A non-linear process

I didn’t start with the final production system.

Design first — map where the complexity actually lived.

Then a spike — validate feasibility fast, fold in early peer feedback on markdown and slide outputs, and treat the spike as learning, even when it got big.

Validate with real use — generate artifacts for CSMs; their customer-level feedback shaped content and storytelling before productionization.

Rebuild for production — turn the spike into 100+ reviewed PRs, wire frontend and backend, and make the integration hold up.

The spike helped me learn fast. Productionizing it through smaller PRs made it something we could actually ship.

Using AI without letting it own the system

I leaned on AI-assisted development throughout the summer — plans, agents, PR stacking, tests — but I didn’t treat it as a replacement for judgment.

For the report itself, that meant being careful with how LLMs were used. They were helpful for writing, but the evidence still needed to be validated first, and the core metrics still needed to come from deterministic queries. Same idea with design: AI helped me move faster toward something more on-brand, but the final bar was whether the report felt good enough to send to a customer.

What I learned

1. How to drive an end-to-end system to production — from data and backend logic through deployment, permissions, and delivery.
2. How to use AI-assisted development responsibly — plans, small PRs, review, spikes, tests, and human judgment.
3. How Doppel’s systems actually work — what data is available, how it flows through the system, and how that shapes a report

This isn’t a fully solved problem. Every org looks a little different, so the storytelling, visuals, and metrics will need to keep improving over time. As our product evolves, the reports and their underlying platform need to evolve with it.

Why this mattered

What mattered most to me was getting end-to-end ownership over a pretty ambiguous problem. Even as an intern, I got to work on something big and impactful: taking RAMP from an open-ended idea to a real Digital Risk Report path from config → data → blocks → artifacts → delivery.

Huge thanks to Krish (mentor), Vinci (manager), Alex (PM), and the CSMs who gave me plenty of feedback on real report outputs and helped me ship.