
Fred Wilson's 10 Golden Principles for Successful Web Apps - roblewis
http://www.techvibes.com/blog/fred-wilsons-ten-golden-principles-for-successful-web-apps
======
david_shaw
Interesting article about principles for _designing_ a successful web app...
if you're the only user. There are _zero_ references to security mentioned at
all. As a security engineer, this bothers me a little bit.

A lot of people don't understand that security holes in their applications
aren't usually caused by a 0day in their framework, but instead _sloppy
security practices_ in the application itself. I break web applications for a
living, and although I appreciate the consistent business, entrepreneurs and
developers on Hacker News should understand that a critical hole will cripple
their business.

Take some time before you let other people use your app (other than internal
testing) and do a few simple checks:

\- Am I sanitizing user-supplied input in my application? Can I throw a ' in a
userid form, or will it break my SQL statements?

\- If I put ''";<xss> in the search bar, and view source, are > and < symbols
floating around the page?

\- Am I relying on security through obscurity? This is a big one. "Oh, no one
will find the hardcoded password in this world-readable configuration file six
directories deep" is how infrasctructures get destroyed.

\- Am I handling credit card data myself? Do I need to be PCI-DSS compliant?

These few questions will prevent 90% of XSS, SQL injection and CSRF attacks if
you carry them out thoroughly. Don't realease a buggy webapp just to get
hacked.

~~~
brlewis
He's defining success in terms of potential popularity. I think security is
important, but empirically, security seems irrelevant to most apps'
popularity. Many apps have stayed popular after major security breaches.

~~~
david_shaw
I completely agree, and just wanted to reply to touch on this point a little
bit.

You are correct that the article (rightfully) provides a forumula to create a
popular app. Sure, there are lots of technical details that weren't touched
upon in this article, and certainly we are not going to enumerate each of them
and criticize the author for not creating an end-all be-all make-the-best-app-
ever article.

However, I do believe that security should be a primary concern from the very
start. Think about security early, think about security often. Once your app
is already popular with 500k active users is _not a good time_ to realize your
oversight in security, leading to a possibly fatal breach.

~~~
alain94040
While my _brain_ agrees with your position, my _heart_ tells me that it's more
likely that you never make it to 500K users if you focus on security.

I'd welcome a counter-example: can you name a succesful startup that died
because of lack of early security?

The way it seems to work today on the Web is succeed first, get the money,
then fix whatever needs to be fixed.

~~~
david_shaw
I don't mean to criticize the article posted, and welcome many of the points
myself. I am coming more from a software development perspective, although I
understand that the article is geared primarily from a marketing point of
view.

I agree with you that being paranoid about security instead of working on a
human-friendly interface, or worse--a functioning product--will absolutely
hinder developments to grow, but that is not what I'm suggesting. In my
experience, the vast majority of crippling bugs are _simple_ things, that can
easily be prevented using methods such as the four I listed. These should be
part of everyday secure coding practices.

I would never tell a developer that they should stop working on their product
to tinker with obscure security fantasies, but I'd also say that they're crazy
if they don't include basic checks (such as ensuring on a basic level that
user input is clean) as mentioned above.

Development methodologies like TDD include this inherently in the software
life cycle: tests reaching outer bounds and unexpected input are regularly
created to make sure that errors are handled correctly.

------
dmix
Why is REST relevant to a web apps success?

In the comments he mentions "it makes the app shareable on blogs, email,
social media if every resource/page has its own URL". That's true, unless of
course when 75% of your URLs are behind authentication, which is true with
every paid app.

So the connection between sharing and REST doesn't make much sense.

Why not just say: make it easy to share? Or provide clean URLs for APIs?

~~~
rokhayakebe
I think all he meant by REST was "Have an read/write api"

~~~
auxbuss
I agree. Eat your own dog food. Use your own API. If you aren't doing that, in
most spaces, then there's more friction to scaling.

Course technically it doesn't _have_ to be REST, but that's the buzz of the
now.

~~~
mahmud
But do it right.

People who have never used a diversity of web APIs (>= 20) should never be
allowed to design them, or I will personally fly to their dungeons and
strangle them with their own lousy documentation strings.

Test your "API" with a variety of languages, that are not C++ clones. If you
can respond with a header value, don't make me parse a body (i.e. responding
with 200 when the body says "error".) Accept whitespace liberally. Space
should mean \\\s+. Not just a particular " ".

Version your API. Don't obsolete stuff willy nilly. Even if you're clueless,
it's not too hard to run three instances of the endpoint app, and route
requests to a per-version instance with URL rewriting proxy.

Anybody who has ever sat in the specification committee of a "microformat"
should never EVER be allowed near APIs that others might use. Specification-
creep is real; one draft spec by 3-guys in their dorm room creeping into
another spec by some other guys. I can cope with IETF and W3C pulling stuff
out of thin air, but I will NOT tolerate being told to read several
draft-0.01a.txt specs from 2003, for a myriad of "social identity" crap that
no one, but those whose name appears on the first page, cares about.

Also, offer a sandbox, and dummy instances with mock data. Otherwise I will
rape your live servers in a tight, unrolled loop (Srsly, I am on a fat pipe,
running native x64 code; your instance of Jetty or WEBrick will never know
what hit it.)

Can you tell I have been debugging?

~~~
msbarnett
I agree with all of the above.

And also, for the love of all that is holy, when you offer a sandbox and test
data, give me a way to deliberately trigger error responses.

It's all well and good to give me an is_test parameter on your payment API,
but if using it causes you to blindly approve all payments, I can't test all
of the code paths dealing with all of the possible failure modes(true story).

------
ludistan
Carsonified team actually put up the original video of Fred's talk from FOWA
2010 Miami, with the same points: [http://thinkvitamin.com/web-apps/fred-
wilsons-10-golden-prin...](http://thinkvitamin.com/web-apps/fred-
wilsons-10-golden-principles-of-successful-web-apps/)

~~~
jmulho
Thanks. The talk itself is way better than the summary.

------
darwinGod
I think a lot of points mentioned/not mentioned in this article are
debatable...Security,Features,Target audience... But this article by Evan
Williams is almost timeless( written in 2005, Pre Zynga, pre Facebook)
<http://evhead.com/2005/11/ten-rules-for-web-startups.asp>

------
limist
This seems to be the same talk given back in March 2010 and discussed on HN
here: <http://news.ycombinator.com/item?id=1140596>

Regardless, useful points worth keeping in mind.

~~~
stcredzero
Looking at this list again it makes me think that HN is not in the category of
web sites Fred is talking about. It's obviously successful, but it doesn't
follow a lot of these recommendations.

------
lyal
Great post.

