

What can we do better? YCW12 Reject: Droptype - alexcabrera

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.<p>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<p>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.<p>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).<p>There's a few things we know we need to do and are working on them:<p>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.<p>2. Domain name redirection<p>3. RSS<p>4. Publishing a directory should publish all content already in there<p>5. Better navigation once you're reading a file<p>6. Integrate with Facebook, Twitter, etc to autopost to different services.<p>7. Syncing of other types of media - images, video, audio<p>We also have a few pretty solid monetization ideas, but I rather not get into those right now.<p>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.
======
gregschlom
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.

~~~
alexcabrera
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.

------
pw
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.

~~~
alexcabrera
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.

------
fbuilesv
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 :)

~~~
alexcabrera
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.

------
stuntgoat
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.

~~~
alexcabrera
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?

~~~
stuntgoat
What about publishers of non-text?

\- images

\- datasets ( think scientists )

\- music/video

~~~
alexcabrera
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.

------
sebg
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?

~~~
alexcabrera
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.

~~~
sebg
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?

~~~
alexcabrera
Will do, thank you very much.

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

And "simple publishing" is enough with the bold.

