Essay
Distribution before development
Every founder wants to talk about the product first. What it does, how it works, what makes it different from the other twelve things like it. I get it — the product feels like progress. Distribution feels like a problem for later.
I ask a different question first: can you reach the people who would pay for this, today, without writing another line of code?
Building has gotten cheap. AI tools, no-code platforms, cheap contractors — the cost of putting something on a screen keeps falling. What hasn’t gotten cheaper is getting in front of the right hundred people and having them care. That’s the part that actually kills companies, and it’s the part almost nobody tests first.
Distribution Before Development: The principle that you must identify and validate a specific, testable channel to your first hundred customers before committing serious engineering resources. Not “we’ll run ads” or “it’ll go viral” — a channel you can point to, contact today, and test this week. If you can’t reach buyers now, the code isn’t worth writing yet.
Why founders get this backwards
Building feels concrete. Every day you write code, something exists that didn’t exist before. There’s visible progress — you can demo it, screenshot it, show it to investors. Distribution, by contrast, is uncertain. You’re trying to find people who have a specific problem and convince them to care. That process doesn’t produce anything tangible on a daily basis, so it gets deferred.
The logic teams use to justify deferral sounds reasonable: once the product is ready, we’ll figure out how to sell it. Once we have something to show, we’ll reach out to potential customers. Once we’re live, we’ll run ads.
That reasoning has a fatal flaw. You have no idea, until you try, whether you can reach the people who would pay for what you’re building. And by the time the product is ready, you’ve already spent the time and money you would have needed to find out. If the distribution doesn’t work, you’re not in a position to pivot easily — you have a full product, a specific feature set, and a sunk cost that makes it psychologically difficult to change direction.
Three specific failures follow from building before proving distribution.
You build for the wrong platform. Without a real channel driving early adopters, you default to “build for the web” because that’s what everyone does. But if the people who need your product live on mobile, or in a specific community, or use a specific tool, you’ve built something they can’t get to. The platform decision should follow from where your buyers actually live — not from what’s easiest to build.
You optimize for the wrong market. Without a specific channel forcing you to understand a specific segment, you design for a vague “general user.” The general user doesn’t exist. Products built for everyone resonate with no one. A channel forces specificity: the people in this Discord server, or this Slack community, or this mailing list have specific workflows, specific vocabulary, specific problems. Building for them produces a product that fits.
You burn time and money proving the wrong thing. Six months of engineering and then discovery that you can’t reach buyers is a much more expensive way to learn than running a simple distribution test before the build. The distribution test costs a week. The built product costs a quarter.
What “proven distribution” actually means
Proven distribution is not a theory. It’s not “we’ll partner with someone” or “we’ll cold email” or “we’ll post on Product Hunt.” It’s a specific channel you’ve already tested, at a small scale, and gotten real signal from.
The test looks like this: you can reach a specific group of people — community members, a mailing list, an audience, a professional network, a conference attendee list — describe the specific thing you’re building to them, and get a response that shows real interest, not politeness. People asking how to get access. People sharing it without being asked. People with the problem you described immediately saying “that’s exactly what I need.”
If you haven’t gotten that response yet, you haven’t proven distribution. You have a theory. That’s fine — theories are where you start. But you prove the theory before you build the product, not after.
Proven distribution typically looks like one of these:
A community you’re already in. You’re a member of a specific Discord server, subreddit, Slack workspace, or forum where the people with your problem congregate. You have credibility there. You can post about what you’re building and get a real response.
A list you already own. You’ve been building an audience — newsletter subscribers, social followers, past customers — who fit the profile of who you’re building for. You can send an email today and get replies.
A partnership you can close with one call. There’s a company, community manager, or platform that already has access to your target users, and you have a relationship that makes them likely to promote or integrate your product.
Direct access to the specific industry. You’ve worked in the space. You know the operators, the vendors, the conference circuit. You can pick up the phone and get in front of decision-makers without a cold outreach campaign.
What doesn’t count: social media followers who like your personal content but aren’t in your target market, a LinkedIn network that’s mostly recruiters and former colleagues from a different industry, a plan to run Google ads “once we know what converts,” a vague goal to “do content marketing.”
TitanFlow: where the platform decision came from distribution
In 2020, I was building TitanFlow — a real-time options flow platform for retail traders. The standard advice from everyone in the space was to build for web. Bigger addressable market, easier to build, standard for fintech tools. The web was crowded but it was “where people are.”
I pushed back. I wanted to know specifically where active retail options traders lived — not where people in general were, but the specific segment that needed real-time institutional flow data during market hours.
The answer was concrete. These traders spent their time in specific Discord servers and specific subreddits: communities organized around options trading, retail investing, and specific strategies. And they made decisions during market hours. During market hours, they were on their phones, not at their desks. The desktop tools they used were reference tools for research, not real-time decision tools. The real-time decision happened on mobile.
That changed the platform decision entirely. The web space was crowded. On mobile, we weren’t competing with anyone. The distribution channel — Discord servers and subreddits — was already on mobile. Our early adopters were already on the platform we were building for.
We built iOS-only. We seeded the beta through trading servers and subreddits. We made five partnerships with trading groups and fintech-adjacent tools for cross-promotion. One thousand signups the morning after the beta announcement. Fifty paying customers in the first week after App Store launch.
None of that required a paid acquisition dollar. The channel was proven before the product was built. The product was built for the channel, not the other way around.
Some Android users switched to iPhone to use TitanFlow. That kind of pull doesn’t come from advertising. It comes from a product so precisely fitted to the people using it that they’ll change platforms to get access. The fit happened because distribution came first.
Harvestdate: selling directly before the platform existed
In 2015, Washington state had just legalized recreational cannabis. Processors were tracking compliance data inside BioTrack — a state-mandated traceability system built for regulators, not for commerce. There was no vendor playbook for turning that compliance data into something a sales team could use.
The distribution question was: who are these people, and can you reach them?
Washington licensed processors were a bounded, identifiable group. They attended the same industry events. They knew each other. The cannabis industry press — Marijuana Venture Magazine, industry newsletters, conference circuits — reached them directly. This wasn’t a mass-market problem. It was a specific population with a specific compliance burden and no existing solution.
We validated distribution before we built the full platform. We sold directly to processors. We talked to them about the specific problem — getting live, buyer-facing inventory published quickly from a compliance system that wasn’t designed for it — and asked for payment. When they paid, we built. When they asked for specific features, we added them to the next chunk.
That direct sales motion was both the distribution proof and the wallet test happening simultaneously. Every processor who signed on was confirming that the channel worked and that the problem was worth paying to solve.
By the time Harvestdate was acquired in 2019, we had roughly 30 percent of Washington’s licensed processors. That penetration didn’t come from ads or viral growth. It came from a specific, testable channel — direct sales into a bounded industry — that we validated before scaling the build.
Named to Marijuana Venture’s Top 40 Under 40 in 2017. The recognition followed real adoption, which followed proven distribution, which followed a specific channel identified before major engineering investment.
The anti-pattern: building without a channel
The contrast is worth making explicit. The failure mode looks like this:
A team has a problem they want to solve. They’re excited about it. They start building. Six months later, they have a product. They launch on Product Hunt, post on Twitter, cold email a list they bought, run some Facebook ads. Nothing converts. They iterate on the product for another three months. Still nothing. They conclude the market doesn’t exist.
The market might not exist. But more often, they never found the channel. They built for an audience they hadn’t identified, then tried to find that audience with tactics that don’t work for a product without a distribution advantage.
The test that should have happened at week two happened at month nine, after burning most of the runway.
If you can’t describe, right now, a specific community, list, or network that contains your first hundred customers, and a specific way to reach them without paid advertising, you don’t have distribution. You have a theory about distribution. Run the test.
How to prove distribution this week
You don’t need a finished product. You need a specific channel and a specific message.
- Name the channel. Not “social media.” Which community, which list, which conference, which Slack workspace? Write the specific name of the place where your first hundred customers currently spend time.
- Test the message. Post or email or DM with a description of the problem you’re solving, not the product you’re building. Describe the problem as precisely as you can. Count who responds with “yes, that’s exactly the problem I have.”
- Count the real responses. Not likes, not “sounds interesting.” Replies that say they have the problem and want to know when they can pay for a solution.
- Set a bar before you build. If ten people from this specific channel respond with real interest, we build the MVP. If fewer, we revise the channel or the problem framing before writing code.
If you’ve run that test and you’re getting real responses but can’t figure out the right MVP to build for that channel, or if you’re not sure which channel to test first, that’s where a Sequencing Audit helps. We identify the specific distribution channel, match it to the smallest buildable thing, and sequence the rest from there.
Related: The Wallet Test — once you’ve found the channel, use it to get real payment before you build. The Chunking Theory — how to sequence what you build once distribution is proven.