The Build-Seed Inversion: Why Marketplaces Die Building Platforms Before Proving Transactions
At Tushky, we built a super easy service listing product. We created awareness campaigns. People came. People went. The funnel kept drying as soon as fuel was not injected.
We had built supply without demand, features without focus, distribution experiments without a single proven channel. We spent 18 months building before we understood what the market actually wanted to buy.
I’m calling this the Build-Seed Inversion — the mistake of optimizing for scale before proving a single transaction works repeatably.
The Question Most Founders Get Wrong
Most founder advice splits into two camps: “just ship” or “talk to users first.” Both miss the actual pattern. The question isn’t whether to build or validate. It’s what to build before you have market signal versus what to build after.
The Build-Seed Inversion happens when you invest in horizontal infrastructure, multiple distribution channels, and polish before you’ve made one specific transaction happen ten times in a row.
If you can’t describe your first 100 transactions in a single sentence, you’re building too early.
Tushky couldn’t. We said “connecting customers to service providers.” That’s not a transaction. That’s a category. Etsy could say: “craftspeople selling handmade goods to other craftspeople.” Slack could say: “small engineering teams adopting for internal communication, then spreading to other departments.”
The difference isn’t semantic. It’s strategic.
Supply Is Visible, Transactions Are Not
We built seller onboarding tools, listing templates, search algorithms. All supply-side infrastructure. But we hadn’t proven we could get a single customer to transact twice.
A marketplace isn’t valuable because it has supply. It’s valuable because it creates transactions. We confused the two.
Founders build the platform before seeding the transaction. They optimize listing quality before proving anyone will buy. They add payment options before proving anyone will pay.
This is the central confusion of two-sided markets. Supply is visible. You can count listings, profiles, sellers onboarded. Transactions are harder to measure, harder to manufacture, and harder to show investors. So founders default to the thing they can control and count. They build the stage and assume the audience will show up.
In India, this problem is compounded. Low average transaction values mean you need higher density to make unit economics work. A home services marketplace in Mumbai with 500 providers and 50 monthly transactions is a spreadsheet, not a business. You need thousands of transactions in a tight geography before the marketplace has any defensibility at all.
Five Verticals Is Five Companies
Tushky was for “anyone who needs services.” Cleaning, repairs, tutoring, photography, pet care. We built features for all of them.
Trello did this at scale. They built a horizontal product for tens of millions of users with a bleeding-edge stack. But they “didn’t do a good job of keeping track of paying customers.” They built for everyone and monetized no one effectively.
Slack went the opposite direction. They focused on “figuring out how and why its product spread from small teams, to departments, to larger organizations.” One transaction type. One expansion pattern. Then scale.
The horizontal product trap isn’t about product breadth per se. It’s about attention fragmentation. When you build for five verticals simultaneously, you build five mediocre products instead of one excellent one. Your feature roadmap becomes a political negotiation between use cases rather than a focused pursuit of depth.
At Tushky, we had separate onboarding flows for tutors and for plumbers. Different quality signals for photographers and for electricians. Each vertical had its own supply dynamics, its own customer expectations, its own trust thresholds. We were running five marketplace experiments and calling it one company.
The founders I’ve seen get this right — including the early UrbanClap team (now Urban Company) — picked one vertical and made it work obsessively before expanding. Urban Company started with beauty services at home. Not “all services.” Not even “beauty and repairs.” Just beauty. They built transaction density in one category in one city before adding the next.
Three Channels at 25% Commitment Teaches You Nothing
We tried corporate sales. Long, winding, uncertain sales cycles. We tried online affiliates. No success. We tried society activations. Some traction, but nothing repeatable.
We were running three distribution experiments simultaneously before we’d proven any channel could acquire a customer profitably.
The math was obvious in retrospect: if your CAC is unknown and your LTV is unproven, adding more channels just multiplies the uncertainty.
I see this in every startup cohort I’ve worked with at Pragmatic Leaders. Founders with 6 months of runway running paid acquisition, SEO content, partnerships, and community-building in parallel. They interpret the spread as “testing.” It’s not testing. Testing means running one channel with enough conviction and capital to get a statistically meaningful signal. Running four channels at 25% commitment each means you learn nothing about any of them.
One distribution channel, proven to unit-economics breakeven, is worth more than ten experiments running at subscale.
Etsy Found Existing Transactions First
Etsy targeted exactly one group: craftspeople selling to other craftspeople. Not “anyone who makes things” selling to “anyone who buys things.” One seller type, one buyer type, one transaction pattern.
They sparked transactions within that group successfully before branching out. The platform features came after the transaction mechanics worked.
The critical move was that Etsy’s early team went to craft fairs physically. They didn’t build a platform and wait for sellers to discover it. They found people already transacting and gave them a better venue. The demand and the behaviour existed before the technology.
What We Built vs. What We Needed
Here’s what we built before we had product-market fit:
- Service provider onboarding flows
- Multi-category listing templates
- Awareness campaigns that drove traffic
- Corporate sales collateral
- Affiliate partnership frameworks
- Society activation playbooks
Here’s what we didn’t have:
- A single customer segment that transacted repeatably
- Unit economics for any channel
- A clear answer to “which transaction are we optimizing for?”
The third missing piece wasn’t product features. It was transaction mechanics. We had supply, we had awareness, but we couldn’t connect early customers to unique sellers in a way that created repeat behavior.
The pattern holds across the companies I’ve worked with. The ones that scaled figured out seeding strategies before building horizontal infrastructure. The ones that struggled built platforms before proving transactions. A SaaS tool can succeed with a great product and decent distribution. A two-sided market dies without transaction density in a specific segment first.
The Sequence That Works
| Build Before Market Signal | Build After Traction |
|---|---|
| Minimum mechanics to complete one transaction | Horizontal features for adjacent segments |
| Single channel acquisition experiment | Multi-channel distribution |
| Manual processes that prove unit economics | Automation and scale infrastructure |
| Focus on one user segment | Expansion to broader market |
| Supply in one geography, one vertical | Supply aggregation tools |
The test: can you describe your first 100 transactions in one sentence? If not, you’re not ready to build for scale.
At Tushky, we inverted this. We built the scale infrastructure first. We optimized for millions before we’d proven hundreds.
The market eventually showed up — not for what we built, but for what we should have started with. Urban Company, Housejoy, and others entered the same space later with tighter wedges and better sequencing. They didn’t build better technology. They built the right things in the right order.
By the time we recognized the pattern, we’d spent 18 months building the wrong things in the wrong sequence.
The question I’m still working through: how do you know when you’ve proven “enough” transactions to start building horizontally? Ten transactions? A hundred? A thousand? The companies that got this right seem to have felt it rather than calculated it. I’m not satisfied with that answer yet.