12
37 Comments

I've reached out to over 5k developers without success. Is it time to pivot?

"Only I can know when it's time to pivot" is only partially true, and practically not very helpful.

For context, the product is a code marketplace.

I've reached out to over 5k developers over the past 12 months. I get a great response rate, but the answer is almost always (in one way or another) a no, meaning they are not interested in selling code.

Part of the problem is behavior. Buying code is an unusual activity (outside of themes and plugins) and changing behavior is difficult.

The other part is the nature of marketplaces. Amazon started with books. I don't see good way to do this with code. Even dividing by language is a large surface area. Further dividing it by a framework like React is still a massive surface area. Practically, this means that early users come looking for something specific and 99% of the time don't find it.

Is 5k a decent enough sample size to start drawing inferences?

  1. 7

    As a software engineer my concern around buying someone else's code is that it creates incentives where just one commercially motivated person is supposed to be maintaining, fixing bugs, adding features as needed, testing, and updating the code. This seems very unlikely unless the person has an adequately popular piece of code, and the marketplace is mature enough to pay them enough to take this on.

    The second biggest concern is that mixing in other people's code in to my project's is a form of technical debt for me. It's new code that I don't necessarily understand. It comes with new integrations that I need to make, and after I do I still end up with code written by different people and in different styles. This creates a lot of problems for me. I'm willing to overlook these problems if it's an open source project were there are lots of eyes on the code. I just have to be certain the wisdom of the crowd is greater than the alternative of writing it myself; or at least that the ROI for writing it myself is a worse option than using something open source.

    You would probably have more interest if you could try to bridge the gap between open source developers and the consumers of open source. Specifically, you would want to create a revenue stream for the open source maintainer out of corporate users of the code. A maintainer should be able to ask for donations, and get them from those using their code. Unfortunately this is something that usually does not happen. Instead open source maintainers usually just get harsh criticism from the very people who are benefiting most from the projects they are supporting.

    Of course then the question for any offering that tackles this, "Why would we go through a third party to connect us to a developer for pay for something I can get for free in FOSS." I don't have an answer for that at all. In fact I don't have an answer for any of this, but perhaps this feedback can help you ask a slightly different question. Instead of trying to figure out how to "sell code", perhaps you could try to figure out how to help existing coders monetize their open source work.

    1. 1

      to your first point:

      open source works like this today without a commercially motivated model.

      to your second point:

      I don't know what you'd be building where you don't use open source something.

      "other people's code in to my project's is a form of technical debt for me."

      That doesn't feel true and sounds like an enormous duplication of effort.

      1. 4

        Sounds like you have it all figured out then. Carry on.

        1. 1

          Not by a long shot. I wasn't trying to be disrespectful. I just disagree with a few of your points but I do appreciate the effort you put in to them

  2. 2

    Do you have a link to your site?

    1. 1

      It's on my profile. I didn't want to make this about the site, I just wanted to have a discussion around pivoting and the idea.

      The conversation immediately changes when people have the site to look at, whereas I wanted people's candid thoughts on it as opposed to feedback on one execution of the idea.

      1. 1

        Totally understand, I was having difficulty understanding what it was you were offerring and thought maybe other people might be also.

  3. 2

    5,000 people is an insane amount. That's almost 14 people per day over the course of a year. Based on those numbers, I assume you're pinging people through scalable channels like email, Twitter DMs, etc., which is fine. But how many people have you tried having calls or in-person conversations with? I find that you can dig a lot deeper, faster, and learn more by talking to people that way. Sure, it's not a great way to grow in the long run, but it's almost always the best way to start.

    My second question is: How many people are saying yes and actually putting code on your marketplace?

    If the answer is nobody, have you tried selling some code yourself? I would highly recommend getting the ball rolling and proving it's both possibly and desirable before you try to scale things into some sort of marketplace. Marketplaces are hard. I would never start with just a marketplace. Do it yourself, build an audience, then teach others how to do it, then organize them into a marketplace.

    If the answer is yes, and a few people have tried selling code, what was different about them? Did they already have code to sell or something? Were they already entrepreneurs? Were they open source contributors? Are they developers in a particular ecosystem? Does their code fit some profile? I'd find out what separates the yesses from the nos, then double down on methods to find more of the people who say yes. That might involve updating your pitch and your product as well to be more appealing to these people. As the wisdom goes: if something is working, do more of that and less of everything else!

    1. 1

      Thanks for your thoughts.

      The people that have listed items for sale on the marketplace had something ready to go right away (or the item was very close to being ready).

      I added 9 items for sale on the marketplace but again, the probability that I'm going to randomly (or through limited data) build the thing an individual developer is looking for is, on the margin, very low.

      1. 3

        Yes, this is why it's hard to start with a marketplace, especially with a large footprint. As you yourself identified, Amazon started with books, but it seems you're trying to start with everything.

        If you start there, then yes of course you're counting on getting lucky that visitors randomly want one of the things you built, which is unlikely. You need to keep shrinking the footprint smaller and smaller. What's the smallest footprint you can have for a marketplace? Easy: one single item on the seller side. Create a website where people come to buy one thing.

        The problem is you're trying to solve two problems: (1) building a marketplace for selling code, and (2) actually just selling code. Obviously #2 is a pre-requisite for #1. But the challenges of solving problem #1 are interfering with your ability to even learn how to do #2.

        At least Amazon knew that people loved buying books, and it had a large selection of books to sell. You don't even have that yet.

        IMO stop trying to build a marketplace for now and just try to sell a plugin. Improve, and tweak, and market, and advertise the hell out of that plugin until you can sell it. Give it all your attention. If you can't sell your own plugin, you shouldn't try building a marketplace where you're telling other devs that you can sell their plugins.

        But if you eventually can sell yours, then you can write about it, build up clout and trust, and have a more convincing and inspirational message to other devs. Not to mention you'll actually know more about selling code, having learned a lot in the process. You can publish helpful guides to that effect, teach what you know, and use education-based selling to get people on your platform. Your knowledge will probably also change how you think about building the marketplace itself, which will change the features you build into it, so it's more effective.

        Overall, I think the thing is just take one step at a time. It sounds like you're trying to start at the very end of your grand vision. Walmart didn't start as a mega chain. It started as just one store. Arnold didn't bench press 400 pounds on his first day in the gym. He worked up to it.

  4. 2

    When you are talking to the developers, are they giving any reason why they won't sell? Are they bound by NDA's? Is there an issue as to whether or not they would get paid, etc?

    Understand why developers won't sell is probably the first step. The second step is probably targeting developers or freelancers to build a product (similar to UpWork) and asking if they would like to produce the code in a standardized format so that they can make some "free money."

    Here to help. If warranted, my email is in my profile, and can answer more questions through a direct message.

    1. 1

      Thanks Ralph

      The #1 objection is that it’s not currently something they do (which, of course it’s not, it’s a new thing!)

      When I follow up to that it’s they don't have anything to sell (anything they feel that's ready to sell)

      I think the underlying issue is just generic marketplace problems. There's no signal that it's worth their time because frankly at the moment it's not. There's no supply and therefore no demand.

      A good question is how do I take a slice of this marketplace idea and execute it extremely well for a small segment of "software developers".

      1. 3

        Hey, just my 2 cents as a developer and a potential customer.

        • I would agree with the #1 objection you posted. The reason is that creating something "sellable" is way more work than it looks, and most of the time, people don't know how to wrap things up into a product.
        • If I buy someone else's code I become the owner of that. But the thing is, I don't want to own it, and therefore have to maintain it. I just want to benefit from it.

        Think about creating a marketplace where people can build and sell mini APIs that are packaged up and ready to use, without having to maintain them. I think there are some players in this space already, but I wouldn't call this a solved problem in the general case.

      2. 2

        Think incremental code canyon. They sell finished product/applications.

        Take a leaf out of their book. Learn everything about them. Who is their target market? What products sell the best ? How have they solved problems you're having now ?

        Let them show you the way. The real market is not the code snippets but the finished applications.

        Can you sell under a more permissive license than them ?

  5. 1

    Here is my opinion, another data point. I would pivot. Not sure if you have gotten 5K opinions yet for you to make the decision. Just kidding:-)

  6. 1

    Nothing kills a product faster than great advertising.

    Especially a poor product.

    Pivot.

  7. 1

    I read a lot of the feedback you received and I'm, generally, in agreement with the feedback you received. Besides the classic marketplace problem you have a problem that the barrier to entry for the buyer is really high.

    Like others said:

    • I'll become the owner/maintainer of this code that I didn't write and perhaps won't fully understand.
    • Integrating within a larger codebase will require work on the buyer side.
    • Finding a person to "hire" for a particular job is risky (shitty code, spec communication issues, etc) is hard and has a (non-monetary) cost (mostly of uncertainty) to the buyer. Even if you had a rating system for the sellers what 10 people perceive as a 5-star seller might be a horrible experience for a different buyer (due to the subjective work of code and the subjective state of the codebase where code needs to be integrated).

    As a developer, I had the same idea for a marketplace like this one years ago and decided against pursuing it: the germ of the idea is clear: "I have a lot of code that is self-contained and I'm sure someone out there has the same problem I solved with this code. If only I could find. them!". I decided against pursuing it because the problem is not the supply or demand of specific code. The largest cost is the integration of the code and the spec communication.

    [Spec communication is a problem that happens often even within teams that work together and know each other, working on the same product constantly and still, and even in those conditions, specs are often misunderstood].

    Me, personally, I would pivot immediately.

    The fact that you reached out to so many people means you've got what it takes to build something, it's just this idea will be orders of magnitude harder to execute.

    If you still don't want to pivot, I'd say that I would make the following. Perhaps you're already doing some. of these.

    • Code comes with a guarantee -- the seller will offer to maintain it for x years (how you enforce this is a separate question).
      *. Code is always packaged as a separate library with a very clear/well-documented API. This way you reduce the cost of integration in the main code base.
    • Buyer and seller should agree on a complete suite of BDD test cases that needs to pass for delivery. Something written in plain-language to lower the chance of misunderstanding.

    Hope this helps!

    @pablof7z

    1. 1

      I really appreciate the thought you put into this. I'm thinking through a pivot right now. I think it's time.

  8. 1

    Interesting, I see (I guess?) devs saying why this is happening, but without drawing conclusions coming from a sales standpoint, this is a clear stance with relevant sample size. The good part is that you sort of dodged a bullet and can move on.

    One thing that came to my mind is also Algorithmia, a marketplace for selling algorithms that had to expand on product offering, doing ML infrastructure solutions as they would probably never reach the growth they need with VCs being included. You can think if you can expand into other services since now you have 5k potential customers you talked to!

  9. 1

    I would pivot.

    1. Marketplaces require notoriously large amounts of money to get started, because you need to subsidize the sellers income to keep them interested until you have enough buyers.

    2. I have previously sold source code and every time the buyer insisted on me also doing the integration work into their website. So that business is services with a low profit margin and the license sale with a high profit margin. You're trying to cash in on the high-profit transaction but to make that possible I still have to suffer through the low-profit part. So for me as a seller, it's a bad offer.

    3. If you're not careful, you might be on the hook legally for things like presumed patent infringements inside the software sold on your platform. Also, you might get sued for lack of merchantability, meaning for bugs that prevent your customers from using the software that they purchased for the advertised purpose. Or if you push all of this liability onto the seller, it becomes an even worse offer.

    1. 1

      #3 is really important and easily forgotten or ignored until something bad happens. Thanks for bringing that up.

  10. 1

    1st question: who is your buyer?

    Is it other developers? If so, then its a hard sell. Its very difficult to sell source code to a developer. The 1st instinct is why would I buy if I can write my own or obtain via OSS?

    2nd question: is it pure source code you are selling on the marketplace?

    Pre-packaged OOTB solutions are different from source code as such. They solve a problem for devs (sometimes less experienced) or they solve a common/regular/mundane problem that devs have that they are not interested in solving and therefore would rather pay for.

  11. 1

    How about turning your attention to acquiring buyers instead? Sellers would be easier to acquire if people are queuing up to buy. So how to attract buyers with nothing to sell? You could engage with them 1-on-1 ('doing something that doesn't scale') and have them post a "Code Request" that describes what they are looking for. If you can acquire a healthy collection of requests then sellers should be more likely to engage. For the website, I entered a few searches and it returned nothing each time. How about a browse or a recently added feature?

    Best of luck!

    1. 1

      You fell into a trap!

      kidding (sort of). I moved signups to the bottom of the page. I wanted people to search just to see what they're looking for.

      1. 1

        Approach buyers.
        Find 5 you can convince to post a request for code.
        If you can't find anyone then pivot.

  12. 1

    I would be thinking about pivoting, creating a product is like building a really esoteric tool. Conceptually its like reverse engineering a screw driver from the screw pattern knowing that there are millions of these screws and no one is able to figure out how to unscrew them. You see the screw pattern, you know you need a tool, so you design a screwdriver that will work. At first it might be some crap like a piece of metal that you jam in there to unscrew it and your end state after iteration will be a perfect modern day screw driver.

    You can take this analogy and multiply it by 1000x for a software product. Trying to design a tool, without really understanding the market need, demand, and volume of the problem is a recipe for disaster.

    Marketplaces like you mentioned are inherently difficult to get started, even in a perfect ecosystem (think like offerup - you can sell anything, you aren't even limited to code only) - even that is hard to get started against competitors like fb/craigslist and the need to have buyers and sellers on day 1 to spark interest.

    With code any developer will say that languages and processes used in code solutions is a constantly evolving ecosystem, code integration is inherently difficult (Any competent developer will say that they would rather rebuild something from scratch than work on patchwork integration which can be a nightmare).

    A model that I could see working here is selling a modular section of code that works within a standardized format that can be integrated with little effort - or whole projects that can be used as templates to scale on - but even then I would need to see the code before I buy it to know if its good or not, and if anyone could see it before they buy it than how could you prevent fraud to capitalize on it and keep everyone incentivized to keep producing/consuming?

    1. 1

      important questions, thanks for your thoughts @combition

  13. 1

    What is code for you in this context?

    A 10-liner on java or whatever? A simple module? Complete library?

    And who are the customers? If it are also devs, why should I care and buy your code? What code do I get there which I do not get as open source at every corner? Wherr's the benefit for me as a buyer and seller?

  14. 1

    I think the most difficult part is on the side of the developer, where integrating code within existing infrastructure is a massive headache.

    If you manage to pivot towards a model where a developer can get paid by using a certain package manager, or maybe (preferably) an extension to an existing package manager, I think you're closer to hitting a sweet spot.

    Code on itself isn't really worth a thing when it cannot run.

    1. 1

      Thanks for your thoughts. I'm not sure I understand though.

      "If you manage to pivot towards a model where a developer can get paid by using a certain package manager, or maybe (preferably) an extension to an existing package manager, I think you're closer to hitting a sweet spot."

      How would that work?

      1. 1

        From an architectural point of view, consuming a package is easier than consuming an arbitrary piece of code. If designed correctly, a package will abstract away all the implementation details which make the functionality which has been implemented in a package complex.

        I believe abstraction is important for developers. It enables them to outsource some responsibility and complexity, which enables them to sleep at night and work at a higher pace.

        I imagine your product to enable monetization options for OSS developers. Closed source is not going to work since OSS has become mainstream. Because of this I would focus on 1) abstractions which help developers work faster 2) sustaining OSS development. What this would look like, I have no idea, but the most obvious place to start would probably be packages which can easily be consumed in code.

        Given the rise of serverless and no-code, maybe it would be interesting to look into snippets which can be bought, linked together, and paid for by each invocation. I believe something like this already exists in the blockchain space.

        Just some unfiltered thoughts.

        1. 1

          I think I see where you're coming from.

          Perhaps it is something more like a lambda/cloud function marketplace that you can click to deploy.

          That's not a bad idea to try next!

          1. 1

            I agree with Cortisan. It makes more sense to have a marketplace with ready to run code snippets (that are doing one thing) than with a marketplace of code. GitHub is a marketplace with code, stackoverflow is the place with code. Developers search there.

            But you can't run immediately code that you just found and use it with your own input (lambda function).

            Or you can try to sell boilerplates, here you have example of such list:
            https://jomlaunch.asia/24-tools-starter-kits-boilerplates-to-speed-up-your-saas-development/

            You can try to contact each of seller and partner with them (just idea).

            1. 1

              yeah if its a marketplace boilerplates might be the correct way to go about it. It's narrow. It's a thing people already do. Thanks for your thoughts!

          2. 1

            I had the same reaction as Corstian. Something like lambda would solve the integration problem with any new code.

            1. 1

              Interesting. I like that both of you came to the same conclusion. I'm not sure it solves the problem of what to seed the marketplace with initially though but it's a helpful thought.

  15. 1

    This comment was deleted 4 years ago.

  16. 1

    This comment was deleted 2 years ago.

  17. 1

    This comment was deleted 4 years ago.

  18. 4

    This comment was deleted 3 years ago.

    1. 1

      That's a very interesting objection that I haven't heard before that I agree with.

      All my devs (at my day job) use strict guidelines.

      That's actually really tough to overcome unless it's a black box, in which case the damn thing better "just work".

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 28 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 14 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments