AboutHow we built thisSponsorshipShop
SearchSubscribeDecision ToolsBusiness ModelsFrameworksReading Lists
Privacy PolicyTerms of UseCookie PolicyRefund PolicyAccessibilityDisclaimer

© 2026 Faster Than Normal. All rights reserved.

Faster Than Normal
DecisionsPeopleBusinessesNewsletterSubscribe
Start reading →
  1. Home
  2. Business frameworks
  3. Build feature requests on top of existing platforms

Build feature requests on top of existing platforms

20 min read

On this page

  • How It Works
  • When to Use This Framework
  • When It Misleads
  • Step-by-Step Process
  • Questions to Ask Yourself
  • Company Examples
  • Adjacent Frameworks
  • Analyst's Take
  • Opportunity Checklist
  • Top Resources

Contents

  1. 1. How It Works
  2. 2. When to Use This Framework
  3. 3. When It Misleads
  4. 4. Step-by-Step Process
  5. 5. Questions to Ask Yourself
  6. 6. Company Examples
  7. 7. Adjacent Frameworks
  8. 8. Analyst's Take
  9. 9. Opportunity Checklist
  10. 10. Top Resources
Every major platform accumulates a backlog of feature requests it will never build. The startups that mine those backlogs — shipping the functionality users are begging for on top of someone else's infrastructure — capture demand that's already been validated by millions of frustrated users.
Section 1

How It Works

The core insight is deceptively simple: the most popular software in the world is also the most complained-about. Every platform with millions of users generates a proportional volume of unmet needs — feature requests buried in forums, workarounds duct-taped together by power users, integrations the platform team deprioritized three roadmap cycles ago. These gaps aren't bugs. They're business plans.
The mechanism works because of a structural misalignment between platform incentives and user needs. A platform like Salesforce, Shopify, or Twitter optimizes for the broadest possible user base. That means features serving the 80th percentile get built; features serving the 95th percentile — often the most valuable, most willing-to-pay users — get ignored. The platform can't justify the engineering resources for a niche feature that serves 5% of users. But 5% of Shopify's two million merchants is 100,000 potential customers. That's a real business.
The underlying asymmetry is one of focus versus breadth. Platforms must be generalists. You get to be a specialist. You can obsess over a single workflow, a single integration, a single pain point — and build something ten times better than the platform ever would because you're not balancing it against ten thousand other priorities. The platform's inability to focus is your moat.
This framework also benefits from a powerful distribution advantage: the platform's own ecosystem. Shopify has an app store. WordPress has a plugin directory. Salesforce has AppExchange. Chrome has the Web Store. These are built-in distribution channels where users actively search for solutions to the exact problems you're solving. You don't need to generate demand — the platform already did that. You just need to show up where frustrated users are looking.
"Every big platform is an opportunity for a thousand small companies."
— Stewart Butterfield, CEO of Slack
The best practitioners of this framework understand that the end state isn't staying a plugin forever. The trajectory is: feature → product → platform. You start by filling a gap, accumulate users and data, and eventually build enough standalone value that you can exist independent of the original platform — or become so essential that the platform can't remove you without user revolt.
Section 2

When to Use This Framework

✓

Best Conditions for Platform Feature Building

DimensionIdeal conditions
Founder profilePower users and domain experts who live inside the platform daily. The best founders here are the ones who built the workaround for themselves first — they felt the pain, hacked a solution, and realized others needed it too. Technical fluency with the platform's API is a significant advantage.
StageIdeation through early traction. This framework is strongest when you're choosing what to build and need fast validation. The platform's existing user base lets you test demand in weeks, not months. Less useful at growth stage when platform dependency becomes a strategic risk.
Market conditionsBest when a platform is large enough to have millions of users but still growing — meaning the gap between user needs and platform capabilities is widening, not narrowing. Mature, stagnant platforms offer fewer opportunities because the ecosystem is already saturated.
Platform opennessThe platform must have robust APIs, a developer ecosystem, and ideally a marketplace or app store. Closed platforms (Apple's iOS in certain categories, for instance) limit what you can build. The more permissive the API and the more explicit the platform's commitment to third-party developers, the safer the bet.
Competitive environmentIdeal when the feature gap is clear but no dominant third-party solution exists yet — or when existing solutions are poorly built, poorly maintained, or overpriced. Check the app store ratings: a category full of three-star apps is a category waiting for a five-star entrant.
Inputs neededPlatform API documentation, community forums (Reddit, Stack Overflow, platform-specific communities), app store reviews of existing solutions, user interviews with power users, and competitive teardowns of existing plugins/extensions.
The framework is particularly potent right now because of two converging trends. First, the explosion of AI capabilities means you can build sophisticated features — natural language search, automated workflows, intelligent recommendations — on top of platforms that haven't yet integrated AI themselves. Second, the proliferation of no-code and low-code tools has lowered the cost of building integrations, meaning a two-person team can ship a credible plugin in weeks rather than months.
Section 3

When It Misleads

⚠

Failure Modes & Blind Spots

Blind spotWhat goes wrong
Platform risk (the "Rug Pull")The platform builds your feature natively, changes its API, or alters its app store policies. Twitter's 2012 API restrictions decimated dozens of third-party clients overnight. Zynga lost 80% of its value after Facebook changed its News Feed algorithm. Your entire business sits on someone else's foundation.
Feature, not companyYou build something genuinely useful but structurally incapable of becoming a standalone business. A single-feature plugin with a $5/month price point and no expansion path is a lifestyle business at best, a dead end at worst. Not every gap deserves a company.
Ecosystem saturationMature platform ecosystems (WordPress plugins, Chrome extensions) are crowded with thousands of competitors, many of them free or open-source. Discovery becomes the bottleneck — you've built a great product that no one can find in a sea of mediocre alternatives.
Misreading the roadmapThe feature you're building is already on the platform's internal roadmap. You ship, gain traction, and six months later the platform launches a native version that's free and deeply integrated. You've done their product research for them.
Value capture failureUsers love your feature but won't pay for it because they expect platform functionality to be free. This is especially common in consumer-facing extensions where willingness to pay is near zero. The value you create accrues to the platform, not to you.
Single-platform dependencyYou optimize so deeply for one platform's architecture that you can't port your product elsewhere. When the platform's growth stalls or its user base shifts, you're trapped on a shrinking island with no bridge to the mainland.
The single most common mistake is underestimating platform risk while overestimating the durability of the gap. Founders see a clear unmet need, build for it, gain traction — and then assume the platform will leave them alone. But platforms are rational actors. If your plugin is wildly popular, you've just demonstrated to the platform exactly what feature to build next. The more successful you are, the larger the target on your back. The only defense is to accumulate enough standalone value — data, workflows, multi-platform integrations, brand loyalty — that users would choose you even if the platform shipped a basic native version.
Section 4

Step-by-Step Process

Step 1 — Mine

Identify high-signal feature gaps on target platforms

Go where frustrated users complain. Shopify's community forums, WordPress's plugin request threads, Salesforce's IdeaExchange, and Atlassian's feature request boards are goldmines. Look for requests with hundreds of upvotes that have been open for years — that's the platform telling you they won't build it. Cross-reference with app store reviews of existing solutions: if the top-rated plugin in a category has 3.2 stars, the bar is low and the opportunity is real.
Tools: Platform community forums, G2/Capterra reviews, Reddit, Twitter/X, app store reviews, UserVoice boards
Step 2 — Validate

Confirm willingness to pay, not just willingness to complain

Complaining is free. Paying is not. Before building anything, reach out directly to users who posted feature requests. Ask: "If this existed, what would you pay?" Run a landing page with a price point and measure conversion intent. The threshold: if fewer than 10% of interested users would pay $10+/month, the gap may be real but the business isn't.
Tools: Typeform surveys, landing pages (Carrd/Webflow), pre-sale campaigns, direct outreach to forum posters
Step 3 — Assess

Evaluate platform risk and build defensibility thesis

Read the platform's developer blog and API changelog for the last 12 months. If they're actively expanding into your feature area, abort. Review earnings call transcripts for language about "expanding platform capabilities" in your domain. Map existing competitors in the ecosystem — if there are already 15 plugins doing this, you need a 10x better approach, not a marginally better one. Write a one-page defensibility thesis: why will this business survive if the platform ships a basic version?
Tools: Platform API changelog, developer blog, earnings call transcripts, competitive landscape mapping
Step 4 — Build

Ship an MVP that solves one workflow completely

Don't build a Swiss Army knife. Pick the single most painful workflow gap and solve it end-to-end. Your MVP should be installable in under two minutes and deliver value in the first session. Optimize for the app store listing: title, screenshots, description, and initial reviews matter enormously for discovery. Get your first 50 users through direct outreach to the forum posters you identified in Step 2.
Tools: Platform SDK/API, Figma for UX, PostHog/Mixpanel for analytics, Stripe for billing
Step 5 — Expand

Build toward platform independence

Once you have traction on one platform, begin expanding to adjacent platforms to reduce single-platform dependency. If you built a scheduling tool on top of Instagram, add Twitter, LinkedIn, and TikTok. If you built an analytics plugin for Shopify, add WooCommerce and BigCommerce. The goal is to shift your value proposition from "a feature for Platform X" to "a standalone product that integrates with Platform X." This is the critical transition from plugin to company.
Tools: Multi-platform API integrations, data export features, standalone dashboard, cross-platform analytics
Section 5

Questions to Ask Yourself

Discovery
What popular platforms have feature requests with hundreds of upvotes that have been open for more than 12 months?
Where are power users building ugly workarounds with spreadsheets, Zapier chains, or manual processes to compensate for missing platform functionality?
Which platform app stores have categories dominated by poorly-rated (sub-4.0 star) solutions?
Is the platform growing fast enough that the gap between user needs and platform capabilities is widening?
Validation
Have I confirmed that at least 20 potential users would pay $10+/month for this feature — not just that they want it for free?
Is this a feature that serves a high-value user segment (businesses, professionals, creators) rather than casual consumers with near-zero willingness to pay?
Can I identify a wedge use case narrow enough to dominate but broad enough to expand from?
Platform Risk
Has the platform publicly committed to keeping its API open and supporting third-party developers?
Is this feature strategically peripheral to the platform's core business — meaning they're unlikely to prioritize building it natively?
If the platform ships a basic native version of this feature, would my product still be 5x better for power users?
Can I build multi-platform support within 12 months to reduce single-platform dependency?
Long-Term Viability
Is there a credible path from "plugin" to "standalone product" — or will this always be an extension?
Can I accumulate proprietary data, workflows, or network effects that exist independent of the platform?
Does this opportunity support venture-scale economics, or is it a profitable but small niche?
Section 6

Company Examples

H
Hootsuite
Built social media management on top of Twitter, Facebook, Instagram, and LinkedIn
Hootsuite started in 2008 as BrightKit, a simple dashboard for managing multiple Twitter accounts — a feature Twitter itself didn't offer. The insight was that social media managers needed to schedule posts, monitor mentions, and manage multiple accounts from a single interface, and no platform had any incentive to build cross-platform tools. By 2012, Hootsuite had expanded to Facebook, LinkedIn, and Instagram, serving over 10 million users. The critical move was going multi-platform early, which made Hootsuite's value proposition independent of any single platform's API decisions. By 2023, the company reportedly generated over $250 million in annual revenue and served more than 200,000 paying customers. The platform that started as a missing Twitter feature became the category-defining social media management tool.
Z
Zapier
Built automation workflows connecting 6,000+ web applications
Zapier identified a gap that no single platform would ever fill: the need to connect different web applications without writing code. Every SaaS product had an API, but none of them had any incentive to build deep integrations with every other SaaS product. Zapier filled that structural gap, starting with simple two-step automations ("when I get an email with an attachment, save it to Dropbox") and expanding to complex multi-step workflows. Founded in 2011, the company reached an estimated $140 million in ARR by 2021 while remaining fully remote and bootstrapped until a $5 billion valuation round in 2021. Zapier's defensibility comes from the sheer breadth of its integration library — over 6,000 apps — which no single platform could replicate. It turned "missing integrations" into a $5 billion company.
Atlassian logo
Atlassian
Third-party apps built on top of Jira and Confluence
Atlassian's Marketplace hosts over 6,000 apps built by third-party developers, generating an estimated $2.3 billion in cumulative sales by 2023. Companies like Tempo (time tracking for Jira), BigPicture (project portfolio management), and ScriptRunner (automation for Jira) each built multi-million-dollar businesses by filling gaps Atlassian chose not to address. The pattern is instructive: Atlassian deliberately leaves certain feature categories to its ecosystem, creating a stable environment for third-party builders. Tempo, for instance, reportedly generates over $100 million in annual revenue — entirely built on top of Jira's infrastructure. The lesson: platforms that explicitly encourage ecosystem development create the safest conditions for this framework.
G
Grammarly
Built writing assistance on top of every text input on the web
Grammarly started as a browser extension — essentially a feature layer on top of Gmail, Google Docs, LinkedIn, and every other web application with a text field. No single platform had incentive to build a sophisticated grammar and writing assistant because it wasn't core to any of their value propositions. Grammarly filled that gap across all of them simultaneously. By 2021, the company had over 30 million daily active users and was valued at $13 billion. The critical insight was building horizontally across platforms rather than deeply into one — making Grammarly's value proposition platform-agnostic from day one. It's now so embedded in user workflows that it functions as a standalone product, not an extension.
YS
Yoast SEO
Built search engine optimization tools as a WordPress plugin
WordPress powers roughly 43% of all websites, but its core product has never included meaningful SEO tools. Yoast filled that gap starting in 2010, building a plugin that guided users through on-page SEO optimization — meta descriptions, keyword density, readability scores, XML sitemaps. By 2021, Yoast had over 13 million active installations and was acquired by Newfold Digital for a reported $100+ million. The company succeeded because SEO is critically important to WordPress users but perpetually outside WordPress's core roadmap. Yoast became so synonymous with WordPress SEO that "install Yoast" became standard advice in every WordPress tutorial on the internet — a distribution flywheel no marketing budget could replicate.
Section 7

Adjacent Frameworks

This framework connects to several others in the library — some as natural complements, others as productive counterpoints.
Pairs well with
Three-Star reviews
Three-star reviews on existing platform plugins reveal exactly where current solutions fall short. Use this framework to identify the gap; use three-star review mining to understand precisely what the existing solutions get wrong and what users actually want.
Pairs well with
Find processes for people and companies with a lot of steps and pain (friction) in going through and make fast and simple
Platform workarounds are friction incarnate. Users cobbling together multi-step processes with spreadsheets and manual copy-paste are telling you exactly what to automate. Combine with this framework to identify the highest-friction workflows on popular platforms.
In tension with
Category creation
Category creation demands you build something the market doesn't know it needs yet. Platform feature building is the opposite — you're serving demand that's already been articulated, often loudly. The tradeoff: lower risk but lower ceiling.
In tension with
Invent a new sport
Inventing a new sport means creating entirely new behavior. Building on existing platforms means serving existing behavior better. These are fundamentally different bets — one on novelty, one on execution within established patterns.
Apply next
Unbundling
Once you've established a foothold as a platform feature, unbundling helps you identify which slice of the platform's broader functionality you should absorb next — expanding from a single feature to a standalone product that replaces an entire workflow.
Apply next
Niche down
After initial traction, niche down to own a specific vertical or user segment within the platform's ecosystem. A generic Shopify analytics app competes with hundreds; a Shopify analytics app built specifically for DTC beverage brands owns a defensible niche.
Section 8

Analyst's Take

Faster Than Normal — Editorial View
My honest read: this is one of the most reliable idea-generation frameworks in the entire library — and also one of the most commonly misexecuted.
The reliability comes from the demand signal. When 500 users upvote a feature request on a platform's community forum, you don't need to guess whether the problem is real. When the top-rated plugin in a Shopify category has 3.1 stars and reviews that say "it works but the UX is terrible," you don't need a focus group. The platform's own ecosystem is doing your market research for free. That's an extraordinary advantage that most founders undervalue.
The misexecution comes from treating the platform as a permanent home rather than a launchpad. I see this constantly: a founder builds a brilliant Shopify app, gets to $50K MRR, and then spends the next three years optimizing within the Shopify ecosystem instead of building toward platform independence. Then Shopify ships a native version of their core feature, or changes its app store revenue share from 0% to 15% (which it did in 2023 for apps earning over $1M), and suddenly the entire business model is under threat.
The founders who win with this framework are the ones who plan their escape from day one. Zapier didn't stay as a "Salesforce integration tool." Hootsuite didn't stay as a "Twitter dashboard." Grammarly didn't stay as a "Gmail extension." Each used the platform as initial distribution, accumulated users and data, and then built enough standalone value that the platform became one integration among many rather than the foundation of the business.
The other mistake I see is building features that are too thin. A Chrome extension that adds a single button to a single page is a feature, not a company. The bar should be: could this eventually charge $50+/month to a business user? If the answer is no — if you're building a $3/month consumer convenience — you're building a hobby project with platform risk. The economics don't justify the dependency.
One more thing worth noting: AI has made this framework dramatically more powerful in the last 18 months. Every major platform is scrambling to integrate AI, but most are doing it generically. The opportunity is to build AI-powered features that are deeply specific to particular workflows on particular platforms — the kind of narrow, high-value intelligence that the platform itself will never prioritize. A Shopify app that uses AI to optimize product descriptions for a specific vertical. A Jira plugin that predicts sprint velocity based on historical team data. These are the next generation of platform features, and the window is wide open.
Section 9

Opportunity Checklist

Use this scorecard to evaluate whether a specific platform feature opportunity is worth pursuing. Score each item as yes (1 point) or no (0 points).

Platform Feature Opportunity Scorecard

The target platform has 1M+ active users and is still growing year-over-year.
The feature gap has been publicly requested by users (forum posts, app store reviews, social media complaints) for 12+ months without a platform response.
Existing third-party solutions for this gap are rated below 4.0 stars or have fewer than 1,000 installs.
The platform has robust, well-documented APIs and an explicit commitment to supporting third-party developers.
The feature serves business users or professionals (not casual consumers) with demonstrated willingness to pay $10+/month.
The feature is strategically peripheral to the platform's core value proposition — meaning they're unlikely to build it natively.
I can build a credible MVP in 60 days or less using the platform's existing APIs and SDKs.
The platform has a built-in distribution channel (app store, marketplace, extension directory) where users actively search for solutions.
I can identify at least two additional platforms where the same feature gap exists, enabling multi-platform expansion within 12 months.
I have a clear thesis for how this product becomes platform-independent within 24 months — accumulating data, workflows, or network effects that exist outside the platform.
I have domain expertise or daily-user experience with the platform that gives me an insight advantage over generic developers.
Section 10

Top Resources

01
Platform Revolution — Parker, Van Alstyne & Choudary (2016)
Book
The definitive academic treatment of platform economics — how platforms create value, how ecosystems form around them, and where third-party builders can capture durable advantage. Essential for understanding the structural dynamics that make this framework work, including network effects, multi-homing costs, and platform governance.
02
The Cold Start Problem — Andrew Chen (2022)
Book
Chen's analysis of how networked products launch and scale includes extensive discussion of building on top of existing platforms as a distribution strategy. The chapters on "come for the tool, stay for the network" are directly applicable — showing how single-feature tools evolve into standalone platforms.
03
Essay
The canonical essay on the trajectory this framework enables. Dixon argues that the best way to bootstrap a network is to start as a single-player utility — exactly what a platform feature is. Short, essential reading for anyone planning the transition from plugin to standalone product.
04
Academic paper
This HBR piece distills the strategic logic of platform ecosystems into actionable frameworks. Particularly useful for understanding when platforms encourage third-party development versus when they absorb it — the key risk calculus for anyone building features on top of existing platforms.
05
Inspired: How to Create Tech Products Customers Love — Marty Cagan (2017)
Book
Cagan's product management bible is essential for the execution phase of this framework. His emphasis on continuous discovery, rapid prototyping, and obsessive user research applies directly to identifying which platform gaps are worth building for — and how to build solutions users actually adopt.

Why this matters next

mental modelsNetwork Effects

Hootsuite applied the Network Effects mental model

mental modelsIncentives

Hootsuite applied the Incentives mental model

mental modelsUtility

Hootsuite applied the Utility mental model

mental modelsIntelligence

Hootsuite applied the Intelligence mental model

mental modelsScale

Hootsuite applied the Scale mental model

mental modelsEnvironment

Hootsuite applied the Environment mental model

Continue exploring

RR

Framework

Recent funding rounds

Analyze companies that have recently secured significant investment, identifying

UN

Framework

Unbundling

Breaking down a bundled product or service into separate, standalone offerings,

IA

Framework

Industry timing arbitrage

Apply newly developed technology from one industry to another that hasn't yet ad

AC

Framework

Acqui-Deaths

Identify opportunities created when large companies acquire startups, potentiall

TR

Framework

Three-Star reviews

Find business opportunities by analyzing moderately satisfied customers' feedbac

ND

Framework

Niche down

Focus on a highly specific market segment or customer base, becoming a specialis

More like this, in your inbox

I send a newsletter every week — free, no spam, unsubscribe anytime.

Or open the full subscribe page.

On this page

  • How It Works
  • When to Use This Framework
  • When It Misleads
  • Step-by-Step Process
  • Questions to Ask Yourself
  • Company Examples
  • Adjacent Frameworks
  • Analyst's Take
  • Opportunity Checklist
  • Top Resources