App Center. Built an end-to-end app marketplace, designed billing architecture adopted by Semrush itself and cut 9-month partner integrations.

Semrush App Center is a marketplace for 60+ marketing apps inside Semrush — serving B2C users, B2B partners, and internal teams.

I joined as the founding designer when the product was at concept stage. No architecture, no billing infrastructure, no partner onboarding, no documentation — and a 15-year-old billing system that was never designed for anything like this.

Semrush had a large user base but no way to offer third-party tools inside the product. Users wanted more functionality beyond core SEO, and the company saw an opportunity to diversify revenue by turning Semrush into an ecosystem — a curated marketplace where partners could publish apps, and users could discover and buy them without leaving Semrush.

I was responsible for designing this ecosystem end-to-end: from how users find and buy apps, to how partners build and submit them, to how the billing system handles monetization models it was never built for.

Key Challenges

Legacy billing. Semrush's billing was 15 years old, never rewritten. One rigid model: one trial → one subscription → add-ons on top. No per-app trials, no standalone app purchases, no freemium. Everything we needed went directly against this architecture. > No partner infrastructure. Every partner onboarded manually via Slack. No submission flows, no documentation, no quality standards. Full integration cycle: up to 9 months, with manual checkpoints from design, compliance, security, and pentesting. > Starting from three. We launched with only 3 partner apps but needed the product to feel complete and the architecture to scale to 60+. Categories, search, discovery, monetization — all had to be accounted for from day one. > UX consistency at scale. Apps ran inside Semrush via iFrame — no direct control over partner UI. Apps needed to feel native and trusted, while each partner had different design quality, tech stacks, and standards.

I owned the entire user-facing product — storefront, app run pages, landing pages, and the feedback system. I built the early CJM to scope the MVP and set the design quality standards for every partner app inside Semrush.

Storefront

The key constraint: we were launching with only 3 external partners. To fill the storefront from day one, we also identified 3 internal Semrush tools that could be repositioned as apps — so the first screen wouldn't feel empty. But even with 6 cards, the product had to feel like a real marketplace, not a landing page. I started with competitor research and partner interviews, then built the early CJM to scope the MVP.

Using HubSpot and similar marketplaces as references familiar to our audience, I positioned the storefront around three promises: trusted Semrush ecosystem, single sign-on into partner tools, and guaranteed best pricing. Categories, search, and discovery were designed into the architecture from day one — but shipped incrementally as the catalog grew

I also designed dedicated landing pages for developers and users — positioning App Center as both an integration opportunity and a one-stop toolkit.

App Run Pages & iFrame

Apps ran natively inside Semrush via iFrame — no external redirects. We studied how Meta and others handled embedded third-party content and found no better alternative for keeping users inside the product. But iFrame created problems I had to solve across multiple teams. The first year was mostly SDK work — adaptivity, passing usage limits and trial states, triggering the rating system, controlling notifications. A major problem was layout: Semrush's standard page frame created a double scrollbar on partner apps, and on small screens it broke completely. I escalated this to the platform team and negotiated a dedicated run page view — a custom layout where all content scrolled inside the iFrame, with no competing page scroll. This required an exception from the design system team, which I had to justify with impact data and partner feedback.

Partner design quality was consistently poor and slowed down every launch. I created a 40-page design guideline as a Figma prototype — a condensed, partner-friendly version of Semrush's design system. It became the mandatory quality bar for review, cut cycles significantly, and later evolved into the documentation hub on the developer portal.

App Landing Pages

Each app had a dedicated SEO-optimized landing page with descriptions, trial options, and pricing — driving organic growth from search.

App Landing page — optimized for SEO and conversions, providing clear information about each app.

Continuous Feedback Loop

Low traffic early on made frequent A/B testing impractical. We had no clear signal on which partners to prioritize, and the iFrame made it hard to detect when partners changed things inside their apps. I designed a continuous feedback system with capture points at three key moments: - Homepage — when users were choosing between apps (expectation-driven) - Inside the app — during active usage (experience-driven) - At the churn point — when users tried to cancel a subscription or trial

The churn point became the most impactful — and getting it built required convincing the business.

Trials auto-charged after 7 days with no cancel button in the interface. Users were frustrated, and I saw this as a blocker to trial adoption. I proposed giving users an easy opt-out directly from My Apps. The business pushed back — they projected that a cancel button would tank conversion.

I reframed the problem: combine cancellation with structured feedback. Users could cancel, but had to select a reason — too expensive, doesn't work, too slow, not what I expected, too complicated. This turned a potential loss into a data source — for us and for partners.

To scale this beyond what I could manage directly, I built an infrastructure layer for partner teams — configurable feedback triggers based on user behavior, with documentation on how to collect and act on the data.

The feedback loop replaced the need for frequent standalone user research and kept every team connected to real user signals.

I led the design of the partner experience: research, CJM, portal MVP, documentation hub, and design quality standards.

Early on, every partner was onboarded manually through Slack. At first this worked — the team could give personal attention to each integration. But when we started onboarding 10–15 partners simultaneously, it became unsustainable. The product team couldn't do anything else.

I ran a survey among existing partners — the answers were consistent: visibility into app status, SDK keys, test environments, and clear submission steps. This shaped the MVP scope.

Research & Partner Tiers

I conducted interviews with partners and built a comprehensive CJM mapping the full process — from first contact to launch and ongoing support.

One insight from the research: not all partners needed the same level of hand-holding. Some were experienced SaaS teams who just needed documentation; others required step-by-step guidance. I introduced partner tiers — segmenting them by how much account manager support they needed at each integration stage. This let us scale onboarding without proportionally growing the team.

Portal MVP

Based on CJM insights, I designed the Developer Portal MVP — a self-service space inside Semrush where partners could manage apps, access SDK keys, and follow step-by-step publishing guides.

The portal gave partners a dedicated space inside Semrush with two entry points: Apps (create and manage) and Docs (guides for building and publishing).

App Center developer front page {color="gray"}

Documentation Hub

In parallel, I designed a Documentation Hub — the single source of truth for partners. Integration steps, API references, monetization setup, and mandatory design guidelines for quality review.

The design guidelines started as my Figma prototype and evolved into structured documentation. Over time, strict requirements were slowing integrations — but partners started learning from published apps and seeing the minimum quality bar in practice. We simplified to general principles and a self-check list built from the most common review mistakes.

This let us simplify the design requirements from detailed prescriptive rules to a set of general principles around honest, practical design — plus a self-check list built from the most common mistakes partners made during review.

Scaling Partner Integration

Integration cycles took up to 9 months with manual reviews from design, compliance, pentesting, and security. When we split into two teams to address this, I interviewed every person in the pipeline and built a parallel CJM showing both partner-side and internal steps simultaneously. This revealed duplicated steps, parallel opportunities, and unnecessary gates — we started systematically cutting cycle time.

We hired a product designer for the storefront team, and I shifted to a lead designer role overseeing both teams.

As the marketplace grew from 6 to 60+ apps, the team needed to manage trials, store sections, banners, partner requests, and feedback — without waiting for engineering. I designed an internal admin panel that became the operational backbone: product and partner teams could iterate on content, run promotions, and respond to user signals in near real time.

This was the most technically complex part of the App Center — and the part where my impact went deepest. I designed the business architecture of the monetization system, the billing logic for every purchase model, the admin flows, and the synchronization rules that kept everything from breaking. The infrastructure I built was later adopted by Semrush itself to sell its core tools independently.

The Constraint

Semrush's billing was 15 years old, never rewritten. It worked on one model only: one trial → one subscription → add-ons on top. Add-ons could only be sold attached to a subscription plan. This was fine at first — we started by registering apps as add-ons that users could purchase alongside their Semrush subscription. But there was a fundamental problem: users didn't trust new apps enough to pay upfront. We needed a trial system.

Building the Trial System

Semrush's billing only supported one trial tied to the main subscription — not per-app trials. So we built our own: a custom 7-day access period, after which we'd attach the Semrush plan + charge for the app add-on. This worked.

Then came in-app purchases and freemium — both registered as add-ons but needing to be sold situationally inside apps via SDK. Each model brought its own edge cases around availability, recurring vs. one-time limits, and duplicate purchase prevention.

The Hard Part: Selling Apps Without a Subscription

Then our researchers found that the App Center was a strong entry point for converting users to Semrush subscriptions — but users didn't want to buy both at once. This meant we needed to sell apps and in-app purchases independently from the core Semrush plan. In the existing billing system, this was technically impossible. Add-ons could only exist attached to a subscription. We evaluated 4+ approaches. None worked. The most viable option: create a new free plan called "App Center Access" (ACA) at $0 — a technical subscription that existed only so add-ons had something to attach to. But the billing system couldn't process a $0 charge. So the ACA plan always had to be bundled with an app add-on — never activated alone. And then the synchronization problems started.

Synchronizing Subscriptions

Three independent processes — our app trials, Semrush subscription trials, and manual sales extensions — could overwrite each other at any moment. A user's Semrush plan could silently downgrade when ACA was assigned; a sales-extended trial could desync with ours; an existing subscription could wipe app access entirely.

I mapped every combination of user state, trial timing, and subscription type into a comprehensive synchronization CJM — the blueprint engineering used to build safeguards.

Each new monetization model added more edge cases. We resolved all of them, documented the rules, and built sandbox environments for developers to test against.

Business Logic

The final system supported multiple monetization models — free, freemium, trial → paid, one-time purchases, recurring subscriptions, and usage-based limits — all on top of a billing engine designed for none of this.

Impact

The independent ACA plan became the foundation for a new revenue channel: users who wanted specific apps without the full Semrush suite could now buy them directly.

• Generated $6M+ ARR from customers purchasing apps without a core subscription
• Expanded Semrush's addressable market to users who wanted individual tools, not the full platform
• Opened a scalable business model inside Semrush without disrupting the main subscription

• $4.8M+ ARR and 2,200+ active users in the first 2 years. Today: $12M+ ARR, 62% YoY.
• $6M+ new revenue channel from customers buying apps without a core subscription.
• In 2026, developed a billing architecture adopted company-wide to unbundle the main Semrush subscription into specific toolkit plans.
• Transformed Semrush from a single SaaS product into a marketing ecosystem with an end-to-end partner platform.