Features We Refuse to Build (And Why You Shouldn't Either)

"Can you build this feature?"

We hear it dozens of times per project. And often our answer is no.

Not because we can't. Because we shouldn't.

After 200+ marketplace builds, we've learned which features look good in planning but create problems in reality. Features that sound like improvements but hurt the marketplace. For context on what we've learned, see 200 marketplace builds: what we'd do differently.

Here are the features we refuse to build—even when clients push hard.

Feature #1: Off-Platform Contact Before Booking

The request: "Users want to chat before committing. Let's show emails/phone numbers on profiles."

Why clients want it: Seems like better UX. Users can discuss details. More "human" interaction.

Why it kills marketplaces:

Once users have direct contact, they have no reason to transact on-platform. They'll:

• •Negotiate directly
• •Pay directly (avoiding your commission)
• •Book future transactions off-platform

The data: Platforms that expose contact info before booking see 30-50% disintermediation rates. That's 30-50% of potential revenue walking out the door.

What we build instead:

• •In-platform messaging with conversation context
• •Contact info released AFTER transaction begins
• •Structured inquiry flows that capture intent

The principle: Enable communication, but keep the transaction on-platform.

Feature #2: Full Catalog Bulk Upload (Day 1)

The request: "Suppliers have existing inventory systems. Let's build CSV import and API integration from day one."

Why clients want it: Seems efficient. More listings = more supply = better marketplace.

Why it backfires:

Early-stage marketplaces need CURATED supply, not bulk supply. When you enable bulk upload:

• •Quality control becomes impossible
• •Low-quality listings flood the marketplace
• •Search results degrade
• •Buyers have bad experiences
• •Trust is destroyed before it's established

The Etsy lesson: Etsy manually reviewed every listing for years. Quality control built the trust that made the marketplace valuable.

What we build instead:

• •Manual listing creation with quality guardrails
• •Bulk upload only after:
  • •You have established quality standards
  • •You have moderation workflows
  • •You have data showing bulk suppliers perform well

The principle: Control quality until you have the systems to maintain it at scale.

Feature #3: AI Matching Before You Have Data

The request: "Let's build an AI-powered matching algorithm from day one. Like Spotify recommendations but for our marketplace."

Why clients want it: AI sounds sophisticated. Automated matching is the dream.

Why it fails:

AI needs data. Lots of it. Without transaction history, preference signals, and outcome data, there's nothing to train on.

AI matching with no data produces:

• •Random results
• •Poor matches
• •User frustration
• •Wasted development time

The Netflix reality: Netflix's recommendation engine was built on years of viewing data. They didn't launch with it.

What we build instead:

• •Simple rules-based matching (location, category, price)
• •Manual matching for high-value transactions
• •Data collection infrastructure for future AI
• •AI layer added after 10,000+ transactions with outcome data

The principle: Walk before you run. Simple matching with good outcomes beats sophisticated matching with bad outcomes. This is a key theme in why simplicity wins.

Feature #4: Native Mobile Apps for MVP

The request: "Users expect native apps. We need iOS and Android from launch."

Why clients want it: App stores seem like legitimate distribution. Native feels more "real."

Why we push back:

Native apps triple development cost and timelines. For MVP marketplaces:

• •You don't have enough users to justify App Store presence
• •App updates are slower than web updates
• •You need to iterate fast, and native slows you down
• •Most users discover you via web, not app store search

The exception: If your marketplace is inherently mobile (location-based services, real-time booking), mobile-first makes sense. But that usually means mobile web, not native apps.

What we build instead:

• •Responsive web app (works on all devices)
• •Progressive Web App capabilities (home screen install, offline)
• •Native apps added when:
  • •You have 10,000+ monthly active users
  • •50%+ of traffic is mobile
  • •You've validated the core experience

The principle: Prove the concept on web. Build native apps for scale, not for MVP.

Feature #5: Multi-Currency/Multi-Language Before Single Market Fit

The request: "We want to launch globally. Support for EUR, GBP, JPY, and translations for 8 languages."

Why clients want it: Global ambition. Bigger TAM. International sounds impressive.

Why it derails focus:

Internationalization adds enormous complexity:

• •Tax compliance per region
• •Payment processor variations
• •Legal requirements per country
• •Support in multiple languages
• •Currency conversion and pricing
• •Regional logistics

And you haven't even proven the model works in ONE market yet.

What we build instead:

• •Single market focus (one currency, one language)
• •Architecture that CAN support internationalization later
• •Expansion only after:
  • •PMF proven in home market (see how to know if you have PMF)
  • •Operations scaled in home market
  • •Specific demand identified in target market

The principle: International expansion is a growth strategy, not a launch strategy. See also why geographic constraint is almost always right.

Feature #6: Social Features That Don't Drive Transactions

The request: "Let's add user profiles, followers, likes, feeds—make it social."

Why clients want it: Social sounds engaging. More time on platform seems good.

Why it's usually waste:

Marketplaces exist to facilitate transactions. Social features that don't contribute to transactions are distractions.

Questions we ask:

• •Does "following" a supplier increase transaction likelihood?
• •Does a feed increase purchase frequency?
• •Does the social graph create matching value?

Usually the answers are no.

The exception: Some marketplaces have legitimate social components (Poshmark's sharing mechanism, Etsy's favorite shops). But these drive transactions, not just engagement.

What we build instead:

• •Features that directly impact transaction velocity
• •Social elements only when they serve matching or trust

The principle: Engagement metrics don't pay the bills. Transaction metrics do.

Feature #7: Subscription Revenue Before Transaction Revenue

The request: "Let's charge suppliers a monthly fee to list. Recurring revenue!"

Why clients want it: SaaS metrics look better to investors. Predictable revenue seems safer.

Why it usually backfires:

Subscription models for early-stage marketplaces create adverse selection:

• •Suppliers who pay monthly but don't get customers become angry
• •Suppliers who get lots of customers resent paying subscription + commission
• •The pressure is on you to deliver leads, not on the marketplace to work

The timing problem: Subscription revenue makes sense AFTER you've proven you can deliver value. Before that, you're charging for something you haven't validated.

What we build instead:

• •Transaction-based revenue (you only make money when suppliers do)
• •Subscription tiers added later for power sellers who want advanced features
• •Freemium tools to acquire suppliers, conversion to transaction when they sell

The principle: Align incentives first. Subscription revenue comes after you've proven you can deliver.

Feature #8: Blockchain/Crypto Payment "Because Web3"

The request: "Let's add crypto payments. NFTs for listings. Smart contracts for escrow."

Why clients want it: Web3 hype. Differentiation. Tech credibility.

Why it complicates everything:

Blockchain adds complexity without solving real problems for most marketplaces:

• •Users don't want to pay in crypto (fiat is still king)
• •Regulatory requirements multiply
• •Payment UX becomes more complex
• •You're solving a technology problem, not a user problem

The exception: Some categories benefit from blockchain (NFT marketplaces, international transactions with currency issues, verifiable provenance). But this is rare.

What we build instead:

• •Standard payment rails (Stripe Connect)
• •Blockchain infrastructure only when:
  • •Users specifically demand it
  • •It solves a real problem (provenance, international payments)
  • •You're willing to accept the complexity cost

The principle: Technology should solve user problems, not create interesting engineering challenges.

Feature #9: Reviews Without Transactions

The request: "Let's let anyone leave reviews to seed content and build trust."

Why clients want it: Empty review sections look bad. More content seems better.

Why it destroys trust:

Reviews that aren't transaction-linked:

• •Are easily gamed (fake reviews)
• •Have no credibility (anyone can review)
• •Create legal liability
• •Destroy the signal value of legitimate reviews

The Yelp problem: Yelp's credibility suffers because reviews aren't transaction-verified. A competitor review can masquerade as a customer review.

What we build instead:

• •Reviews linked to completed transactions only
• •Verified purchase badges
• •Review prompts triggered by transaction completion

The principle: Reviews are valuable BECAUSE they're verified. Unverified reviews are noise.

Feature #10: Admin Dashboards Before Product-Market Fit

The request: "We need comprehensive analytics, admin tools, CMS, and reporting from day one."

Why clients want it: Feels professional. Data-driven sounds good.

Why it's premature:

You don't know what metrics matter yet. Building elaborate dashboards before PMF means:

• •Tracking metrics that turn out to be meaningless
• •Building tools for workflows that change
• •Spending time on internal tooling instead of user experience

What we build instead:

• •Basic transaction tracking
• •Access to raw data (CSV exports, database access)
• •Third-party analytics (Mixpanel, Amplitude)
• •Custom admin tools AFTER you know what you need

The principle: Use off-the-shelf tools until you understand your specific requirements.

The Pattern

All these refused features share common characteristics:

1. •They solve imaginary problems: Not based on user feedback or data
2. •They optimize prematurely: Before the fundamentals are proven
3. •They add complexity: Without proportional value
4. •They delay learning: By extending development timelines
5. •They create technical debt: That constrains future decisions

The Conversation

When clients push for these features, we have a conversation:

"Why do you want this?"

If the answer is "I think users might want it" or "our competitor has it" or "it would be cool," we push back.

If the answer is "users have specifically requested this" or "we tested it and conversion increased," we listen.

"What happens if we don't build it?"

Usually, nothing bad happens. The marketplace works without it. Users transact.

The features that truly matter—if you don't build them, things break. Those are the features to build.

The Bottom Line

Saying no to features is one of the hardest parts of building marketplaces. Every feature seems reasonable in isolation. Every request has a justification.

But feature bloat is how marketplaces die slow deaths. Complexity accumulates. Focus dissipates. The core value proposition gets buried under features that seemed important but weren't.

The marketplaces that win are the ones that say no to most feature requests. That ship embarrassingly simple products. That add features only when there's overwhelming evidence they're needed.

We've learned to say no. Sometimes it frustrates clients. But it keeps projects focused on what matters: transactions.

---

Our Feature Philosophy

When you work with us, we'll say no to a lot of ideas. Yours and ours.

Not because we can't build them. Because we've seen what happens when teams say yes to everything.

We help you identify the 20% of features that drive 80% of value. We build those features well. Everything else can wait.

Let's scope your MVP. We'll tell you what you actually need—and save you from the features you don't.

---

Sources:

• •Paul Graham - Do Things That Don't Scale
• •Basecamp - Shape Up
• •Internal analysis of feature decisions across 200+ marketplace builds
• •Post-mortems of failed marketplace projects