Show HN: my weekend project, Gumroad | Hacker News Reader

Show HN: my weekend project, Gumroad

gumroad.com

396 pointssahillavingia202 comments

Over this past weekend I had the idea to build a sort of link shortener but with a payment system built-in. There have been many times in the past where I wanted to share a link - on Twitter or just through IM with a few friends - but did not want to go through the overhead of setting up a whole store.

So I built Gumroad. I coded/designed from 12PM -> 11PM on Saturday and 8AM -> 11PM on Sunday. There are still tons of features missing (I'm working on AJAX file uploading next!) but I think it's reached that - buzzword alert! - MVP stage where I want to see if anyone's actually going to use the darn thing (I'm thinking about taking a 30% cut).

Here's an example Gumroad link: http://www.gumroad.com/l/hjbaod - I use Stripe for payments. Here are some screenshots I took while making it: http://letscrate.com/gumroad/gumroad-progress - I didn't use Photoshop so no crazy time-lapses!

I think it has some potential. What do you guys think?

What does Stripe's fee structure look like?

Stripe reps have stated repeatedly that whatever their fee structure looks like right now, it's not representative of what it will look like when they come out of beta.

The only thing that I've seen that was commented on, but not objected to, is that it's 'similar to' PayPal fee structures. But even that's up to being refuted.

I love the idea! This makes it really easy to sell scripts (e.g. your own jQuery plugins or whatever) for $5 where it would normally be too much work to set up some payment processing.

The 30% cut is way too high though. Especially for higher priced links - I wouldn't want to sell my $99 game engine[1] through your service. I think something like "5%, but at least $0.30" would make more sense. But maybe having such "highly" priced links wasn't your intention in the first place?

[1] http://impactjs.com/ (Can't mention it often enough :))

Paypal already takes $0.30 plus a small percentage. I think the service is a neat idea, but microtransactions are not a solved problem.

Thinking about it, Gumroad is the perfect application for Bitcoins:

http://www.bitcoin.org/

No, it isn't. Bitcoins are clever and all, but how many people would be willing to set it up just to see a link?

Sure, at the moment only nerds use Bitcoins, but this _could_ become as universal as PayPal is today.

But yes, it probably doesn't make much (commercial) sense right now.

> Bitcoins [...] _could_ become as universal as PayPal is today

Putting aside numerous other issues, bitcoin.org states "The total eventual circulation will be 21 million bitcoins".

[EDIT: DanI-S pointed out that bitcoins can already be subdivided. So this was switched from "there are too few bitcoins to support even American e-commerce" to "bitcoins are not valuable enough to support even American e-commerce". The number of fractional bitcoins is still an issue, but less immediately.]

At the current ~$0.70 / bitcoin, this means that every American will be able to have ~$0.05 in his or her electronic wallet, once all bitcoins are generated. Assuming that the rest of the world does not participate at all and that bitcoins are evenly distributed.

Sure, you could imagine an instant dollar-to-bitcoin-to-dollar conversion at the point of payment. Or you could imagine a bitcoin2.org that generates more coins. Or you could hope for a massive surge in the value of the bitcoin.

I'd put my money on Paypal sticking around, though.

Bitcoins are already subdivisable to a whole bunch of decimal places.

The obvious hole in your chain of reasoning is that "$0.70/bitcoin" would obviously change when every American attempted to fill his wallet with bitcoins.

I'd put my money on paypal sticking around, but I'd also expect the volume on the Bitcoin/USD markets to increase as the value climbs (presumably from rate of new bitcoins from mining declining). I think we could see services using fractional bitcoins behind the scenes and USD (or euros) end to end.

I bet you could make some money facilitating lower fee transactions backed by bitcoins.

Bitcoins probably won't take off (cf the failures of all the other alternative digital currencies so far), but the whole number of bitcoins is no more a roadblock than the limited number of ounces of gold in the world was to getting everyone using gold as currency. The problems basically lie elsewhere.

Do you actually believe the price of a Bitcoin would remain statically frozen in the present, if everyone was using it?

Just a crazy idea, when something like NaCl catches on perhaps gumroad could generate bitcoins client-side in lieu of payment?

[EDIT: the text below is correct, but a bit too snarky. My apologies.

Also, the site owner could just trust the client to actually run his/her bitcoin-generating code for a couple of hours and send any generated coins - this should earn him/her ~$0.20/hour, rounded down because lots of people have crufty computers. Still not feasible, and generating bitcoins will only get harder in the future, but not as bad as I suggest below.]

Sure, if you're willing to leave your browser consuming 100% CPU for a couple of weeks. And if you're willing to pay the entire resulting 50 bitcoins (~$40-45) you generated (at the cost of ~$60 in electricty, I'd guess)[1], or trust the site to return you the rest. In either case, you'd need to trust the site code to tell you that it's generated a coin, instead of silently sending it back to the server and continuing to run.

At least, that's my understanding of how bitcoins work.

[1] Only GPU-based generation is currently profitable, and there's no way NaCl can be given full access to the GPU - GPUs typically have DMA access, so being able to run arbitrary code on them is more or less equivalent to kernel-level access. In theory, you could verify the GPU code - but that's an enormous job, and there are lots of GPUs that you'd need to check for security holes. And security was not design criterion #1 for these devices, I'd guess.

Something like DirectX/OpenGL access makes sense, but running crypto algorithms through OpenGL (instead of CUDA or the like) is probably infeasible.

Good points. I figured it was probably totally infeasible, thanks for filling me in on why.

I like that idea. It seems like microgeneration is a feature Bitcoin is currently suffering from a lack of. As competition increases, generation seems to be more and more centralized. A low-traffic way to generate small amounts of Bitcoin in a peer-to-peer network would be a great addition to a future Bitcoin protocol.

This doesn't seem like a good match. With different hardware and prices of electricity out there it would be hard to make the system fair for everyone. Also, although minting coins is an important feature of Bitcoin, it seems there's a certain amount of miners needed to offset threat of fraudulent transactions; going significantly above that amount is just wasting planet's resources.

I can't imagine bitcoins in their current implementation gaining traction as a form of payment with 'regular folks'. I mean the whole idea is complicated enough that even I as a technically minded person have trouble fully understanding how it works.

Plus it's not clear to me that there are enough bitcoins to go around. Some comments below point out the fact that bitcoins can be divided down to multiple decimal places. That's great and all but I can't imagine a 'regular person' being comfortable with the idea that they currently posses .00152 bitcoins. I doubt most people think of a penny as .01 dollars, because fractions are confusing. Plus even if that .00152 bitcoins is enough to buy a car, it still just seems like a minuscule amount.

I don't mean to be a huge downer. I think bitcoins are an interesting idea, but if you want to sell things now a more traditional payment method would probably make sense.

PayPal has a lower tier for sales under $12: https://merchant.paypal.com/cgi-bin/marketingweb?cmd=_render...

Still, you need to take fees into consideration. Also, the seller has to pay another PayPal fee when transferring the money every month.

And it has to be a completely separate account. They basically force you to either pay way too much or violate their terms by having two separate accounts. :/

You definitely don't want to use PayPal for a service like this, unless you want to lose all your un-swept earnings when they catch on.

PayPal's TOS specifically prohibit running a payment gateway or aggregation service, ie collecting payments on behalf of many sellers and then re-distributing the proceeds.

A service like this would almost certainly draw their attention, since one could be selling warez, pr0n, stolen credit card numbers, or any number of other naughty files through this service...

Someone else posted a tale of woe within the last month about their "experience marketplace" getting impounded by PayPal, ostensibly for the same reason.

Paypal released a micropayment platform this year http://www.readwriteweb.com/archives/paypals_micropayment_so...

<<The solution was first announced last October when the company said that the upcoming feature would offer "a competitive fee structure for micropayments, with pricing at 5 percent plus 5 cents for purchases under $12.">>

No, that's definitely a good point. I'm going to switch to a .30c + x% (tiered) model - aim to make at least $70-80 of that $99 if you use Gumroad.

I'm also thinking hard about "Preferred" accounts. Basically, you send an email to sahil@slavingia.com in the next 24 hours, whenever I do your balance at the end of the month you get as much as I can give without losing money on the transaction. ;)

I disagree. Take a bare minimum of 15%. That seems to be about what's competitive for non-merchant-account payment systems. You'll need to keep margins up.

Exactly. And keep in mind, you're competing against someone setting up their own web store. If I didn't use your service, I probably wouldn't go through all of the trouble of setting something up. In that scenario, I make $0. If you charge 30%, and I price my stuff at $10.00, I make $7 per transaction, which is $7 more than I would have made without your service.

It's a weekend project. Implement your own and charge less.

how are you using stripe already?

I'm friends with one of the founders + I asked repeatedly.

I've tried it and purchased on my own link.

1) How soon until the money reaches PayPal? 2) There are no assurances that the CC data is safe. It looks to be sent over HTTPS, but you're assumed to be trusted.

Awesome! I'm doing Net 60 as that's what Stripe does. The CC data is safe, but of course there's no reinforcement on-site. I'll add something.

Net 60 days? I would assume that users expect near real-time if PayPal is the back end. 60 days sounds way too long.

I'd assume it's at least partly to deal with fraud.

Posted on it as well. http://blog.louisgray.com/2011/04/gumroad-launches-to-sell-d...

Wow - that's fast feedback! On a separate side-note would you be interested in early access to apps for similar sort of reviews / blog postings, or is that inappropriate to ask?

That's not inappropriate to ask at all. It's a fun hobby. Look through my site and you'll see I've done this a long time and have some big wins that launched first with me.

(TweetDeck, Beluga two examples)

Gumroad will be another. :)

Cool idea! One quick thing: I would change the "(Minus our cut)" wording to something a little more friendly. Maybe transaction fee or something along those lines.

I would include a sample URL or two on the homepage - I was confused as to how I would get people to buy/what the sales page would look like - but thanks for clarifying with the attached URL.

Suggestion: you should now build a second app which generates a stream of single-use urls that are invalidated as soon as they are accessed, and which proxy through to an original base url. Then hook the two apps together and profit.

Love the idea! I'd also love a thumbnail/pic for each link, though. Something that might give them a little more evidence of what they're getting into.

That's one hell of a cut.

Could you add the option to let the payee set the price? That would be great for donations and pay-what-it's-worth-to-you transactions. :)

Interesting idea, but I see two main issues with this.

First, anyone who pays and gets to the resulting link can trivially share that link; of course, you can always ask them nicely not to do so, and in some contexts that will work, but in general the security model just doesn't work unless you authenticate each paid user at the destination. You need to come up with an answer to this.

Second, if you market this as a link shortener which requires payment, I think you'll get backlash from people who currently use link shorteners to share links on Twitter and similar; from that perspective it feels like the kind of thing you'd see used by Twitter spammers/scammers. Suggested fix: flip it around, and present it as an astonishingly simple payment system based on URLs, which happens to behave like a shortener.

That second formulation is how I thought of it in the first place.

You could get around the link-sharing problem for those that wanted to avoid it by offering single-use URLs, and provide Gumroad either with a way of generating a new single-use URL for your resource, or a way to pull a new URL from your site. Both of these methods would require some degree of control over the resource, however (you wouldn't be able to do this for content hosted by third parties).

For those who aren't fussed about security, you could offer it as a really easy way to optionally pay for content - eg a rapid "Donate" method.

We used something like this for our content at Naughty America.

For each page request we'd generate a link to the file on BitGravity with a timestamp, expiration, and filename, and a hash generated from those concatenated with the requesting IP and a secret key. On BitGravity's end, they'd re-hash everything, and if it matched up they'd serve out the file.

Interesting, I didn't think about the implications of "donate."

Kind of tangentially, I wonder if there's value in letting a user select a charity to donate all of their sales to (no pressure on the user, just an option)?

To address the first problem, you should offer a passive solution and not require the user to set up anything special in the way of single-use URLs. In fact, I assumed the issue of payers sharing the end-link was such an obvious problem that the service would have already addressed this and had it built-in by default (but of course, MVP/first-release, I understand).

The way I'd see it working is, I give Gumroad a link I want users to pay for, and Gumroad charges each user, serving up the content, but never sharing with them the link that I gave Gumroad. You could do this by fetching the content on the back end, and serving it up through Gumroad's own single-use URL.

Sure, that would make sense for content that could be so served (for example, the pencil icon used as the example here) - but not all content is like that. What about content you want people to interact with (a blog post on your site, a special beta registration form)? You also take on all the problems of becoming a content distributor rather than a link distributor.

I agree with everything you said. If this were my project, these are all problems I'd be thinking about and trying to address. Looks like you're on the right path ;-)

I'm thinking about them hard. :)

and I would add that the content distributor problem is also a good one to solve (with your solution). May even be more profitable... a lot of people want to sell stuff, not link.

Another interesting variant might be: payment unlocks the destination link for X minutes. (After that, the true destination URL is changed somehow. Yes, that adds complication on the true hosting site or the necessity for Gumroad to proxy.)

So in a sense you don't care if people share the link for that period... maybe you even want them to, like a time-limited offer, so that they post to all their friends, "get it while it's hot!"

(The price could also rise or fall after each purchased open-period... perhaps even, depending on the number of downloads during the last open period.)

I like the idea of the proxy, why not have it so you do a direct link and gumroad takes a small percentage (1%?), and if you want it proxied gumroad takes a bigger percentage (5%-10%)?

The service could send a special "auth" key along as parameter when forwarding. E.g.: http://example.com/secret.php?key=dh498

In secret.php on your server you could then ask the Gumroad API (via another http request) how often this key was already used and deny or allow access. This would be super easy to implement for the seller - just paste in ~5 lines of PHP code.

You could allow access to that link about 5 times. After that, display a link that says something along the lines of "Thanks for using us. This link has been used 5 times already. If you wish to access it again, click here and we will send you an email with another authorization code (or whatever)". That way your users don't lose access to their stuff, and you can keep track of abuse. It's not a perfect solution, but it's better than nothing.

I think #1 is a bit of a red herring. The security problem is not what this is solving. It's the ease of getting paid for some content, with less hassle overall.

Keep in mind that this is digital content so anyone could just rehost/resell/redistribute anything they bought or downloaded. But for something low-payment enough or the average silly download, why would they bother?

It's important to tell sellers that it's insecure so they don't assume it's locked, but please don't complicate this by adding DRM or sharing prevention. The most I'd do here is track downloads and let people kill their link and repost it if they sense abuse.

The difference: sharing the file violates the original author's copyright, but sharing the URL to it on the original author's site doesn't.

I actually wouldn't recommend adding DRM or sharing prevention. Instead, I'd just add a lightweight system to make it trivial to know who shared the URL. That will likely do wonders for getting people to play nice.

Optionally, you could add proxying through the gumroad site as an extra feature (perhaps at the cost of a higher margin on the sale), for people particularly concerned about the issue.

Think long term adjustment to the mentality of the site. If that link was worth something, why would the buyer just give it away? It's possible that the buyer would try to sell it and compete with the original seller, and all subsequent buyer might follow, but that would be something the original seller could take into account in pricing their product.

I agree that the link shortening aspect of this site cannot be it's product. Emphasizing that at all can detract from the truly novel idea that exists in selling and buying micro-properties of internet knowledge. People need to see the incredible nature of a site which allows you to sell information which has high demand and low supply, but has no other method of paid distribution. For everything too small to put in a book, and not small enough to just give away. I think its brilliant.

I haven't thought much about this solution, but wouldn't it be simple to just proxy the content back to the user? This would work fine for downloadable goods, maybe not so much for secret links to sites.

Here's how I would structure things to mitigate link sharing. It won't prevent it entirely, but will reduce it about 100x without affecting UX.

Your links can be one of two things: 1) a webpage, 2) a file.

For a file, I wouldn't worry about the DRM, as a person serving the file can have their own system, or you can use the system I'm going to propose for serving a webpage.

Essentially just use an iFrame.

So you have your public link: gumroad.url this leads to a paywall which then sends you to an auto-generated one-time link of gumroad.paidurl. This url is a simple page that loads an iFrame with the real private URL.

So gumroad.paidurl and gumroad.url both go to a paywall when user 2 tries to access it. And either paidurl or url will be the one that's shared. Yes, people can circumvent it by looking at the source of the iFrame, but 95%+ of people won't bother, and it's a heck of a lot easier than downloading and displaying the page through AJAX or server side.

Clickable: https://gumroad.appspot.com/l/jxrvbk

Trying to sell the link to Gumroad for $100?! Stop trying to profit off of my work! :D

It's profit all the way down.

"But I make a profit of three and a quarter cents an egg by selling them for four and a quarter cents an egg to the people in Malta I buy them from for seven cents an egg.

Of course, I don't make the profit. The syndicate makes the profit. And everybody has a share."

-- Milo Minderbinder, Catch 22

Please let us know if someone pays for that :D

Missed opportunity here, if you had set it $1 I'm sure some of us would have paid just for the hell of it. I know I would. :)

Oh really? Well then you'll be pleased to know that I just released Gumroad Lite:

Clickable: http://gumroad.com/l/nbmeyt

Well worth it IMO.

Traceback (most recent call last):

  File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 634, in __call__
    handler.get(*groups)

  File "/base/data/home/apps/gumroad/1.349472656690944858/main.py", line 60, in get
    if is_logged_in():

  File "/base/data/home/apps/gumroad/1.349472656690944858/main.py", line 110, in is_logged_in
    s = sessions.Session()

  File "/base/data/home/apps/gumroad/1.349472656690944858/appengine_utilities/sessions.py", line 562, in __init__
    self.session = _AppEngineUtilities_Session.get_session(self)

  File "/base/data/home/apps/gumroad/1.349472656690944858/appengine_utilities/sessions.py", line 142, in get_session
    ds_session = db.get(str(session_key))

  File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/db/__init__.py", line 1422, in get
    keys, multiple = datastore.NormalizeAndTypeCheckKeys(keys)

  File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 180, in NormalizeAndTypeCheckKeys
    keys = [_GetCompleteKeyOrError(key) for key in keys]

  File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 2339, in _GetCompleteKeyOrError
    key = Key(arg)

  File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore_types.py", line 364, in __init__
    raise datastore_errors.BadKeyError('Invalid string key %s.' % encoded)

BadKeyError: Invalid string key agdndW1yb2FkciMLEhtfQXBwRW5naW5lVXRpbGl0aWVzX1Nlc3Npb24Y.

I got an error like that also when trying to log in.

Things you have to look at fast.

* Money laundering. Cap fees now.

* You are using Stripe, but you're still collecting CC data. Are you PCI compliant?

* Does Stripe allow you to do this? Really? Basically, you're acting as a third party processor, an IPSP. People can sell anything through your service (Think adult content)

I'm really interested if Stripe is aware of what you are doing and fine with it.

PCI compliance is only an issue if he's storing CC data.

I'm no expert, but I don't think this is true. I've witnessed a few payment systems being implemented, and just having this data pass through your system you need to adhere to some compliance rules (which are softer vs. actually storing the data though).

Correct. We are doing a PCI compliance certification right now, for a service that does the same CC flow as this. We don't store, but just forward. But even that requires a PCI certification.

That's not true. If CC data is passing through his system, their are things he needs to be aware of. You'd be surprised at the logs that are generated by people who don't store credit card information. Somehow, that unstored CC information winds up in a random logs directory, unencrypted and open for anyone to see.

True, but "storing" is very broadly defined. "Storing" CC data in logs or temporary folders is enough to fall under the purview of the PCI rules.

Coming from direct QSA experience, you can be liable for CC data if you are collecting, transmitting, or storing the data. Basically any touchpoint in the flow of CC data you're involved in holds you legally liable for PCI-DSS. Kind of like speeding on the freeway... doesn't really matter until you get nailed doing it, and PCI council fines are devastating. I'm glad to discount our product extensively for any bloggers here... https://www.secure128.com/trustwave-trustkeeper-pci-complian... Just drop me a line to say hello and I'll give you whatever price you feel reasonable.

Yes they're aware. Fees are already capped. I'm not collecting CC data.

That's cool. Far too many people ignore what a solid relationship with the upstream payment provider can give you.

Glad the fees are capped. I saw a $100 link, so not sure about what the cap is.

As for collecting CC data, if it's passing through your code, even if you don't store it, you are accountable for it. I've seen the silliest things with people claiming they aren't storing CC data. And yet, you can browse file after file of automatically generated logs that contain raw CC data.

That you aren't storing CC data makes your life easier. However, I'd still review what you are liable for just in case. I don't say any of this bash you (I really like the idea!), but so you avoid any problems that cause you to shut down (because it's a cool idea!). I've been doing this for 10 years now, and as soon as someone opens up a payment system like this, money laundering and other schemes will review how to abuse it. So when I see something like this, I get nervous. I ask: how would I exploit it.

> I've been doing this for 10 years now, and as soon as someone opens up a payment system like this, money laundering and other schemes will review how to abuse it. So when I see something like this, I get nervous. I ask: how would I exploit it.

Maybe you should write a guide of all the ways you've seen people go wrong and the best ways to do things (and why). That could be useful to a lot of people on HN.

I should. =)

I take what I know for granted too much, I think.

He could sell the guide on Gumroad

You have an XSS on the login form. I create a page which posts to the login page with the name

" onclick="alert('do evil here')" onfocus="alert('do evil here')" foo="

It errors out, and my javascript is now in the input box. They click the name and then it runs my javascript.

It's great you've escaped < and >, but you need to do more.

As with many ideas I see floated and mvp'd on HN, I'm jealous. Great idea, good execution. I'd agree with others that the 30% is too high. 5-10% would be acceptable.

I'm definitely seeing that. When I get that FAQ page up it'll definitely be much lower than 30%.

Why be jealous? He has no traction. Copy it and do it slightly better.

I have 50,000 page-views worth of traction and over 1,000 users - many of them making real money. :)

Kidding aside, I dare you (not sarcastically, I would love to see another approach to the same problem).

I may do that, but perhaps focused on a particular niche. Thanks.

Jealous of people being able to have good simple ideas, not specifically his particular implementation.

Seriously? I'm not sure I could take anyone seriously that tried to sell me a link of "value." Why not just share the link for free like people have been doing since the beginning of time?

Don't get me wrong. You did a great job getting this rolled out over a weekend and it looks nice. I must need some enlightening because I really don't get it.

I think there are some links that do have value. For example, if I wanted to release a new web app to my Twitter followers but wanted some sort of barrier (without having to set it all up myself) - I would use Gumroad.

If I had a bunch of files laying around my FTP that I never sold and would like to sell off for $5 a pop without the overhead of creating a store - I would use Gumroad.

Does that make it any better in your mind?

This makes more sense to me now and I see the potential. Perhaps you should put this example on your website to make it a little more clear.

I definitely will. Thanks for bearing with my crappy copy. It'll get better :)

Imagine you have a Fireworks iPhone mockup template.

Instead of setting up a store somewhere to list your ONE item, you put the template up on your website and link to it through gumroad.

Then, you give out the Gumroad link on Twitter: "Need a sweet Fireworks iPhone UI template? Buy it for a buck: gumroad.url"

Your twatting friends click it, give you a dollar, get redirected to your website. They download the template, you get a dollar - all in like 2 minutes while your oatmeal was cooking.

Good example. Makes more sense to me now. :)

And 2 minutes later the "secret" link is shared on Twitter.

Yeah, I'm not sure I understand that part either.

If this really is possible, you'd have to create a user who is somehow whitelisted to get the linked item in question.

I think people who use Gumroad won't really have that as a concern - but if enough people bring it up, I'll see what I can do about it!

For many of the things that people might want to do, a "patronage" model isn't so bad either: the creator demands $1000 for the work behind the link; people can leave an e-mail address and pay anything from $1 to the full remaining price, and will be notified as soon as the work is available.

I think this has tons of value, almost like a mini-kickstarter without the need to advertise for a kick for communities of people (forums, etc) who want new features or some kind of quick bit of work done.

Disable direct links and proxy the content, that way you can create unique URIs for every buyer. Then you can do all sorts of things like add a watermark on the content page containing the credit card number of the buyer or just add expiration time to the links. That'll limit sharing somewhat, although I don't think it's a huge problem.

have the asset be hosted on S3 with a signed url that expires quickly

Then you would need to do that for every customer individually as I understand the system.

That Makes sense. How then do I make sure that they don't just go to the actual url once they know it instead of going through the paywall url?

It's like a freemium model but there's a single price point that starts off as a premium and slowly shifts toward free over time. :D

More likely usage scenario: pornography. Niche pornography.

(Hmmm, you may need to give some thought to legal questions raised when you're suddenly making money by selling every possible type of pornography into every jurisdiction of the world.)

What's being sold isn't the "link" but ability to access what it points to - an image, a blog post, etc. I think it's a great idea with oodles of potential - a link-based mini-paywall :).

Why not act as a download middleman so the buyer gets a download now button, and the link to the originator is not shown?

Loving the simplicity of the idea. The simplicity is worth a higher cut (though maybe not 30% ;-)) and makes it a lot more attractive to use in small situations. One thing you need to beware of, though, is the filing requirements.. you might have to start issuing tons of 1099s and that process will cost you.

If this becomes a high traffic site, it could really help fight internet piracy. If I have a high demand, hard to find video, I'm far more likely to try to sell it than just give it away. And even if I can't because the site is closely watched by the actual copywriter holders, the idea that money can be made off any online property can give internet knowledge and assets the feeling of physical worth, to the degree that people may grow hesitant to just give away their video and music files. It also has potential to detract from the information free-for-all of the internet, as people may also grow hesitant to share in general, but that would only be for sellable things, so blogs and general information are basically out. If successful, this site could make major change in the attitude of the internet. In essence, conflict exists between copyright holding companies, who believe their intellectual property should be paid for, and the general population of the internet, who freely share information constantly. This conflict could seriously benefit from a general shift toward the resounding feeling that information and online assets are worth something and should be bought and sold. That could be of serious detriment to the culture of the internet, but the communities could also gradually adjust. After all, the feeling that assets have monetary value is the way we live in the real world, its only a matter of time before the internet starts to follow.

What do you plan on doing about fraud? Seems like it would be way too easy to move money around with stolen credit cards.

This. Some friends of mine ran a payment startup. However as soon as there is a money->thing->money option, you get a LOT of fraud, as they found out.

I haven't planned on anything yet. I'll take it as it comes, I guess.

He's not doing the payment processing, Stripe is.

In the world of payments, that doesn't really matter at all. Payment processors can't afford to have high fraud % customers, so if fraud becomes a problem they'll just drop him.

How does this work for art though? I mean you want to see the icon/graphic/design/whatever before you pay for it.

Also - once you've been redirected to the page, what's to stop you taking the link and sharing it yourself?

Also also: if I've got something to sell, can't I just bung it on ebay?

I'd like to think that this has lower overhead than eBay. Nothing is there to stop you for now - I think this is more for casual use than building an entire business on top of. Yes, I'm thinking about adding in a preview option with cluttering up the experience.

Thought of this too, I guess you can watermark images.

Not sure how you would sell JS scripts since showing a working demo would require the file to be accessible to the user.

That script you make is copyrighted, if they take it without paying you for it (if that is the deal), then they just broke the law.

Sure, but the question is how to make it more difficult.

graphics can be watermarked or provided low-res for review.

Come on, if you want to see the icon/graphic/design/whatever before you pay for it obviously the seller can show you a smaller/low-res/watermarked/whatevered version.

The second question has been answered.

This is a completely different model than ebay.

These are really bad questions. I'm not putting you down - its no big deal, but just a little critical thought should answer these for you.

Cheers,

> If you want to see the icon/graphic/design/whatever before you pay for it obviously...

But that's the whole point. There's nothing that allows a seller to do this at the mo.

> The second question has been answered.

Sure, after my post. The answer to which seems to be "there isn't". So a valid question.

> This is a completely different model to ebay.

Perhaps from the platform's perspective, not from the sellers. The motivation is to enable someone to quickly put up an item for sale. I can pretty damn quickly put up a single item for sale on ebay too.

> Perhaps from the platform's perspective, not from the sellers. The motivation is to enable someone to quickly put up an item for sale. I can pretty damn quickly put up a single item for sale on ebay too.

You are completely wrong. The model is entirely different from the seller's perspective. See the author's original comment. I've included it below.

>How does this work for art though? I mean you want to see the icon/graphic/design/whatever before you pay for it. This is also answered by the original comment.

"There have been many times in the past where I wanted to share a link - on Twitter or just through IM with a few friends - but did not want to go through the overhead of setting up a whole store."

The seller will be sharing a link with a person who they have a seller/buyer relationship with. The product in question is the last step in a process that the seller has complete control over.

No more of this. Cheers,

> "There have been many times in the past where I wanted to share a link - on Twitter or just through IM with a few friends - but did not want to go through the overhead of setting up a whole store."

Right - and putting something up for sale on ebay and sending people the link is different... how?

This looks like a really expensive way to get Rick Roll'd :)

Yes, how do you deal with the (hundreds, thousands, millions) of annoyed customers per day who were promised one thing but wound up paying for another?

This can't be a minor problem, either. At any given time the percentage of your users who are being ripped off by some nasty scam will be between 10% and 90%. You'll have to be very careful about policing things, otherwise the first mention of your business in the media will be "gumroad enables porn bait-and-switch scammers".

Please put a video on the homepage. If I'm on the fence, I'd rather watch a video than create an account.

can I quote you?

If the payment fails, will you still redirect to the link?

If you only redirected based on successful payments, you could use this as a simpler paypal for charging clients on your site using unique gumroaded links.

You only get redirected if your payment goes through. Yes, that is a potential use-case.

Is the redirect-link unique in any way? I mean.

If anyone buys the access to a a non-unique-link (ie: http://mybook.com/book.pdf), and then shares the redirected URL to a third person, this third person could load the link without paying, right?

Yup. For now, there is no security built into the link once you get through that payment wall. I'm thinking about how to do that without hurting UX - though it's low on the priority list anyways.

If you potentially host the files/keep track of static/unique URLs on your site, you could keep track of who is the first owner to ensure that no future users also claim to be the owner and resend the file/link as their own.

This doesn't take into account all cases but a good chunk to start with.

I get a broken lock icon, and "Connection partially encrypted" message. You need to make sure all externally linked resources on the page use SSL. Specifically: change http://fonts.googleapis.com/css?family=Cabin:regular,bold to https://...

Thanks for the notice, I'll do that.

The copy on the re-direct page is bothering me a bit. Anyone else?

You're being shared Gumroad!

With the "You're being shared". Sounds confusing.

"You got Gumroaded!" Wait, no. That sounds wrong for some reason.

Interesting concept -- how do you deal with the legalities?

If I buy something am I buying it from you or from the original owner?

How long do you hold onto the funds to deal with any potential chargebacks?

This may just be the simplest way to sell digital goods.

I think all content should be uploaded to your servers otherwise if someone gets to the final link they can just send others to it.

I like the simplicity of the home page, but I would want to see what a user would see when supplied with a gumroad'd link before singing up.

Agreed. Added that to the to-do list.

I'm already giving this away for free with a PayPal donate link at http://pickdropapp.com/ but what the hell: http://gumroad.com/l/cvhhwi

Are you collecting taxes? if it's a company registered in the US

Also how do you deal with chargebacks?

Traceback (most recent call last): File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 634, in __call__ handler.get(*groups) File "/base/data/home/apps/gumroad/1.349472656690944858/main.py", line 60, in get if is_logged_in(): File "/base/data/home/apps/gumroad/1.349472656690944858/main.py", line 110, in is_logged_in s = sessions.Session() File "/base/data/home/apps/gumroad/1.349472656690944858/appengine_utilities/sessions.py", line 562, in __init__ self.session = _AppEngineUtilities_Session.get_session(self) File "/base/data/home/apps/gumroad/1.349472656690944858/appengine_utilities/sessions.py", line 142, in get_session ds_session = db.get(str(session_key)) File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/db/__init__.py", line 1422, in get keys, multiple = datastore.NormalizeAndTypeCheckKeys(keys) File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 180, in NormalizeAndTypeCheckKeys keys = [_GetCompleteKeyOrError(key) for key in keys] File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 2339, in _GetCompleteKeyOrError key = Key(arg) File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore_types.py", line 364, in __init__ raise datastore_errors.BadKeyError('Invalid string key %s.' % encoded) BadKeyError: Invalid string key agdndW1yb2FkciMLEhtfQXBwRW5naW5lVXRpbGl0aWVzX1Nlc3Npb24Y.

Am I missing something or could you just employ a download method rather than link? Maybe something like how istockphoto does it. Although the link leads to a purchase terminal, if they make the purchase it would prompt a download rather than a link they could share.

Also link shorteners + asking for credit card information immediately can get iffy in terms of trust and fraud. I understand that it is an mvp though. Later you might be able to employ a buy credits system like istockphoto does.

I really like you color pallette. How did you come up with it?

I took it from Colorlovers. Here's a link: http://www.colourlovers.com/palette/1473/Ocean_Five

Traceback (most recent call last): File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 636, in __call__ handler.post(*groups) File "/base/data/home/apps/gumroad/1.349498677539326613/main.py", line 292, in post db.delete(link) File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/db/__init__.py", line 1491, in delete datastore.Delete(keys, config=config) File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 516, in Delete keys, multiple = NormalizeAndTypeCheckKeys(keys) File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 178, in NormalizeAndTypeCheckKeys keys, multiple = NormalizeAndTypeCheck(keys, (basestring, Entity, Key)) File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 157, in NormalizeAndTypeCheck (types, val, typename(val))) BadArgumentError: Expected one of (<type 'basestring'>, <class 'google.appengine.api.datastore.Entity'>, <class 'google.appengine.api.datastore_types.Key'>); received None (a NoneType).

Seems good.

How long until exact clones appear? What makes GumRoad the micro-paywall of choice?

How long until shortened<-->lengthened websites appear which reduces how many people pay up?

You can tell clients to check the http referrer for your domain. That would (mostly) stop people from posting now-useless destination URLs online.

http referrers are easily spoofed, of course, but it'll be enough to prevent most people from sharing secret urls on twitter. You could also pivot and allow people to upload files to your own server, but that's a different story.

That would hurt the UX. For example if someone gets the link to a blog-post-in-the-making they shouldn't have to go through Gumroad to access it every time.

Not bad to have the option, though.

Brilliant little idea, I think the big selling point is speed and ease of use. I might create a similar product to this for BitBuffet.com (a similar file selling service I created), as I think the process can be further streamlined.

Digital sale processes still need streamlining for everyday users (especially one-off users) and I can see a service like this taking off.

I'd work on the name. Gumroad? What does it mean?

To me it brings up an image of a road, covered with gum. I'm trying to get where I want to go, but there's all this gum on the road slowing me down. It's a huge and annoying obstacle. And that is a bad mental image, given that what you're selling is a sort of obstacle.

It's not too late for a different name.

Huh...I guess that makes more sense, but actually my first impression of the name was to think of Candyland. Like the Yellow Brick Road, but with gumdrops and such. Cheesy, but positive. I wonder which interpretation is more common?

Nice product!

Feature request: use the top half of the screen to show a preview of the linked page rendered as a PNG. Use the other half of the screen for soliciting payment. I want to know what I would get with the payment. How much of the target page is shown should of course be configurable by the page owner.

First off, I like the idea, but there are some noticeable flaws, many which have been brought up.

One interesting one for me, which is more an oversight, is that anyone can make money off of the sale of a link. There is no way to validate that the person posting the link, is the owner of the content. So someone could sell links to a page on HN, Reddit, Techcrunch, etc. at no expense to them.

If this did occur, I think it would cause a quite negative view of Gumroad links, as being scammy. In which case, people would begin to avoid them, reducing their effectiveness as a possible sales medium. Without oversight, as to who is selling a link, this might end up smothering itself out.

While providing an authority model is often a great business, it's a fallacy to say that provenance is mandatory to be taken seriously. See: Twitter, eBay, 4chan, TechCrunch

http://please.bitcoin.me/now/

I saw it mentioned here already, but the idea of a "Name your Price" option would be really cool. Just like how Bandcamp does it. I'm always more motivated to support artists that chose this option.

What are your fees? Didn't see that anywhere on the homepage.

Honestly, I'm not sure - hence them not being listed - but I think I'm going to go with 30%. And then for people making >$x a month dropping that in tiers. Thoughts?

30% kinda provokes sticker shock.

What if you went with max (5%, 0.01/MB)? 30% of 0 is still 0, after all.

30% commission is for when you are selling people's stuff for them. Unless you have a huge audience who can't wait to buy random stuff on the internet (like Apple does), 30% is outrageous. If Paypal started charging 30% commissions on money transfers people would drop it like a hot potato.

My recommendation is to establish the %age markup based on file sizes, since that would be the basis for infrastructure costs such as storage and bandwidth.

30% is definitely high. I understand 30% has become a buzzword these days, but in reality it cuts a lot into merchants' margins. You may want to research on current digital goods market sites such as e-junkie, payloadz etc. Most seem to have a combination of monthly pricing and a "low" per transaction fee. Monthly fee certainly going to be a barrier for casual merchants.

All he is serving is a redirect page. He's not offering a hosting package or anything like that. Charging per file size doesn't really make sense.

At 30%, unless my product is pure profit I'm going to look elsewhere. A Paypal (or WePay!) buy now button isn't that hard to create after all...

Yeah - I'd rather try my luck at Kickstarter and pay their 5% fee and PayPal's 2.7%.

You'd have to write up some very specific usage scenarios that make that cut viable.

Apple's cut makes sense so far that you get some tangible advantages in terms of such things as exposure. You'll have to explain people what they get for the 30% cut.

Right now, I'm unconvinced that you get 30%'s worth. But, on another note, it's probably always better to start at a high price and dial it down than to launch a product and increase the prices over time. People will be crying bait and switch - justifiably.

Or eJunkie - it lacks the (apparent) simplicity for but for $5 a month you can make an unlimited number of sales for up to 10 digital items and then you've got PayPal/processor fees on top of that.

PayPal's micropayments pricing is 5 cents plus 5% per transaction so this combination can be a big money saver.

We created a service for a niche market that was mostly using eJunkie at the time (lowest cost, word of mouth travels fast among groups of sellers) and we had to compete with them on price and features.

Thought about it. How does this sound? "i think 30% below $10/month in sales, then 25% below $50, 20% below $100, 15% below $1000, 10% above $1000"

That sounds like highway robbery.

great idea, but if your site is getting traction, you'll have to face tons of imitators -- after all, you already said that this is a weekend project. They are going to undercut you like crazy if you are doing 30%. So might as well make it as enticing as possible, maybe just 3% overhead (or even 1%).

I've been thinking about this exact problem for a few weeks now. I have gone as far as buying a domain for it (epayfiles.com) and I just started coding. I think I'll continue on with my project I'll just focus on a different payment niche.

After doing some quick research I found five or six sites with similar ideas. Most of them focus on selling digital files not links. The link idea sounds novel. The presentation is also very clean. Looks good.

There's some potential for gamification here. Here's a Gumroad URL which, when paid for, unlocks some kind of challenge that you must solve in order to find a new Gumroad URL. Which unlocks another challenge that leads to another Gumroad URL, continuing for n steps until you unlock the final reward. Each step costs less than a dollar.

How would this have played out if eg. Dropbox had run their challenge on top of Gumroad?

Is this what you've been working on in SF, Sahil :) ?

At least for the past two days, yup. Just a small part of the rest of my life though!

Seems cool. I wish you'd render the about text box for products with Markdown or something though so the links were clickable.

I already dislike URL shorteners, there's no way I'm going to give my credit card info to one.

If the value is zero the user is being redirected to home, after accessing the link url.

I like it, there's a lot of functionality missing, as you said but tons of possibilities.

I'd like to see a "pay as much as you'd like" feature, where you can set a minimum amount (like radiohead and girl talk do) but still allow them to pay more.

Why wouldn't stripe just implement this themselves? Since their payment processing service (and API?) is 99% of the project, seems like they'd make their own and cut you off if this gained any traction.

It's not 99% of the project, it's one line of code (among over 2,000).

One? That sounds like a rather awesome API, unless you just redirect to a payment processing system over on their site. Mind sharing the one line of code? :)

This is my daily fail: http://potomak.tumblr.com/post/4361901296/developer-business...

Developer ≠ Businessman

I think it's a great idea, and really well implemented so far.

Best of luck with it!

Just a caution, if you are taking in money via paypal and then paying out via paypal, paypal will probably shut you down within a month. They don't like competition.

i love the idea, i hate the new "We have a tiered system for pricing:" basically it says: if you earn less, we will take even more. so basically if - lets say - earn 2 dollars (casual user who sold a psd template for 1$) this service now takes 2$ - 230c = 1.40$ - (1.40$ 0.3) = 98c

this tool should encourage casual use and it makes a perfectly simple product complicated.

please overthink your pricing-strategy. make it as simple as possible, iterate from there.

I saw this post the other day, then came across Pulley. Is there a difference? http://pulleyapp.com/

sahillavingia, your personal site looks awesome too! http://sahillavingia.com/

How do I know that, when I pay, I am actually getting what I am paying for? How do you handle chargebacks etc..

Really neat way to sell vulnerabilities.

Great idea. Your email address matching is case sensitive, you might want to fix that.

Well done this is brilliant.

please tell us when the first (real) vc are knocking on your door ... this is just awesome and has more potential then the most startups covered by techcrunch and co

Nice - how about this as a feature: # of downloads allowed. This would allow people to sell just 1 copy or set up something like a groupon-esque clone. First 50 people get 50% off. Then after 50 people say you're too late. Just an idea.

I really like this idea, especially for art. It solves the "what if someone just passes the final link around" problem because if you're getting 1 of 25 copies of something you're less likely to go out of your way to reduce the rarity of the item you bought.

Expanding on that if there is a limited # you could choose to list # left to create a sense of urgency or keep it hidden and mysterious. Good luck!

So it's funny that this happens today: http://news.ycombinator.com/item?id=2407969

There is no way to stop re-selling of the content once somebody has bought it short of implementing some horrendous DRM system.

Reply on news.ycombinator.com