What's the holdup on your startup?
Limiting factor time, money, both? There may be an idea for a startup in what your inhibiting parameter is.
34 comments
I was able to solve one of my holdups using news.yc. I needed a fair amount of money to buy new servers, get really good co-location service, pay for incorporating, and cover some other expenses. By posting to news.yc my need and what I thought I could do (will do) I was able to find someone to buy-in a 5% stake of what I am doing. The news.yc forum is a powerful medium. In all I found a partner willing to to give me $20,000 (its in my bank now) so I could make things happen. 5% may seem like a lot but I figure I still own 95% and have no need to go out and look for more money.
This is the coolest comment I've read on news.YC in a while. Congratulations!
Until Dec 6th, my hangup is school, it's a time-eater. I'm taking some time off (and probably never going back) to start my startup, with some YC style funding from some personal sources; I feel like the money is paltry in comparison to the contacts and the tech-world help that YC gives. That's not necessarily a holdup of mine, just a concern. I know that it will be harder to find good business and legal advice, and such; but it will come.
Time, and brainpower. Too big a problem, too stupid.
Money isn't really an issue - for the stage we're at now, more people would only hurt us, so our only expenses are my living expenses (practically nil; thank you mom & dad) and a cheap server.
Money isn't really an issue - for the stage we're at now, more people would only hurt us, so our only expenses are my living expenses (practically nil; thank you mom & dad) and a cheap server.
What's the thinking behind "too big a problem, too stupid" and then -> "more people would only hurt us"?
More people means that each one of them would need to be brought up to speed on the problem, and then each time we try something out, we'd need to communicate amongst us to make sure this new approach wouldn't adversely affect (too much) what the other folks are trying out. Communication overhead is O(n^2).
There are two stages a software project goes through. In the first, you're exploring the design space and trying to figure out what the constraints are. There's no architecture yet, because an architecture is a reaction to a set of constraints, and you don't know what those are yet. So a change anywhere could result in radical changes to the rest of the codebase. You might find out that the approach you were trying just doesn't work at all and you need to scrap everything and start again.
In the second, you have a basic architecture and a set of users that are happy with the product, and you're trying to incrementally refine it so it has broader appeal and users like it more. Here, developers only need to be familiar with one section of the code, because the basic architecture is set and changes should be fairly well localized. Things like tweaking a UI widget, or adding a new feature, or changing look & feel.
The first situation requires that all developers be familiar with all parts of the code, and so (given the O(n^2) communication overhead) is best done by a single person. The second allows developers to work in parallel on different features, and so is best done by a large team.
This also explains how to reconcile The Mythical Man Month (which recommends a team size of one, plus supporting cast) and open-source software like Linux (created by thousands of volunteers across the globe). Brooks was writing about software systems before they're delivered, when the architecture is first emerging. When Linux was new, it was created by a single developer too. It's only after it became moderately useful that it was opened up and people started contributing patches.
I suspect it's also behind much of the acrimony between the static-typing (Java/C++/C#) and dynamic-typing (Python/Perl/Ruby/PHP) camps. Dynamic languages are much better in phase 1, because they don't enforce interface boundaries when you don't yet know the interfaces. Static languages are better in phase 2, when you have clear interfaces and the hordes of programmers need to know what will or will not break things outside the area they're working on. You can use dynamic languages for this too, but you need to essentially reinvent most of the features of static languages through documentation, testing, and assertions.
There are two stages a software project goes through. In the first, you're exploring the design space and trying to figure out what the constraints are. There's no architecture yet, because an architecture is a reaction to a set of constraints, and you don't know what those are yet. So a change anywhere could result in radical changes to the rest of the codebase. You might find out that the approach you were trying just doesn't work at all and you need to scrap everything and start again.
In the second, you have a basic architecture and a set of users that are happy with the product, and you're trying to incrementally refine it so it has broader appeal and users like it more. Here, developers only need to be familiar with one section of the code, because the basic architecture is set and changes should be fairly well localized. Things like tweaking a UI widget, or adding a new feature, or changing look & feel.
The first situation requires that all developers be familiar with all parts of the code, and so (given the O(n^2) communication overhead) is best done by a single person. The second allows developers to work in parallel on different features, and so is best done by a large team.
This also explains how to reconcile The Mythical Man Month (which recommends a team size of one, plus supporting cast) and open-source software like Linux (created by thousands of volunteers across the globe). Brooks was writing about software systems before they're delivered, when the architecture is first emerging. When Linux was new, it was created by a single developer too. It's only after it became moderately useful that it was opened up and people started contributing patches.
I suspect it's also behind much of the acrimony between the static-typing (Java/C++/C#) and dynamic-typing (Python/Perl/Ruby/PHP) camps. Dynamic languages are much better in phase 1, because they don't enforce interface boundaries when you don't yet know the interfaces. Static languages are better in phase 2, when you have clear interfaces and the hordes of programmers need to know what will or will not break things outside the area they're working on. You can use dynamic languages for this too, but you need to essentially reinvent most of the features of static languages through documentation, testing, and assertions.
I was just commenting on the fact that apparently you have a problem, but not the resources to solve it, it seems that the communication overhead for even one other person would help you see the issues and details needed to solve whatever problem it is that is being dealt with.
I've got a cofounder, and yes, he helps. The problem is still brainpower-constrained.
My challenge is that I don't have a problem with the ambiguity behind knowing what to do, (I love it actually) it is just getting the cahones to say, "YES, I will commit to this uncertainty, if it kills me."
Same here. It's taking that step that looks like it's off a cliff. The irony is that, in talking with other folks, I'm told the drop off is only a few inches. The cliff is an optical illusion.
Time.
We discovered that we were generating so much data that Rails and MySQL wouldn't cut it. We need to rearchitect our backend in data warehouse + MOLAP terms, and ActiveWarehouse is too young to bet a company on. So, time to learn a new platform and rewrite everything. :P
We discovered that we were generating so much data that Rails and MySQL wouldn't cut it. We need to rearchitect our backend in data warehouse + MOLAP terms, and ActiveWarehouse is too young to bet a company on. So, time to learn a new platform and rewrite everything. :P
Too much time spent on a certain social news website :)
Haha, Internet Explorer quirks. Almost done actually, doing some touch-ups here and there, and then launching an invite only beta early January.
Money and advisors (oh, if only YC would just accept us). We can bootstrap all we want and keep on tapping into our bank accounts, but we need to generate money somehow. The first product hasn't reached the powerful userbase it needs to generate the high CPMs or the deep sponsors. The second product is launched with a paying media partner, but that sucks because they get some of the branding, which decreases our branding.
The departure of two co-founders has made it take several months longer than I expected. All the same, I should be launching in the next week or so.
Identifying a good idea is my limiting factor. I have the ability (practical and theoretical) to create all sorts of software, but no idea feels solid enough to base my future on. For most of the ideas, the market is too small or saturated.
I wonder if I'm thinking too small.
I wonder if I'm thinking too small.
I'm the opposite; too many ideas coming and going all the time and not enough time to do anything with
though, maybe that's for the better as I would end up pursuing a lot of things that had little or no substance
though, maybe that's for the better as I would end up pursuing a lot of things that had little or no substance
@ Mrevelle. Just start to build something and pitch it to people (your would be market). The idea will always change and the feedback will always help.
Every bit of progress you make increases your future success whether it is with this venture or another. I meet 3 people a week that need programers or technical co-founders. If you're in NYC, email me, I can put you in touch with people that have good ideas.
Every bit of progress you make increases your future success whether it is with this venture or another. I meet 3 people a week that need programers or technical co-founders. If you're in NYC, email me, I can put you in touch with people that have good ideas.
Thanks for the reply. I know you're right, and I have a few ideas that I should start on and let evolve.
I am looking to join up with a few others (technical, design, or business/marketing) but am in the DC area now and will eventually be in Austin.
If anyone in Austin is interested in meeting, please lob an email my way.
I am looking to join up with a few others (technical, design, or business/marketing) but am in the DC area now and will eventually be in Austin.
If anyone in Austin is interested in meeting, please lob an email my way.
You're probably thinking too big. I have that problem often. Sometimes, the best ideas are the simplest ones.
ME TOO. Amen, brother. I have vague ideas and have the feeling I might be onto something but concrete ideas elude me. :-( :-(
Found a summary of a book on "lateral marketing" from a previous "Ask YC" thread that's helpful, though obvious.
It's nice to have the vocabulary, and associated granularity, for idea-forming.
http://www.squeezedbooks.com/book/show/5/lateral-marketing-n...
It's nice to have the vocabulary, and associated granularity, for idea-forming.
http://www.squeezedbooks.com/book/show/5/lateral-marketing-n...
Non-startup related chores that really can't be put off. That and a thorny technical problem that would be solvable if I could get a few days to focus on it, if I didn't have these non-startup chores.
"... Non-startup related chores ..."
Same here to some extent. There are certain tasks ("fatigues") that I have to do at set times during the day. The only suggestions I have is to focus on small bits at a time and chip away. Another thing is to use exercise as thinking time. Think on very specific problems. Write your solutions as you get them. Then work on them.
Another suggestion might be to adopt the Joshua Schacter (Schacter worked while building delicious) model of "being lazy". You can read/listen more about his techniques here. [0], [1]
[0] http://notelab.infogami.com/startupschool2006
[1] http://wiki.ycombinator.com/presentations/apr06/Joshua_Schac...
ps; Oops I downvoted by mistake while trying to upvote, so I re-adjusted via prior comments.
Same here to some extent. There are certain tasks ("fatigues") that I have to do at set times during the day. The only suggestions I have is to focus on small bits at a time and chip away. Another thing is to use exercise as thinking time. Think on very specific problems. Write your solutions as you get them. Then work on them.
Another suggestion might be to adopt the Joshua Schacter (Schacter worked while building delicious) model of "being lazy". You can read/listen more about his techniques here. [0], [1]
[0] http://notelab.infogami.com/startupschool2006
[1] http://wiki.ycombinator.com/presentations/apr06/Joshua_Schac...
ps; Oops I downvoted by mistake while trying to upvote, so I re-adjusted via prior comments.
Injured wife and sick baby. Try reasoning your way out of that one!
Not being a hacker and not having enough money just yet to hire one for my startup. So I spend a lot of time looking for and trying out shortcuts that tend not to amount to much.
Probably getting enough funding up to start working full time on it. I am loathe to quit my day job before I have at least enough cash to last 6 months or so stored up.
Time... it's not on my side.
3 things:
Time, time, & time
Time, time, & time
[deleted]
visas