
EsDeCode
Marketplace for scripts, plugins and templates

What seller outreach taught me about cold-starting a two-sided marketplace
When I started building a marketplace for source code products, I expected the difficult part to be technical.
Payments, seller accounts, product delivery, licensing, reviews, search, moderation, payouts.
Those problems are real, but they are also predictable. You can design them, test them, break them, and fix them.
What turned out to be much harder was convincing independent developers to list their products in the first place.
I have now contacted roughly 15 developers and small software creators whose products I thought would fit the marketplace.
So far, only one replied positively.
And even that did not turn into a completed listing.
That result was not what I expected.
I assumed that if the offer was reasonable, some developers would at least be curious. The marketplace did not require exclusivity, sellers could keep using their existing sales channels, and I was even willing to prepare the listing for them to reduce the amount of work.
Still, almost nobody responded.
At first, I thought the problem might be the email itself.
Maybe it was too generic.
Maybe the value proposition was unclear.
Maybe I contacted the wrong people.
So I changed the outreach.
Instead of sending the same message to everyone, I started mentioning the exact product I had found, why I thought it would fit, and what I could do to make the process easier.
I also removed as much friction as possible.
Instead of asking a developer to create an account, configure a profile, upload screenshots, rewrite the description, define the stack, and publish the product, I started offering something much simpler:
Send me your existing product URL and I will prepare the listing for you.
The seller would only need to review it.
From my perspective, that seemed like a significant improvement.
But it also taught me something important.
The main problem was probably never the amount of work required to create a listing.
The bigger problem was trust.
A seller looking at a new marketplace does not primarily ask whether creating a listing takes ten minutes or thirty minutes.
The real questions are closer to this:
Will anyone buy here?
Is this marketplace going to exist six months from now?
Is it worth adding another sales channel?
Will I have to maintain another product page?
Will this create support work without generating sales?
Why should I spend time on this instead of improving the channels that already work?
Those are much harder questions to answer.
Especially when the marketplace is still new.
A lower platform fee does not solve this either.
It sounds attractive to say that sellers can keep more of each sale, but a seller will happily pay a larger commission to a platform that already has buyers.
A smaller percentage of real revenue is more useful than a larger percentage of zero.
That sounds obvious when written down, but I underestimated how important it is.
I initially thought that seller acquisition would be mostly about finding good products and making a better offer.
I now think it is much closer to a trust problem.
A developer who already sells a product somewhere has very little incentive to take a risk on a new marketplace unless there is a clear upside.
And at the beginning, the marketplace cannot point to large traffic numbers, a long sales history, or a large community.
That creates the classic marketplace cold-start problem.
Buyers want to see good sellers.
Sellers want to see buyers.
Neither side wants to arrive first.
The temptation at this stage is to make the marketplace look bigger than it really is.
Add more products.
Create more categories.
Fill the homepage.
Make the catalogue appear active.
I do not think that is the right solution.
A catalogue full of products is not the same thing as a functioning marketplace.
What matters is whether real independent sellers want to participate and whether real buyers complete transactions.
One real seller who actively maintains a product is more valuable than dozens of listings that exist only to make the platform look populated.
The same applies to reviews.
One genuine review from a real transaction is more valuable than a page full of empty five-star signals.
So my goal has changed.
I am no longer focused on making the marketplace look large.
I am focused on making it real.
That means a smaller number of serious sellers, products with demos, proper documentation, clear licensing, and eventually real purchases.
The outreach experiment also changed how I think about seller onboarding.
At first, I approached onboarding like a software problem.
Build a good form.
Make the workflow simple.
Validate the data.
Automate everything.
Now I think early onboarding should be much more manual.
If a developer is interested, I would rather prepare the product page myself, fix the screenshots, organise the technical details, and help with the listing than force the seller through a polished self-service flow.
That obviously does not scale.
But scalability is not the problem when you have almost no sellers.
The problem is getting the first few people through the door.
Automation can come later.
Another thing I learned is that a positive reply is not the same as activation.
One developer agreed that I could list their product.
At the time, that felt like progress.
But the conversation did not continue.
That was useful in its own way because it showed me that “interested” is not a meaningful marketplace metric.
A seller is not acquired when they reply.
A seller is acquired when the product is live, the listing is maintained, and ideally when they eventually make a sale.
Everything before that is just part of the funnel.
So now I think about seller acquisition more like a sales process.
Contacted.
Replied.
Interested.
Listing prepared.
Listing approved.
Product live.
First sale.
That gives a much clearer picture than simply counting outreach emails or replies.
The current numbers are not impressive.
Roughly 15 developers contacted.
One positive reply.
Zero completed external seller onboardings from that outreach so far.
But I actually find that more useful than a fake success story.
It tells me exactly where the problem is.
The technical platform exists.
The seller terms are clear.
The listing process can be made easy.
The real challenge is creating enough trust and demand that an independent developer sees a reason to participate.
That is what I am working on now.
The marketplace is called esdecode.com. It focuses on source code products such as scripts, plugins, starter kits, templates, and self-hosted software.
At this stage, I am not trying to pretend that it is already a huge marketplace.
I would rather get the first few independent sellers who genuinely want to be there and learn from them.
If you have built a two-sided marketplace before, I would be especially interested in one thing:
What helped you convince the first supply-side users to join before you had meaningful demand?
Hey everyone,
I recently launched EsDeCode, a global marketplace for independent developers selling scripts, plugins, templates and other code assets.
The idea is to help developers turn reusable code into real products with product pages, licensing, author profiles and instant downloads. Buyers can discover PHP scripts, WordPress plugins, HTML templates and JavaScript tools in one focused place.
It is still early, so I would really appreciate honest feedback from other indie hackers:
Is the positioning clear?
Would you trust a marketplace like this as a buyer?
What would make you publish a code asset there as a creator?
Which categories should I focus on first?
What is missing before this feels like a real marketplace?
Website: https://esdecode.com/
Thanks for any feedback — especially from people who have bought, sold or built digital products before.
2 Likes
4 Comments
4 Comments
-
1
One thing I'd be careful with:
The challenge may not be whether developers will sell code assets.
The harder decision could be which side of the marketplace deserves to feel scarce first.
That sounds subtle, but it can shape almost everything that follows.
I wouldn't make that call casually this early.
-
1
That’s a very good point.
My initial focus is on building a curated supply of genuinely useful, production-ready code assets rather than filling the marketplace with a large number of low-quality listings.
At the same time, I’m trying to learn which categories are already attracting buyer interest, so the supply side is not being built in isolation.
I agree that deciding which side should feel scarce will have a major impact on positioning, quality control, and early growth. I’m still testing that assumption rather than treating the current approach as final.
-
1
That's exactly what made me think there's a bigger strategic decision underneath your approach.
I don't think it's really about supply or demand. It's about a business decision that becomes much more significant as the marketplace grows, and I don't think I can explain the reasoning properly in a thread without oversimplifying it.
If you're interested, what's the best email to reach you on?
-
-
-
1
This comment was deleted 3 months ago
About
EsDeCode exists to help independent developers turn scripts, plugins, templates and reusable code into real products.


Comment