Ask HN: Is relying on scribd's API a big mistake? | Hacker News Reader

Ask HN: Is relying on scribd's API a big mistake?

2 pointsedb6 comments

I have a web application I'm working on that essentially shares documents within a small niche community. Scribd has done alot of the hard work as far as managing documents go, their iPaper allows me not to worry about storing documents, making them easily readable, etc.. Most of the heavy lifting is done by them.

HOWEVER, I am now building a web service that depends on scribd.com for full functionality. If scribd goes down, I go down. If the documents on scribd no longer become available, my service fails. I've already discussed the implications of copyright for my service with the scribd guys and that's not a concern of mine.

I've been told that scribd has enough momentum to not have to worry about it, but adding that extra coupling still makes me wary. It will save me LOTS of time and effort though and my release date will be MUCH earlier and alot more flashy and stable. I've decided to go forward with scribd.

Am I making a mistake here? I'd like to hear what you guys have to say.

I'd figure out how to backup the scribd documents so that your users' data won't get completely lost if and when scribd disappears. You want to make it possible to recover from the loss of scribd, even if it's inconvenient.

Most likely the right answer is to launch now and work around scribd later. If your community completely fails to catch on, then you needn't waste time cloning scribd. If scribd gets you through a year, after which someone else has cloned scribd, you get to leverage their work. If you're really lucky, that work will be open source.

If nothing else, having your community up will allow it to grow and get stuff done while you are busy building an emergency failover system for scribd.

Of course, if your community will lose $1m for every minute that scribd is down, you should consider paying someone to build your own version of scribd. Indeed, you should probably consider buying scribd, or at least their source code.

I'm in agreement. It seems like having the user upload to your server/hardware, store the original and pipe it into the Scribd API. It'll afford you the opportunity to move away from Scribd bit by bit. In fact, if Scribd goes down, you can revert to say a PDF of the original document. It won't have the bells and whistles, but the info is there...

Thanks for the good reply. I guess it makes sense that I use scribd to get my community going, and if it takes off, use those resources to wean my dependency.

You already called out the problem: you can only be up as often as all of your critical partners are up.

If you care about uptime and reliability, you can only partner with well established, reliable players for core functionality. For example, Google Maps is a pretty safe partner.

Also, what would you do if they went away? I'd make sure you have your own copies of every document, just in case.

Now, in all fairness, scribd has been up whenever I've used it and seems to be continuing to gain traction.

If scribd went out of business tomorrow, how long would it take for you to get a solution working? How much would it cost?

No, I don't think you're making a mistake, but this is a high risk decision. Personally I would at the very least look into using one of scribd's competitors as an emergency solution in case of major downtime, bankruptcy, etc.

The likelihood of scribd suddenly disappearing seems small, whereas the value of speed in developing new services is large. So seems like a good bet.

Reply on news.ycombinator.com