Admiral’s Path to 130% NRR: The Technical Architecture That Makes Expansion Inevitable

Most SaaS companies treat expansion like a second sale. The customer wants additional capabilities. Sales schedules calls. Solutions engineering scopes the work. Professional services estimates implementation time. The customer waits weeks or months for new functionality. Friction accumulates at every step.

Admiral’s expansion motion looks different. A publisher using ad block recovery decides they want a paywall. They flip a switch in the dashboard. The paywall goes live. No new implementation. No professional services. No waiting. The infrastructure was already there.

In a recent episode of Category Visionaries, Dan Rua, CEO of Admiral, explained how architectural decisions made early in the company’s life created the technical foundation for 130% net revenue retention. The lesson: great NRR doesn’t come from sales tactics—it comes from making expansion effortless.

The Frankenstein Architecture That Admiral Replaced

To understand why Admiral’s architecture matters, you need to see what publishers were doing before. Every publisher had cobbled together what Dan calls a “Frankenstein” stack.

“Their VRM stack today, or when we started was kind of a Frankenstein of five different point solutions,” Dan explains. One vendor for ad block recovery. Another for email capture. A third for subscription paywalls. A fourth for privacy consent. A fifth for first-party data collection.

Each vendor required separate implementation. Each added a tag to the page. Each had its own decision engine determining when to engage visitors. The result wasn’t just operational complexity—it was technical chaos.

“You have five or six vendors to manage, it’s five or six tags to put on page, which screws up page load time and everything. And worst of all, it’s five to six vendors kind of fighting over the visitor journey,” Dan notes.

Publishers would show up on their own websites and get hit with three prompts simultaneously. The ad block recovery vendor would trigger. The email capture vendor would pop up. The consent management platform would overlay. Each vendor’s decision engine operated independently, creating overlapping engagements that destroyed user experience.

The One-Tag Decision That Changed Everything

Admiral’s core architectural insight was simple but profound: consolidate everything under a single tag with one decision engine.

“Once that tag is on page, they can just flick a switch to turn on everything across the journey with one decision engine that can avoid overlap of engagements and all sorts of things,” Dan explains.

This sounds like an implementation detail. It’s actually the foundation of Admiral’s entire business model.

When a publisher installs Admiral’s tag—often starting with just the free analytics to see their blocked traffic—they’re not just adding monitoring. They’re deploying the complete infrastructure for every module Admiral offers. The tag includes the capability to show paywalls, capture emails, recover ad block revenue, manage consent, and collect first-party data.

The modules are dormant until activated. But the infrastructure is present. This changes the expansion economics entirely.

Why Expansion Friction Kills NRR

Traditional SaaS expansion requires overcoming multiple friction points. The customer needs to recognize the need for additional capabilities. They need to budget for it. They need to get internal approval. They need to schedule implementation. They need to coordinate with their development team. They need to test before going live.

Each friction point represents a chance for the deal to stall or die. Priorities shift. Budgets get frozen. Key champions leave. Projects get delayed. By the time implementation happens—if it happens—months have passed and momentum is lost.

Admiral eliminated almost all of this. The recognition of need still happens organically—a publisher using ad block recovery sees results and wonders if they should add a paywall. But everything after that is frictionless.

No new implementation means no involvement from the publisher’s development team. No coordination means no scheduling delays. No testing cycle means no technical risk. The expansion is a configuration change, not a project.

The Land-and-Expand Model Built on Architecture

Admiral’s go-to-market strategy and technical architecture work together. They sell individual modules to land accounts, keeping the initial sale simple and focused. But the infrastructure for expansion is deployed from day one.

“We don’t have to sell everything at once. We can sell an individual module,” Dan notes about their land-and-expand approach. A publisher might start with ad block recovery because that’s the immediate pain point. But Admiral’s tag is already capturing data about email conversion opportunities, subscription propensity, and consent management needs.

Three months later, when the publisher’s ad block recovery is working well, the account team can point to data showing how much additional revenue a paywall would generate. The publisher can see the opportunity quantified. And more importantly, they can activate it immediately to test the hypothesis.

This creates a compounding effect. Each module generates data that reveals opportunities for other modules. Each success builds trust that makes the next expansion easier. And critically, each expansion happens without the friction that normally kills deals.

The Economics That Drove Series A Fundraising

When Admiral raised their Series A in 2024, they came armed with metrics that told a clear story about the business. “Burn multiple, just really strong birth, you know, well under one on burn multiple, really strong NRR 130% plus, really strong rule of X, you know, 100% plus,” Dan shares.

That 130% NRR wasn’t accidental—it was architected. The metric reflects publishers starting with one module and systematically expanding to two, three, four modules over time. The expansion happens naturally because the infrastructure eliminates friction.

The CAC efficiency comes from the same architecture. Admiral’s free analytics tag creates an installed base that self-serves initial deployment. Publishers install it to see their problems. When they’re ready to solve those problems, the infrastructure is already there. No expensive field deployment. No professional services overhead.

The result is unit economics that compound. Initial CAC gets amortized across multiple module purchases. Each module expansion is high-margin because it requires minimal incremental cost to activate. The lifetime value grows while the cost to acquire and expand remains low.

What Other Multi-Product SaaS Companies Miss

Most companies with multiple products or modules think about architecture as an implementation detail. They focus on feature development, assuming they can solve integration and deployment later.

Admiral inverted this. They started with the architectural decision that all modules would share one tag and one decision engine. This constrained how they could build features—everything had to fit within that unified system. But it created massive strategic advantage.

The constraint forced good decisions. Instead of building independent products that happened to share a brand, Admiral built a genuinely integrated platform. The decision engine can orchestrate between modules because it has visibility into all of them. A visitor who’s not ready for a paywall might be ready for an email opt-in. The system can make that judgment because it controls the entire journey.

Compare this to companies that build separate products with separate deployment processes. Each expansion requires project work. Sales cycles remain long. Professional services become a bottleneck. NRR suffers because expansion is hard.

The Principle Beyond Admiral

Admiral’s architectural approach offers a lesson for any multi-product SaaS company: architect expansion into your infrastructure from day one.

This doesn’t mean building every feature upfront. It means making architectural decisions that eliminate implementation friction for future capabilities. Some approaches:

Make your initial deployment include the infrastructure for future products, even if those products aren’t activated yet. Use feature flags and modular activation instead of separate implementations. Build one integration point instead of multiple per-product integrations. Design your data model to support capabilities you haven’t built yet. Create a unified control plane that works across all products.

The goal is making expansion feel like configuration, not like a new project. When customers can test new capabilities without coordinating with their tech teams, expansion accelerates dramatically.

Why This Matters for Your NRR

Net revenue retention above 120% separates good SaaS businesses from great ones. It signals that existing customers see enough value to expand spending significantly. But many founders optimize for the wrong variables.

They focus on having great features to upsell. They build sophisticated sales processes for expansion. They create customer success playbooks to drive adoption. All of this matters. But it’s not sufficient if the act of expansion itself is hard.

Admiral’s lesson is that technical architecture might be your biggest NRR lever. Not because architecture creates demand for expansion—that comes from product value. But because architecture determines whether expansion demand converts to expansion revenue.

As Dan frames it, the one-tag infrastructure with unified decision engine means publishers can “just flick a switch to turn on everything across the journey.” That’s the goal: make expansion so effortless that the only real question is whether the customer wants the capability. Not whether they can implement it. Not whether they have time for it. Just whether they want it.

When you remove friction from expansion, NRR stops being a sales challenge and becomes a product adoption challenge. And that’s a much easier problem to solve.