dhouston

you're thinking of robert kiyosaki (also from hawaii, however :P)

(fwiw, i thought rich dad poor dad was fairly interesting -- i'm not going to hate on it as much as others might -- although it's alleged that some of both some of his anecdotes and financial success were exaggerated or false. see http://en.wikipedia.org/wiki/Robert_Kiyosaki ; google will turn up other criticisms.)

yeah, the intro/failed kumbaya was excruciating. but the rest (ok, i only watched about a third of it) was well delivered, and pretty damn compelling.

btw, cough, someone needs a <meta content="text/html; charset=UTF-8" http-equiv="content-type" /> (or equivalent) in their <head> section :)

you lost me with that last paragraph, to put it nicely.

your innovation as a startup will not be reinventing wheels -- building and debugging frameworks that, fortunately for you, others have put [tens of? hundreds of?] thousands of man hours into, solving seriously unsexy problems like browser incompatibilities, security nits and writing init scripts. i can't see how it's faster to tackle all of these things _and_ your application code than just, um, building your application code leveraging one of the very solid foundations that already exist.

while your competitors are solving problems that matter to your users, you'll be running around feverishly putting out fires when someone types an é into your application, or starts getting funny with strings involving apostrophes, semicolons and "drop table", or script tags in comments.

looks like web.py has some interesting ideas and useful data munging functions. but unless there's something i'm really missing, most normal web apps (that aren't completely trivial) are way better off using turbogears or django, which provide mature and usable components (templating, object-relational mapper/query building/db access, web/WSGI server). i've built a couple reasonably large web apps using turbogears and love it (although i use cheetah instead of kid) and django seems to be winning the python framework race.

not to sound overly harsh, but web.py seems like a big case of NIH. each of its pieces seem like v0.1s of more established counterparts. mature web frameworks are occasionally big and ugly _because_ they work around that random safari bug from 2002 or the flash 8 player's uploader non-RFC-compliant MIME-multipart requests and all the unicode encoding and DB integration nits, etc. the plumbing looks gross because the surface area of the problem they solve is gross.

and with the big frameworks, thankfully hordes of others have banged their heads against and solved these issues; with a "lighter" framework, or one of the 4328429 me-too python web frameworks from 2001-2004 that didn't really make the cut, you're volunteering to blunder into and track down all these problems yourself over the next year or two -- probably not the best use of your time or problem solving skills.

it depends on where your bottlenecks are. if you're serving static content (e.g. an image hosting or photo sharing service), amazon S3 is a cheap and simple way to do so. if you have a big database involved anywhere (e.g. facebook, which has to keep track of user profiles, mappings between users, groups, and god knows how many hundreds of other kinds of connections), it's a lot tougher.

in general, you can "scale up" (buy bigger servers) for a little while, but eventually you'll have to "scale out" (divide the load across a lot of smaller servers.) amazon's EC2 service lets you do this relatively easily. it's hardly plug and play though; you have to figure out how to scale out within your app and ensure that you can split up your data across multiple servers, which is often not trivial. for example, even if you can partition your data, what if one "piece" gets hammered with a disproportionate amount of traffic (i.e. one particular photo album or whatever gets dugg/slashdotted); what if a server goes down; what if you need to dynamically add servers; how do you protect data if a disk completely fails; etc.

here's some food for thought from the sysadmins of livejournal and digg, and how they dealt with growth.

http://www.getdropbox.com/u/2/Interesting/servers%2C%20infrastructure/danga.com%20livejournal%20backend.pdf http://www.getdropbox.com/u/2/Interesting/servers%2C%20infrastructure/digg%20sysadmin%20presentation.pdf

perhaps better than the technical solutions are social solutions to hypergrowth: you can use invites, beta periods or waiting lists to control your growth instead of turning people away indefinitely, and also set users' expectations that things may go wrong and to bear with you. it's really tough to anticipate on the technical side where things will break if you're adding hundreds of k users; just look at ilike, which got rocked by f8 signups.

there are more pieces too besides just serving the http requests properly :P presumably you'll need to provide some support to these people, answer emails, fix things when they go wrong, have some method of discovering and triaging problems, etc.

not found? mirror?

good discussion (check the comments too) of the hoops you'll have to jump through once you have the enviable problem of your customers wanting to open their wallets :)

annoyingly, paypal and google checkout really seem to have dropped the ball on flexible recurring billing (paypal requires buyers to have a paypal account, and google punted on recurring billing altogether)

same situation here. last day at the day job was last friday. rock on :)

is the problem that they don't like the idea, or aren't willing to give up their day job?

if the latter, i've seen pg's essays (either why to not not start a startup, how to make wealth, how to start a startup, whatever) and better yet jessica's book (founders at work) serve as a serious kick in the ass to people in cushy day jobs at ms and google; a few of my friends quit are now in this summer's yc program.

if pitching the idea isn't going well, i've found that giving potential team members problems to solve ("hey, how could this be made to scale to x members" or "what features should be put into the first version" -- whatever, the specific problem isn't the point) gets people going (and as a bonus lets you see if they give smart answers) and 1) makes them feel a sense of ownership/participation in the project and 2) opens the door to nudges like "yeah, these are the kinds of problems we'd be solving!" i've found this kind of end-around persuasion is better than arguing or trying to tackle objections head on (people love to buy; they hate to be sold.)

great article and discussion. lots of yc companies have gone this way -- we will probably as well. anyone have experience raising hundreds of k (in convertible debt) from multiple investors, or is it preferred to get that amount from only one or two?

the max levchin interview is fantastic, and probably among the top entrepreneurship-related things i've seen/read in a long time. i haven't seen the others, but seriously, go watch or read max's interview (he co-founded paypal and slide); there are a variety of gems about vetting startup ideas, working hard, catching "waves"/emerging markets, understanding business issues as an engineer, and lots of other things the news.yc should appreciate.

http://www.pbs.org/cringely/nerdtv/transcripts/002.html

short answer: part time sucks. long answer: part time sucks. i did a variant of this (school for part of it, work for another) for 3 years with my first company, and it was frustrating because you miss opportunity after opportunity because you move so slowly, and everything just turns out mediocre.

so if you have to do your startup with a 40-50hr/wk job, do it as briefly as possible until you can prove to yourself the worth of the idea and then make the jump. and this may sound strange, but get yourself in decent physical shape so that you have more stamina and aren't exhausted after a normal 8-9 hour work day. in my case i had way more energy/focus if i was running/lifting regularly (and frittered around/needed more downtime if i wasn't.)

i'm going full time on my idea at the end of this week and have a lot more momentum because 1) other people will be working on it with me and 2) i will be able to focus 100% and do things like pull all nighters when necessary and basically not have any other constraints in the way of getting things done.

i saw enough of a need for my idea to quit outright and just go for it (although i have some cash saved up and can live off a low burn rate). i think that if you have the right idea and are truly passionate about it, you just know that you will be able to make it work. i did my first company by bootstrapping/moonlighting, and thought i was passionate about it, but really in retrospect it was a stupid hedge (i didn't quit my day job, for example) and my reluctance to go for it should have just been a signal that i didn't really believe in the idea as much as i thought.

as far as the new idea, i intended to leave outright back in january but instead reached an agreement with my employer to go part time for a few months (to finished a project/accrue some more stock) while i built a prototype for my idea. (in retrospect, another unnecessary hedge, but live and learn.)

not being full time on my new idea quickly became very frustrating as i felt my attention was fractured, but i still got a lot done, and it was a decent compromise that allowed me to get a team and a prototype together and sanity check the idea with smart people/entrepreneurs/investors and secure seed funding.

that said, i would be a lot further along if i had been full time over the past 3-4 months, so if i could do it again i would have quit earlier.

in any case, my last day is this friday, and i had given notice before my yc interview (even though funding hadn't yet been secured.) it's helpful to have a cushion (6 months to a year) to tide you over until you'll have something (prototype, team, ideally even something more like a beta launch) that is attractive to angels or VCs. and add some elbow room because it'll probably take you 2-3x as long as you think! the cushion helps to save you from needing to have to scrap around for consulting gigs and dilute your focus, but isn't strictly necessary.

but if you're good, your worst case scenario is just getting another job or taking another swing, so it's not as risky as it might seem. and hedging your bets/moonlighting/halfassing things (they're all the same thing :)) is more of a risk than just going for it unless you have some strange idea where getting to market quickly isn't absolutely critical.

drew (http://getdropbox.com )

see you all there!

now it's down;

http://www.getdropbox.com/u/2/digg.gif if you want a screenshot of what it looked like before it died :P

edit: back up now

there's a group like this that does monthly dinners (open invitation):

http://finance.groups.yahoo.com/group/boston-startup-meetup

next meeting may 9th:

http://www.mypunchbowl.com/publicparty/05c98908a9a3e84e593d

see you there!

cool. i'm in; i'll hopefully drag some of team dropbox along with me :)

i think another factor that distinguishes skype (and joost, and xobni, etc.) as not inherently "web 2.0" is serious secret sauce/engineering under the hood (protocols, algorithms, search, scalability, etc.) see http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf -- very cool stuff (anti-reversing protection, crypto, clever protocols, etc.)

one of the biggest drawbacks in the web 2.0 world from a business perspective is that often the technology provides little barrier to entry. with the typical web 2.0 idea you're not competing on technology but rather on distribution/PR/marketing/engineering user adoption -- things most hackers aren't inherently good at.

one critical point of leverage that good hackers have is the ability to provide solutions to hard engineering problems that are usable and valued by normal people (google, skype, kazaa, bittorrent, etc.) conversely, if you're not solving hard problems, or are solving hard problems that normal people don't care about, your advantage as a good hacker is diminished.

is that a subtle kick in the ass? :)

for me it was the same way that i learned programming or guitar:

1. start with tutorials or poking at an existing design until it does what you want; learn the fundamentals of html and css from a dummies-level book or tutorials

2. find motifs or patterns you like, and reverse engineer (i.e. steal) them: specifically, start with a canvas with the original image on the left and try to create it from scratch on the right

3. repeat 2 until you have a toolkit of techniques (e.g. web 2.0 motifs like gradients, rounded corners, patterned backgrounds, reflections, all that cliched shit :)) and can put together things from scratch

4. integrate more formal theory (graphic design books, typography, photoshop/illustrator technique, web design books, etc.)

your first few designs will suck, but you'll get better :) but definitely learn by doing.

One at startup school '05; one was a friend of a friend I met at MIT (who then co-founded a YC-funded company.)

memcached (google it) implements this idea (giant in-memory hash table), and scales to multiple machines. used by facebook and lots of other very high volume sites.

it's often also used as an LRU cache on top of a normal database so that you can still get the benefits of persistence and rich queries but use memcached to lower the number of hits to the disk/DB.

barcamps (at least in boston) bring together pretty much exactly the people you're looking for, and the group is fairly diverse (young, old, hardcore hackers, serial entrepreneurs, more "corporate" developers, a couple investors/service providers, etc.)

what do people recommend for handling subscriptions/automatic recurring billing that can change over time?

haha, the feed is off.

a fair question -- i would have loved to work with adam and matt, but at the time my stock hadn't yet vested in another startup where i had been working for a while, and i was also running another company i had started in 2004, so the timing wasn't quite right.

i don't want to drag this thread offtopic so shoot me any other questions by email -- thanks :)

they are looking for employees :P but it would be a much better learning experience than a typical job; you'd be joining early enough that you'd be with the company basically from the beginning and would have much more of an opportunity to take on serious responsibility and make a significant impact (that, and much more equity than later employees :P)

let me +1 this post.. adam and matt are not only damn smart but awesome guys (i worked out of their living room last summer and we had a great time.) xobni's on a fantastic trajectory and this is a rare opportunity for a smart hacker to get in early -- definitely check them out.

if you're thinking of developing a web app in lisp but haven't looked at python or ruby, you might consider them -- remember, it's not just the raw language but also the surrounding infrastructure, and python (django, turbogears) and ruby (rails) have arguably much more developed frameworks, and also arguably have most of the interesting language features that would draw you to lisp in the first place.

the point is the language is only one piece of the equation -- you want to be spending your time developing your app, not rolling your own supporting elements (templating systems, init scripts, form validators, sql bindings/mappers, etc.) and of course i'm sure others will point out reddit's switch from lisp to python.