What can we do better? YCW12 Reject: Droptype

10 points by alexcabrera ↗ HN
We received our rejection letter to YCW12 after our biggest day in terms of traffic and positive feedback; so we figured it might be time to turn to HN for some honest feedback and some ideas on what we can do to improve our app.

The basic premise is pretty simple: Write in plain text, format with Markdown, put in your Dropbox, automagically publish on the web. That much works right now, you can (please do) sign up using your existing Dropbox account and play around with it: http://droptype.com

You can also create sub-directories and it will sync those as well. Every file or directory you add has a publish button you have to hit before it goes public.

We also support a couple MultiMarkdown metadata attributes (Title and Summary), and you can drop a readme.txt file in any directory and it will show up when you visit that directory on Droptype (we install a readme.txt for you to show you how the app works).

There's a few things we know we need to do and are working on them:

1. Themes - I'd like to see this working like Jeckyll or Hyde where you can configure the look of the site by putting files in each directory. We'd obviously need to have a few prebuilt themes.

2. Domain name redirection

3. RSS

4. Publishing a directory should publish all content already in there

5. Better navigation once you're reading a file

6. Integrate with Facebook, Twitter, etc to autopost to different services.

7. Syncing of other types of media - images, video, audio

We also have a few pretty solid monetization ideas, but I rather not get into those right now.

I guess the question is what can we do to make the service more compelling. It seems people that get it think it's a pretty good idea, but we're not getting as much people creating content as we'd like.

15 comments

[ 3.5 ms ] story [ 50.1 ms ] thread
A question I would have is what problem are you trying to solve? From a quick though it would seem to be solving the same problem tumblr / posterous is solving?
We're trying to build a platform that's more geared to long-form writers instead of people mainly aggregating content created by others. Services like Tumblr, Posterous, and Wordpress are focused more on real-time, constant updates. We're looking to build something for writers, not the blogging set.

Our monetization strategy is focused on providing writers with the tools for selling their content and then building a solid reading experience on top of that content.

Hey Alex - alright can see where you are coming from. Venkatesh Rao (from Ribbonfarm) writes ridiculously long posts on Wordpress. Maybe you can reach out to him to see if your product would interest him?
Find a specific genre of publishers to target as your primary users. Talk with them and solve their problems. You will make your service more compelling to those users by solving their biggest problems and building the ideal product for them.
We're hoping to target technical writers from the onset as they'll be the ones most comfortable with plain text and formatting using Markdown. Hopefully we can then leverage that momentum to bring in other writers.

Any other genres you can think of that might be a good fit?

What about publishers of non-text?

- images

- datasets ( think scientists )

- music/video

The datasets is a really interesting concept. Maybe SQLite database support? It would need to be some sort of single file database. Then you just need to figure out how to run queries on that data.

We want to do syncing of images, video, and audio. It would be nice to be able to construct a well designed page by dropping assets (text files, images, other media) into a directory in Dropbox and having Droptype automagically arrange those items.

I think your service is, to paraphrase Job's words about Dropbox, "more a feature than a product".

It's probably great and very useful to many people, but I'm not sure that you could generate large revenues from it, and it looks like something Dropbox could easily re-implement.

My opinion: the problem here is not so much about the publishing platform but how you drive traffic. After one of the articles from my blog hit HN's frontpage and got 10k visit, I could feel the magic of it.

Publishing stuff on the web is easy. The question is how you make people read it.

Couldn't agree with you more. Right now we just built a feature that we see as core to the product. In terms of what we want to offer writers, it's:

1. Control over their own content. That's why we liked the idea of building on Dropbox and using plain text. No lock in, everything you write is always on your machine.

2. We've worked out revenue numbers, and if we can provide a simple way to publish and consume ebooks that takes up a tenth of one percent of the market not currently owned by Amazon, Apple, and BN; well, that's more money than I could ever spend.

3. Dropbox can definitely do it; but I don't see how it's in their interest. I'd imagine their newly launched API was developed in hopes of having people like us build things on their platform. They've build a great hard drive in the sky, I don't think that people should fear to build on that any more than people should have feared building on top of traditional hardware.

From what we discussed, publishing on the web isn't easy if you're a writer who doesn't have an interest in blogging. We don't want to for people away from the tools available on their computer that they're comfortable with and we don't want you to have to know how to set up a web site (Wordpress, while great, is a PITA to set up for non-technical users).

We're hoping by providing ways for authors to broadcast their content and the tools to analyze traffic, they'll be able to bring their own readers in. Once we have some people writing, we can better enable discovery of new content.

I just tried it. It's like using a static site generator that deploys as seamlessly as Dropbox syncs. That's nice. That's something I might actually use. But, as I'm sure you've already considered, there's no market for a Dropbox-enabled static site generator. :-(

As for the audience you are targeting, "serious writers who want to focus on writing without the hassle of running a website", I see a couple of problems.

First, it doesn't seem like long-form writers have a problem with any of the current Internet publishing platforms. There are some conventional length restrictions for online content that grew out of the length (and style) of reading that's comfortable to do while sitting at a desk. Adapting those conventions to the era of tablets is indeed a problem, and one that's being addressed by things such as iPad magazine apps, Kindle subscriptions and Instapaper. But that seems to be a different problem than the one you're positing.

Second, and more importantly, anyone who is concerned about the "hassle of running a website" won't understand Markdown (or even know what plain text is, for that matter). The concept of a markup language is a hard one for non-technical people to grasp. There's a reason WYSIWYG editors, for all their problems, are ubiquitous.

Thanks for your input. I'm glad to hear you find it useful.

Our hope is that by having a pretty flexible data storage format (plain text), we can concern ourselves with laying out the content in an optimized manner for any device that might like to access it. By eventually outputting to ePub, responsive HTML/CSS, KF8, we hope to allow writers to write once and let us handle putting it in formats that would make it available everywhere.

Also, 100% agree with you on authors not understanding plain-text and Markdown. These are at the forefront right now because the product is rough enough where the only people that will get it are people that understand these things. To build something your average writer will want to use, we're going to need to provide a soup to nuts experience, but one that respects the content creator and keeps them in control of their content.

A couple of questions/comments:

1) Something we've heard a lot from PG: Is this your biggest problem?

2) What prevents random Hacker McHack from reproducing your company in a couple of weeks and releasing it as open source?

3) You don't want to mention your monetization plans, but are you sure the income from something like this can support a company? I can see why people goes for companies like Tumblr/Posterous (huge, huge, huge audience), but your service by comparison looks like something too "nichey" (not bad, but again, not the scale YC is looking for).

I'm sorry if I sound blunt, but as it stands right now, compare this to Heroku, Justin.tv or Greplin and tell me again if this is something you think fits their idea of a good startup.

Without reading your application it's hard to see what plans you have for this, maybe I'm just blinded by what's only in this post. Your ebooks idea sounds like it could be _super_ interesting.

I hope this feedback helps you :)

Edit: As a geek, I'd love to use this once you support custom themes :)

First, let me say I really appreciate the feedback. This really started as us trying to scratch an itch we've been having for a long time. We've always been of the opinion that plain text is how people should write, and so this is an attempt to make that a bit more accessible. Clearly we have a lot of work to do.

On to your questions:

1. Like I said, delivery of prettified plain text was a problem we were having. The process of going from Markdown'ed text to something you can send to, say, a client, is a complete PITA (read: I want to punch LaTeX in the face). On a macro scale, it's still way too hard for people who are good writers to focus on writing when there's all this other stuff they need to do to just get their words out there (find a publisher, set up their own site, etc).

2. Absolutely nothing, but that's true of just about anything. We built the app in a matter of weeks and I suppose someone could release an open source version. If some intrepid writer is able to set up their own server, install the software, and configure everything themselves, well they're not really our target market anyways. There's not a lot of magic here; you can probably figure out the basics of how this works fairly easily. By that logic, why use Dropbox if SparkleShare is like right there.

3. The sale of content and additional features for people that take the service seriously will be our main revenue drivers. We're taking the eBook thing very seriously and are imagining a marketplace where you could buy access to content and have it available, in different formats, on all your devices. The content on your Dropbox will be considered the canonical source; we simply would create optimized experiences and provide the transactional marketplace on top of that. We've run the numbers and even if we capture a statistically insignificant marketshare, we're living a pretty good life doing interesting work. You might be absolutely right, that's probably not the scale YC was looking for.

I appreciate the bluntness and the time you took to put together your thoughts. They are incredibly appreciated. We're actively working on development and want to make sure things like themes are properly implemented in a way that is a.) flexible for our future plans and b.) geek friendly.

Again, thanks a bunch. We're just trying to build something cool and your thoughts are very welcome.

Landing page: "serious" isn't adding anything to "writers."

And "simple publishing" is enough with the bold.