Ask news.yc: Raising money using bank loans? - <AUTHOR>

I'm interested in hearing any thoughts that some of the other Hacker News readers on starting a company using loans, and who might be the best places to approach?
We're a small team, about 70% of the way through a fairly hefty project. We've done most of the back-end code, but we need to contract some artwork, and want to move one of our co-founders to working FT on the project, in order to speed up development.
SBC style loans are offered by Citizen's bank and others-
These loans, as I understand, typically require that you invest 30% of the loan amount into the company at the time of the loan.
 While we've invested quite a sum over the last few months as we've been building (legal fees, etc), I don't have a huge amount of up-front capital.
There's private sources of capital such as America One (amone.com), but they seem very shady, and want a high percentage as a finder's fee.
I know we could end up going to Angel Investors asking for a loan, but we don't know any personally, and building lengthy presentations for investor meetings takes time away from actually building things, as well as dilluting capital.
We're very dedicated to the idea, and the company, and I'd appreciate any advice, thoughts, or experience as other people have gone through this part of the process.

<comment><USER2> Banks are for houses and sometimes cars. They might be for restaurants and brick-and-mortar businesses, but I don't think it's a wise idea, since those also fail. They are not for technology startup companies, and not just because they don't want to loan you money.

There are angels who will give you convertible debt at reasonable terms, if they like what you're doing. But, it's probably wise to give up a little equity to get someone with some money savvy working towards your success, and that's one of the benefits of raising money from investors that work with tech startups.

In short: Banks don't want you, and you don't want them. Debt is bad for you.

<comment><AUTHOR> Alright- You seem to be in the consensus on the news.yc board, and I'm coming around to your viewpoint. That being said, what are the alternatives? I'm already working 65 hours a week on my primary job, which I need to pay rent and the server costs, art costs, etc for the startup.. Then I'm putting in another 30-35 a week on the startup (12 on Sat + 12 on Sun + 4ish Tues-Wed- Thurs)..

I can't really take another job- I just don't have time to do that, and actually code anything. Approaching AAs is hard, since the product isn't as "Sexy" as a lot of things. It's likely to a good few hundred K per year after we get it going, but it's not the next Microsoft.

Do you have any ideas on where else to look? Is there something outside the AA route, or even a sub-niche within in we should look at?

<comment><USER3> Whoa, you work a lot! I would never manage that. Currently working maybe 30-40 hours a week on our start-up (or maybe spin-off would be a more appropriate term), and I feel I could not really be that productive for much more hours per week.

Of course I am often processing the problems in the background while doing something else...

<comment><AUTHOR> The hard part of working that much is trying to balance work and Family. Mostly I've given up sleeping- I know it's not ideal, but I'm down to 3-4 hours a night.

In full honestly, the 65 hour figure only comes in when I include travel time. (about 2 hours/day)

My typical day is:

Get up at 5am, and head to work. Work from 6-4, then head home. Drive home. Family stuff from 5-7 until my partner gets out of work. 7-1, Startup stuff.

1-5, sleep.

On the weekends, I try to get a bit more family stuff in, but then I usually end up going to work for another 3-4 hours on Sat/Sun, and put in the rest of the day on the startup.

I wish I had time for a 2nd job, but, really, the startup is the 2nd.. and the 3rd. ;)

I'd love any ideas to raise additional money for the startup- If we could work on it full-time, we'd really be doing something special.

</comment></comment></comment></comment><comment><USER4> A bank would value a startup at zero, and thus expect you to put up your personal assets as collateral. That would be a big mistake.

It's because banks can't evaluate startups that venture investors exist.

<comment><AUTHOR> That's fair, but at the same time, I'm hesitant to agree, on a few ground-

1) You're certainly right that banks have nothing to go on. My credit isn't amazing, but its certainly decent enough that I could probably manage a small loan from the banks on personal credit alone. It would provide a few months float money, at the least.

2) You've argued heavily before that there needs to be an element of becoming personally committed[1], providing motivation. Having a Personal Loan over your head is certainly one way to do that.

3) Are there other options? Raising Angel money would be more difficult for us that for some projects, because we're not as Sexy as we could be.. We sent in a yCombinator proposal that was very ambitious, but were rejected, so we scaled back to what we thought we could achieve on our own.

We're doing a pretty decent job on it, but its not going to be the next Google, or even the next Scribd. Most Angel Investors seem likely to want to back a sexier horse, so to speak.

We do have a dedicated group of users waiting to sign up for paid subscriptions, and we know we could hit profitability reasonably quickly, but how do we get from here to there?

[1] <http://www.paulgraham.com/die.html>

<comment><USER5> 1) I'm sure you can find a way to get some sort of bank to lend you money regardless of your credit rating. There are plenty of banks in the business lending money in high-risk situations. Getting the money probably isnt the problem.

2) I see your point, but the problem with being in debt is that it is something you don't have control over or can easily fix. Having a collections agency call you all of the time threatening to repo your personal possessions is not exactly a positive motivator either. I would rather run out of money and be piss poor than have an unpaid loan over my head, personally.

3) Raising angel money is extremely hard I'm finding... This is a huge benefit of YC, IMHO. Guy Kawasaki said in one of his books that you are more likely to get struck by lightening than land VC funding. That quote is not as ridiculous as I once thought..

Thats awesome you've got dedicated users, keep it up. Aim for the sky though, dont tell yourself you wont be the next Google b/c if you think that way you surely wont be.

</comment></comment></comment><comment><USER6> I'm certainly no expert, but if you have (almost) guaranteed cash flow within some window that will make paying off the debt not a problem at all, I see no problem with taking on some temporary debt. Obviously, you are heavily investing your own funds at the moment, anyways, so what difference does it make if you put up some personal assets?

I can see a real benefit to using a loan in this situation, actually. It should be easy to close a reasonably small loan quickly, you don't have to give up any equity or worry about people trying to control what you do, and if you are in the position where you feel like a short-term loan is enough to get you over the hump to revenue, then you are probably on the path to success.

I do have two suggestions, however:

1\. Get your partner in on the loan somehow, too. No matter how much you trust him/her, it's not really fair to you to expect you to take all that risk while your partner takes on none.

2\. Reassess your situation and set reasonable expectations. How long will a loan last for? Is that long enough to finish the brunt of the work? How long until you start getting positive revenue (are you sure about your prospective customers)? With all those factors in mind, is the loan a smart way to proceed (i.e. an 80% chance that nothing will go wrong)?

<comment><AUTHOR> Very good point on getting the partner involved in the loan- I'd like to do this, but I'm not sure how to. We have a Delaware corp set up, but since the company doesn't have any credit, I don't know how it could take out the loan.

Perhaps the company could take out the loan, and we could both co-sign?

We're probably about 3 months from being at a point I'd feel comfortable charging- If we got a 10K loan, we could probably cover this easy.

The problem comes in that if our estimates are off, we've made the world a lot more painful for ourselves. We've had quite a few customers asking to pre- register, but I don't like the quality of experience that would give.

I appreciate the advice, thanks.

<comment><USER6> I mostly was referring to having your partner cosign or put up some assets himself, instead of you taking it all on yourself. Honestly, though, a lot can happen in 3 months. Be careful not to get in over your head and get yourself in a position where you're subject to financial hardship if something goes wrong. Of course, a 10K loan isn't really that much, and split two ways, it could be paid off inside of a year without too much trouble, so it doesn't seem to me like your risk is too high.

That said, you might want to take a little bit more just to give yourselves some leeway. That would allow you to use a portion of the loan to make the initial few (6 or so?) payments. If you think you're going to need to support your partner for 3 months full-time, I'd shoot more for 4, and allowing yourself a full-time month (in case it becomes necessary) might not be bad, either. Finally, I'd suggest using some of it for the operating costs you mentioned, so that you can work your other job a little less and spend more time on the startup.

One last suggestion: sit down for some time with your partner and discuss what the loan will need to pay for, how much is needed, and how it is going to be allocated. Leave part of it unallocated as a contingency fund. Discuss how to split the responsibility for the debt in the event of a failure. In other words, get everything on the table now so that there are no surprises down the line.

</comment></comment></comment><comment><USER5> I've been told explicitly by several people _not_ to finance an early stage startup with debt. I second utnick's suggestion to try to find other ways to make ends meet, until you can land some angel investment (in the form of equity financing). Not only can debt ruin your life if the startup fails, but a lot of debt can look bad on your books if you reach the point of looking for outside investment.

I recently learned about Certified Capital Companies (CAPCOS), which are government backed organizations that look like banks, but their investment turns into equity like an Angel or VC investment. Apparently they are still very conservative in their investments though, and may not have very desirable terms. But at least this is better than taking on a lot of debt. I dont know much about them, but they might be worth looking into if they are available in your state.

<comment><AUTHOR> Hrmm.. Very fair points, both on outside investors, and on CAPCOS. With outside investors, I know we'd get a better valuation if we could launch, and start bringing in revanue before we go out knocking on doors. Investing in a dream and a codebase is one thing, but seeing the numbers on paper has to help.

</comment></comment><comment><USER7> I don't think you can get an ordinary bank loan without some real cash flow.

<comment><AUTHOR> You can if you put your personal assets and reputation at stake instead. To a degree, this is what you're doing in a startup anyway. You're putting your money, time and energy on the line, and hoping for a reasonable return on that.

Granted, you may be right in that it's not worth it for many projects. The project we're working on isn't as sexy as some though, and is unlikely to take over the world. What it does have is a moderate number (300ish) of users ready to sign on as paying customers at launch, and a good chance to tripling that within 6 months. Those aren't retire to Tahiti numbers, but they're enough to pay for dev.

Those sort of numbers make it hard to approach most AAs, who want to see a 10:1 investment:return

</comment></comment><comment><USER8> I've heard good things about Chase small business loans. This looks like a good resource for info on lots of banks:

<http://www.pcmag.com/article2/0,1759,5837,00.asp>

Interest free credit cards are an easy way to go as well. 1 year interest free and then you can switch it to another card or take out a loan from your bank directly with a fixed rate and pay off the card.

<comment><AUTHOR> Thanks- That's certainly an avenue I'll look into.. It looks like they do the SBA loans that I had mentioned, but also do their own private loans, which might be an option.

We have two people in our team- If I could get a Chase loan to allow our lead coder to go full-time, and keep my job to make the payments, we could be OK until launch.

It's not optimal, but it might let us get the time we need to launch successfully and quickly.

I'm very open to any other ideas, and appreciate the discussion.

</comment></comment><comment><USER9> I'd also recommend against getting a loan. Finding an investor might be more effort, but you really don't want the added pressure of possibly losing your personal assets as well as everything else if your business tanks.

<comment><AUTHOR> Fair point, but we need to do something. I'd love any ideas- We're Mass based, and we've got the code about 80 percent done, depending on how you count. We've got users who are ready to pay when we launch, and we've got a decent potential for growth, but we know we're unlikely to be the next Google with this project.

In some ways, we're working to get the bugs out of our Engines, and working on our bona fides, so we can buy google with the proceeds from out NEXT project ;)

<comment><USER10> > We've got users who are ready to pay when we launch

How long (both money and time) are you from being able to launch? How many users are ready to pay and how much?

There are answers to those questions that imply that you can get money the money that you need now by offering said users a discount or longer subscription time if they pay now for your service when it's ready.

<comment><AUTHOR> I know we could (They've offered), but I think it's a pretty terrible user experience.

Essentially, they'd be pre-ordering based on trust in us, with nothing to show for it. I'd be happy to give them an extended subscription, but I feel like it would feel cheap, and make us look bad, not to mention that it would be a pretty frustrating experience for them.

I agree with the idea, I just don't think it can be made to work in a classy way.

<comment><USER10> Why are you arguing with your customers about what they want?

That's a hard argument to make if you're correct, but you're not - they are. It's an incredible user experience. It lets them in on the excitement. It gives them a story to tell others. That's why they want in.

And no, it's not "cheap" to give them a discount, it's rewarding them for faith and it's fair. (You can think of it as interest if you'd like.) It's also fairly standard practice.

Do it right, and they'll be out there selling more "pre-release" subscriptions for you. Deliver, and they'll be your best salesfolk.

Of course, it is poor form to take their money if you're not going to deliver.

</comment></comment></comment></comment></comment><comment><USER11> Probably a bad idea unless you already have cash flow. Getting into debt could ruin you for life.

It doesn't sound like you need that much money.

Work on reducing your expenses/taking 2nd jobs instead.</comment>


What Programmers Want Is Less Stupid And More Programming - <AUTHOR> http://thecodist.com/article/what_programmers_want_is_less_stupid_and_more_programming <comment><USER2> Programmers must program. If anything at all prevents a programmer from programming, he or she will grow unhappy. Incomplete designs, slow builds, too many salespeople, noisy construction out on the street, whatever. Programming good. Not programming bad.

<comment><USER3> I'm a glassblower as well as a programmer, and it's the same deal in this seemingly quite different line of trade. I recently was working in a group shop environment where many things were preventing me from getting work don - distractions, inadequate ventilation, inconsistent fuel supply - and I became quite unhappy.

<comment><USER4> That was my thought when reading the article. Replace programmer with accountant, marketer, designer, etc and the article would read the same. As much as programmers think we're special snowflakes, there's always another group (see previous list) that thinks they're special too and that no one else "gets" how they work.

</comment></comment></comment><comment><USER5> What I want is...Programming, Motherfucker!

<http://programming-motherfucker.com/>

</comment><comment><USER6> A lot of startups that are trying to be cool have lots of distractions. In fact, distractions are what they spend their time trying to create. They want to have people around who are on the 8 + 4 plan. Weeks will go by as the programmers spend 8 hours working and 4 hours fucking around.

</comment><comment><USER7> I think one of things that is a key de-motivator for devs is having to work with other engineers that don't really care about the quality of code they write, as they don't perceive software as an art-form or craftsmanship, but more as something that pays their bills. A lot of dev orgs don't spend enough resource/time evaluating dev work on a technical levels, leading to lots of bad code and frustrating the hell out of the good devs. The places who do instill passion and draw great devs, much like Apple at its height.

</comment><comment><USER8> Stupid pays the bills

There are two kinds of stupid.

Goal stupid, Facebook for dogs, funded startup, take the money, be upfront about the chances for business success but professional about chances of working software

Process stupid, Facebook, but putting 30 devs in different rooms not allowing them to talk or see each others code.

Goal stupid pays the bills.

Process stupid is what you are concerned about here. Process stupid is something you can almost always change as one lone dev. You won't ever change goal stupid. Let schumpter teach them.

</comment><comment><USER9> _required each of 30 programmers to write only their code and never see anyone's else's (because the managers thought they would steal the code)_ \- priceless! Thank you for this.)

Over-confident idiots (especially at management positions) is the must common cause of failure.

</comment><comment><USER10> I found these two passages interesting:

"The best programmers are always self-motivated: just give them opportunity to rock and stay out of the way."

and

"Programmers also complain a lot and can be incredibly lazy which is a good thing as it forces them to find ways to make things easier."

Self motivation needs to be greater than laziness. :)

<comment><USER11> Laziness _is_ the motivation :)

<comment><USER12> I've always felt "laziness" in programmers is often "I don't want to do this tedious crappy task, I'm going to do fuck all until an elegant solution pops into my head at which point I'll at least partially automate it"

Or at least it does with me.

<comment><USER13> I know that feeling. So often, especially when things are busy or deadlines are tight, I feel bad for wasting time surfing the internet or slowly tinkering on some unimportant task no one cares about. The big job is getting no attention. "The programming" is just gone, I'm hanging around killing time.

And then something flips and you get that flash of inspiration; and you dig into the program as fast as you can. In the end, you come out with a little piece of code that's relatively clean and maybe extensible and it _works_.

And you know... _you did it_... _that's why you're here_. Moments like that keep you going and boil your blood if you're in the world of TPS reports and their ilk.

</comment></comment></comment></comment><comment><USER14> What's up with this attitude that any activity that isn't coding is stupid? Why is planning your coding work so uncomfortable to most programmers? I worked on a SDLC based project management tool <http://www.dynamicalsoftware.com/analysis/code-roller> and what I learned is that this attitude is prevalent in a lot of dev shops.

</comment><comment><USER15> "corporate standards" are at least partially good. They should be reasonable though and adaptive to the times. Having a set of acceptable programming languages, frameworks, etc. ensures that the company understands the risks of those choices, can apply reasonable upgrade/maintenance/security patches as needed, can attract and retain personnel that understand the language, etc. Allowing arbitrary choice leads to complete anarchy. The opposite is also at least as bad. Having one rigid language/framework leads to obsolescence and inflexibility. A good programmer will be able to make a strong case as to why this new language/platform is _vastly_ superior to the current one because changing to the new one and supporting the old one are not zero-cost propositions.

<comment><USER16> Why not just create an environment that suits the company and its management. The programmer can decide whether that environment is best suited for them.

Some people prefer rigidity. I don't understand their preference, but I respect that it is their preference. But it's hard to say that arbitrary choice always leads to anarchy or the one rigid framework always leads to inflexibility. Everything varies. That's the beauty of people - we are all different, yet we coexists.

</comment></comment><comment><USER17>
      > Good programmers like challenges. Good programmers
      > hate stupid.

Is anyone who labels themselves a programmer going to disagree with this, especially when they can insert their own values for "challenge" and "stupid"?

The only interesting detail in the article, sadly, isn't investigated:

      > I've [provided effective management] on occasion (but always
      > as a leader who also codes), and I know it can be done.

The article would be much more helpful if it discussed the specifics of providing effective management, or even better, how an coder came to mangage a team in a world full of non-coding managers.

</comment><comment><USER18> Can't agree more. In a lotta cases is up to the programmer to keep solving the desired problems (interesting programming), we tend to say yes to too many things and this sends us to the path of perdition!. You gotta fight to keep doing the cool stuff.

</comment><comment><USER19> The moral arc of the universe is long, but it bends away from stupid.

</comment><comment><USER20> yup, this is actually want everybody wants. You can't have a boring, repetitive job. Challenge wakes everyone up unless you don't rise up to that challenge.

</comment><comment><USER21> As the person being replied to, I'll respond. This is an excellent post. Major upvote. I agree with everything the OP is saying.

My first point about "flow" is, I think, connected to this idea. Stupid wastes time. It breaks flow and replaces meaningful, objective feedback with noise. I also agree strongly that our happiness is correlated strongly with spending as much of our time on programming (I.e. real work) and as little time on stupid shit as possible.

<comment><USER22> _It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs. Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts._

[1] <http://www.paulgraham.com/gh.html>

</comment></comment><comment><USER23> the SOB phrase, never heard that adjective for the man!</comment>


A new approach to generating human organs is to grow them inside pigs or sheep - <AUTHOR> http://www.technologyreview.com/news/545106/human-animal-chimeras-are-gestating-on-us-research-farms/ <comment><USER2> One problem with human-animal tissue contact is the enhanced opportunity for zoonosis (cross-species diseases).

In the early 1990's there was a proposal to enclose pig Islets of Langerhans (insulin and glucagon producing) tissue in capsules with sub-cellular pores and implant them in diabetics. The idea was that rejection was less likely without direct cellular contact and the diabetics would gain something resembling natural blood-sugar regulation.

There were two problems that persist over the three decades of subsequent research: 1. rejection does still prove to be a problem, and 2. the problem was that pig viruses emitted by the transplanted capsules might eventually find an "error" that would infect the human host resulting in a brand new zoonosis shared by pigs and humans. The FDA refused trials as a result (see the last paragraph of this section in wikipedia: [https://en.wikipedia.org/wiki/Pancreatic_islets#Transplantat...](https://en.wikipedia.org/wiki/Pancreatic_islets#Transplantation) \- that article leaves out is the distinct possibility of other porcine viruses that might cross-species given the persistent opportunity this therapy might provide).

If one is being conservative - always a good idea when the prospect of new diseases are in the offing - the process of putting human tissues in pigs and then back in humans is at least as risky as merely putting live pig tissue directly into humans.

<comment><USER3> That might be addressed by modifying the animal to produce the dsired organ at the correct size, scrubbing out all livestock cells with strong detergents, then seeding the organ extracellular matrix with progenitor cells from the intended recipient.

There would be no livestock cells left, so no worry about zoonotic pathogens.

<comment><USER4> If you're leaving behind a protein scaffolding, wouldn't you still have to worry about prion diseases? What about viruses?

<comment><USER3> The only known mammalian prion is PrP, which noticeably affects animal behavior, and is detectable by testing lymph. If the animal has prion-related encephalopathy, you burn it.

Viruses cannot reproduce without living cells. Viruses that employ lipid capsids would likely be removed by the detergent along with the cells. Some viruses do embed in a type of extracellular matrix (HTLV-1). As far as I am aware, no research has been done on the transmissibility of viruses in decellularized animal organs from donor to recipient.

I presume that those facing imminent organ failure would rather catch a cold from a pig and recover in quarantine observation than die while waiting for such research to conclude.

</comment></comment></comment></comment><comment><USER5> That's the origin story for the pigoons in Oryx and Crake. [https://en.wikipedia.org/wiki/Oryx_and_Crake](https://en.wikipedia.org/wiki/Oryx_and_Crake)

</comment><comment><USER6> Not trying to troll, but I can see the idea of organs grown in pigs not going down particularly well with the members of at least 2 world religions.

<comment><USER7> Being given the option of dying or not dying is the sort of thing that causes people to rethink dogma.

<comment><USER6> Hmm, I'd _like_ to agree with you, but there are plenty of examples where this kind of situation has occurred and the dogma won :(

EDIT: To clarify; I mean dying vs not dying, rather than specifically having an animal-grown organ inserted.

<comment><USER8> Personally, I think people _should_ have a choice. But I'm guessing we'll see both: Some will rethink their dogma, and others will put their money where their mouth is.

<comment><USER6> I couldn't agree more that people _should_ have a choice.

Whether they exercise that freedom of choice though...

</comment></comment></comment></comment></comment><comment><USER9> It's not exactly a new approach, but it may finally get off the ground...

<comment><USER10> My first thought when I read the title was "I'm pretty sure this idea made a big splash about twenty years ago."

<comment><USER11> Retroviruses were the major showstopper, now they can identify them and remove them from the genome. Maybe they run into another roadblock, but... Maybe it works this time.

</comment></comment></comment><comment><USER12> A small step to growing intelligent pigs? Put a human brain in one?

<comment><USER13> Pigs are already intelligent.

</comment></comment><comment><USER14> Pigoons!

</comment><comment><USER15> Duke Nukem - how Pig Cops came to be.

</comment><comment><USER16> Like we didn't have enough sheep and pig headed people around...

<comment><USER17> You won't grow heads in pigs and sheeps. More like livers and hearts. So they'll be pig-livered and sheep-hearted.

<comment><USER18> If given the choice, please grow my organs inside of a sheep.

<comment><USER19> Would be kinda funny if they only get it reliably working in pigs.</comment></comment></comment></comment>


Ask HN: Novelty ideas or concepts worth exploring? - <AUTHOR> It feels lately that everywhere I look seems to be a recyclement of the same ideas and same concepts, repeating over and over again, lacking novelty.<p>In an attempt to escape this bubble, my question to you, HN, is this:<p>- What did you learn recently that was surprisingly fresh and different? What concept or idea has been the last to grab your attention and is driving you to explore more deeply? Links are welcome, articles, book suggestions, videos, or maybe (and perhaps even better) software projects? <comment> non-entity Not sure if it counts as novelty or not and its not purely software at all, but I've been learning about and experimenting with VLC ([https://en.m.wikipedia.org/wiki/Visible_light_communication](https://en.m.wikipedia.org/wiki/Visible_light_communication))

Hopefully when I have a semi useful prototype done I'll be able to write more about it. I'm particularly interested in the upcoming 802.11bb standard and it would be cool to design something that can take advantage of or at least build upon existing 802.11 stacks.

This was a pretty easy to understand paper introducing VLC concepts [https://ieeexplore.ieee.org/document/8257800](https://ieeexplore.ieee.org/document/8257800). Sadly it does cost money to read and unfortunately I'm not aware of any way to access ieee documents without paying. Although since it's a research paper and not a standard, you may be able to find it on sci-hub or something similar.</comment>


Ask PG: What % of a failed YCstartup employees are rehired by other YCstartups? - <AUTHOR>

Emilio Castilla and others have studied the movement of employees among the VC firms in Silicon Valley vs. Route 128 (http://www.stanford.edu/group/esrg/siliconvalley/docs/siliconvalleyedge.pdf)<p>Has anyone at YC or outside looked at the movement of employees and founders from failed YC startups to other YC startups? While no one in YC wants any of their peers to fail, I would imagine that the failed startups provide an ample base of talent from where other startups can hire from. Do you guys have any numbers on how much talent "stays in the family"? <comment><USER2> That's an interesting question. The other things I'd like to know is, "Why did those startups fail? Was there anything the founders/employees could have done to save it? What did they learn from their experiences."

If it's a marketplace, marketing, or product problem then ok. But if the team fell apart, if there were internal conflicts, or if someone didn't pull their weight...then those might not be good candidates to bring on board to other startups no matter how smart they are. What bothers me about some teams are, there are people that you can tell have no initiative, they do the minimum of what's required, and they don't double check to make sure that everything works and invariably something minor comes up to trip up the project that could have been prevented. I hope I never get those people on my team, if I do they need to go.

Another thing I'd also like to know is, "How many of those people from failed YC startups founded another startup or did they just go back to a job or to being an employee at another startup?"

<comment><AUTHOR> Those are basically the same types of questions I have as well. I reckon there is a lot to be learned from the YC network of startups. It's a great space for a grad student at Stanford's or Berkeley's iSchools to investigate.

</comment></comment><comment><USER3> if you don't get an answer, that sounds like something you could brute force by gathering a list of YC startups and looking up the founders on LinkedIn.

<comment><AUTHOR> LinkedIn actually had pretty poor info when it comes to startups and the people who work at them. The professional social network for startups works well enough that many people have never felt a need to exploit LinkedIn connections for their next gig. It's often salespeople who most appreciate what LinkedIn has to offer. LinkedIn has always been surprisingly bad at capturing the professional network value in asymmetrical relationships. Great professionals and influencers (which YC founders are likely to be) are those that avoid LinkedIn the most because it's a distraction.</comment></comment>


Start with a Problem, Not an Idea - <AUTHOR> http://blog.startupprofessionals.com/2009/03/startups-start-with-problem-not-idea.html

<comment><USER2> Somebody has been plagiarizing pg: <http://www.paulgraham.com/ideas.html>

OP: "Fix something that's broken. In business, it seems to me that the traditional banking business models are broken or at least no longer fit the purpose. On the other end of the spectrum, Internet dating sites don't seem to work. They have millions of users, so they must be promising something people want. And yet they work horribly. Just ask anyone who uses them."

to pg: "One way to make something people want is to look at stuff people use now that's broken. Dating sites are a prime example. They have millions of users, so they must be promising something people want. And yet they work horribly. Just ask anyone who uses them. "

Or "Take a luxury and make it a commodity. People must want something if they pay a lot for it. It is a very rare product that can't be made dramatically cheaper if you try. When you make something dramatically cheaper, you sell more, and people start to use it in different ways. For example, once cell phones were so cheap that most people had one, people started using them as cameras and Internet devices."

to pg's : "Another classic way to make something people want is to take a luxury and make it into a commmodity. People must want something if they pay a lot for it. And it is a very rare product that can't be made dramatically cheaper if you try.

This was Henry Ford's plan. He made cars, which had been a luxury item, into a commodity. But the idea is much older than Henry Ford."

<comment><AUTHOR> Good catch: I took a hard look and have to agree that the number and phrasing of the exact matches seem to be well above the level of coincidence. I posted this on the site, curious as to what the reply will be. \---

I posted a pointer to this on <http://news.ycombinator.com/> at <http://news.ycombinator.com/item?id=661440> and this reply <http://news.ycombinator.com/item?id=661875> pointed out exact matches for six sentences in an October 2005 essay by Paul Graham at <http://www.paulgraham.com/ideas.html>

here are the matches:

       [dating sites]
       They have millions of users, so they must be promising something people want.
       And yet they work horribly.
       Just ask anyone who uses them.

       [T]ake a luxury and make it into a commmodity.
       People must want something if they pay a lot for it.
       And it is a very rare product that can't be made dramatically cheaper if you try.

Were you influenced by Graham's essay? The number and length of exact matches seem well above the level of coincidence.

<comment><AUTHOR> Martin Zwilling wrote back

       Thanks for the note. I have added a credit link at the end, and an apology note
       as a comment to the blog following yours.
       I'll be more diligent on this in the future

He also added a postscript to the post this afternoon

       P.S. I would like to give credit to an October 2005 essay by Paul Graham for a
       couple of the ideas above, at http://www.paulgraham.com/ideas.html

</comment></comment></comment><comment><USER3> _Take a luxury and make it a commodity._

It works the other way, too. Water is a commodity -- a commodity which is, essentially, free at the margin -- that is also a multi-billion dollar business in the US. Much the same could be said about food.

(I am about to step on some toes. Turn away if you're easily offended.) There are entire industries which are designed around the proposition "You are too good to consume X. Poor people consume X. You should instead be consuming X Prime. You can tell it is better than X, because it costs five times as much."

A separate but related issue: consumption of status goods among poor people.

In terms of selling B2B services, I am often amused by re-luxurization of commoditized services: taking something which was once customized and extraordinarily expensive but then made into cheap-and-infinite-scale and then competing with the cheap-and-infinite with something that is a cut above but which still scales.

Data centers circa 1996: luxury service. Web hosting: commodity service. Slicehost: not a commodity service, but the marginal cost to the firm is still close to zero.

Personalized financial advice: luxury service. Your bank's website and free checking: commodity service. Mint: personalized financial advice, but at scale.

Graphic design: luxury service. Stock icons: commodity service. 99designs: commodity-priced luxury service that scales.

<comment><USER4> People often come up with water as an example, but it fails on many levels:

 _In many cities the "native" water is full of chlorine_ If you travel to a foreign country, you may not be able to drink the native water at all _If you are not at home, getting water may not be possible unless you by it in bottles._ Bottles enable you to carry around water, which is useful for car trips, etc.

<comment><USER3> On the contrary, if smart people can be convinced to ignore the practically inexhaustible and freely available supply of water in every building in most first world countries, then I think the de-commoditization of water was an astounding success.

(I mention this because it is intellectually interesting to me, not because I hold contempt in my heart for people who buy bottled water, by the way.)

Incidentally: HN doesn't support unordered lists very well, particularly if you like starting them with asterixes. The best alternative I have for you is starting them with + signs and putting two linebreaks between points.

<comment><USER5> I think this falls flat as well. Many people have tap water at home that is a) hard and/or b) doesn't taste very good. You can tell the difference.

<comment><USER6> You can also buy a water filter, and get better tasting water extremely cheaply when compared to bottles.

</comment></comment></comment></comment></comment><comment><USER7> This is part of the perverse reason I can't get behind the advice to start a startup immediately after university.

Suffering at a large company for a while isn't self-flagellation, it hands you hundreds of things needing solutions.

<comment><USER8> I'm not sure if working at a large company is the most efficient way to get inspired.

<comment><USER9> It's not getting "inspired", its finding all the problems they have and are incapable of fixing due to bureaucracy, then stepping out of the place and coming back with a product that solves the problem. It is often easier to get money out of big companies than change.

</comment></comment></comment><comment><USER10> Couldnt DISAGREE more. The advice is extremely banal bordering on common sense but most importantly discounts the fact that a lot of startups are built not to solve any existing problem but perhaps to just better an existing solution.

The semantics are crucial here, because solving a problem almost implies that it is something a customer 'understands' to be a problem and not just satisfed with the status quo - that is true for almost everything - give me a better house, car, laptop, email, search etc. etc. anyday and if its really good enough I will switch.

The biggest startups were not found by scratching an 'itch' but through founders idiosyncratic views of the status quo and how they belived (without an MBA, without a customer survey and without figuring out if it was really an 'itch') on what was a better way, and for a long time without any external validation.

Selling books online - how does that even make sense, the internet was supposed to get rid of books but Amazon found a way. The iPod - if no one even knew something like this can be built, how can it possibly be a part of their 'itch'. Twitter - I bet there was no itch here too.

<comment><USER11> Your last little blurb is off the mark: Mp3 players existed long before the iPod, but they had poor usability and no centralized store to legally purchase music. Bookstores existed long before amazon, but their inventory was limited. Blogging existed long before twitter, but it was a bit overkill to use existing solutions for micro-blogging.

<comment><USER12> Yes, but everyone was happy with the status quo of MP3 players at the time. Nobody wanted the iPod. Everybody said it would fail. And certainly no one was asking for a centralized music store. Pfff!

I don't really agree with OC on other points, but the iPod _really_ didn't scratch an itch. It changed the game by creating something new, not something that "solved a problem."

To say the iPod solved a problem is pure hindsight.

<comment><USER13> > Yes, but everyone was happy with the status quo of MP3 players at the time

No they weren't, most people couldn't figure them out.

> To say the iPod solved a problem is pure hindsight.

No it isn't, the iPod brought it to the masses by making it simple enough for everyone to use.

</comment></comment></comment></comment><comment><USER14> Absolutely true. Nothing here is ground breaking, but it seems like so many people forget this. My greatest successes have always come from trying to "scratch my own itch." In fact, it's usually something completely out of left field that never seemed like a business that turns out to resonate with others.

</comment><comment><USER15> The title itself is a ton of advice. So simple and so profound.

I think 'start with a problem' - creates a clear definition of success (solve the problem), demands focus and makes everything so simple to figure out.

</comment><comment><USER16> What is the problem behind Twitter, by the way?

<comment><USER17> Your question brings up my age old question. Communication on the internet has been solved multiple times, again-and-again, since IRC/mailing list (That's as far back as I can remember).

Then, why there's still room to grow for IM, Meebo, and now Twitter?

</comment></comment><comment><USER18> I agree. Consider twitter on the other hand.

I would argue that while it may have been introduced to solve a certain "problem" (communication hub for friends/local groups, "I want to have a dispatch service that connects us on our phones using text."), its success comes from accidentally satisfying different needs.

</comment><comment><USER19> The counter of course is the Blue Ocean Strategy, in which the product solves a problem that people didn't know they had.

Given the innovation of the web, Blue Ocean is just as viable than these other four methods.

There are several ways to implement a winning business, talking points tend to forget that.

</comment><comment><USER20>
        What is the Problem?
        Who is the Customer?
        Who is the Competitor?
        What is the Revenue Model?

A case study [http://xml.gov/documents/completed/bah/registryBusinessCase....](http://xml.gov/documents/completed/bah/registryBusinessCase.htm)

</comment><comment><USER21> <http://paulgraham.com/ideas.html>. Similar, no?

</comment><comment><USER22> Good post, but I dislike the "ideas are worthless because there is no market for them" idea:

<http://journal.dedasys.com/2007/04/26/ideas-are-worthless>

</comment><comment><USER23> Why even post a link to the blog? Why not just the headline? I get the gist. I don't really need an entire anecdotal blog post to loosely explain a piece of advice.

</comment><comment><USER24> Couldn't agree more! Kevin Rose's Problem was, not being able to get news to the SlashDot home page. And we all know how successful the solution he came up with.

</comment><comment><USER25> Not always true, for example twitter didn't solve a new problem. People could communicate before just fine; it just provided another method to stay connected.</comment>


Scala 2.12 roadmap - <AUTHOR> http://scala-lang.org/news/2.12-roadmap/ <comment><USER2> To be honest, I feel like the next few versions of Java will assimilate all of Scala's good features. Java 8 already added lambdas, the optional type, and so on.

In a production system, Scala is quite frustrating to work with because of the frequent backwards compatibility breaks, and the slow-motion build times. Not to mention the new stuff which almost but not quite duplicates the built-in Java stuff, etc. etc. It would be better just to have a better Java, not a hack on top.

<comment><USER3> I have been using Scala commercially for 3 years now. Never have I come across someone who didn't like it. Java veterans almost cry with joy after using Scala. I don't know if I live in a Scala bubble but I don't believe that's likely. And "Java will almost be Scala" nonsense never gets old it seems. It's as stupid as "Go is almost Haskell" (but they both have lambdas!!).

<comment><USER2> It's not "nonsense" or "stupid" to think that Java will adopt more Scala features over time.

You have to put Java in its historical context to understand how it came to be. It was a mid 1990s over-reaction against the super-complicated, super- fragile software that people were churning out with C++. It was designed as a kind of babytalk that would avoid the complexity of speaking C++. Of course we all know it was an over-reaction, leaving behind perfectly reasonable ideas like multiple return values, lambdas, and unsigned numbers in a kind of French Revolution against C++ silliness.

Scala is also an over-reaction in the other direction. It's like a cross between Perl and one of the more pragmatic ML dialects. It's easy to churn out a lot of Scala code, but hard to read someone else's or debug a Scala program. (Case in point: seeing <anonymous> for every stack frame in backtaces.) Eventually we will want to meet in the middle somewhere with regard to complexity, and Java is best positioned to do that.

<comment><USER4> Eventually we're all dead. I don't think Scala will be the best language to use in 10 or 20 years' time. I do think it's the best language to use today (and I won't be leaving it until I see an alternative with higher-kinded types, dependent types, strict evaluation, and project/dependency management as good as maven).

</comment></comment></comment></comment><comment><USER5> It should have [2014]. There are already three milestones out and updated schedule: [http://www.scala-lang.org/news/2016-schedule/](http://www.scala- lang.org/news/2016-schedule/)

<comment><USER6> Definitely.

Having said that, it makes it easier to see that the schedule has already slipped by months, even though it was announced two years ago.

</comment></comment><comment><USER7> The latest roadmap[0] has the last 2.11.x release coming out Q3 this year. That's far too early IMHO since the entire Android eco system is still stuck on Java 7. Android is slowly moving to Java 8 but there's no definite timeline on when that will be done.

[0] [http://scala-lang.org/news/2016-schedule/](http://scala- lang.org/news/2016-schedule/)

</comment><comment><USER8> There are plenty of Scala 2.12 roadmaps to choose from:

\- the original one (June 2014), linked from this article \- its Dec 2015 update [1] Of note is its prominent (Call for) Participation. Looks like the Typesafe team is feeling overstretched now. \- for those of us following the bug database, we're stuck with the outdated schedule [2] \- the GitHub counterpart to the above is [3] which seems more accurate: it updates the updated schedule eg by postponing by one month the release date for RC1 of 2.12.

So I've given up reading tea leaves from roadmaps and just wait for 2.12.0 when it becomes ready.

As to why that report in the (public) bug database is outdated, let's remember the mindset formulated in [https://twitter.com/adriaanm/status/571073842434547712](https://twitter.com/adriaanm/status/571073842434547712) (declaring JIRA bankruptcy) which wasn't put in practice. Quoting: @adriaanm our plan for Scala is to declare JIRA bankruptcy and run for the githubs. Maybe take the top half of the open issues with us.

[1] [http://www.scala-lang.org/news/2016-schedule/](http://www.scala- lang.org/news/2016-schedule/)

[2] [https://issues.scala- lang.org/projects/SI?selectedItem=com.a...](https://issues.scala- lang.org/projects/SI?selectedItem=com.atlassian.jira.jira-projects- plugin:release-page)

[3] [https://github.com/scala/scala/milestones](https://github.com/scala/scala/milestones)

</comment><comment><USER9> I, for one, welcome our Scala overlords.

</comment><comment><USER10> > Scala 2.12 will require Java 8.

Goodbye Android.

<comment><USER11> Won't Android move to Java 8+ once they officially adopt OpenJDK?

<comment><USER10> No idea.

They have included parts of OpenJDK 7, that is about it.

</comment></comment></comment><comment><USER12> Does Scala fix the null problem?

<comment><USER4> Yes, as best as can reasonably be managed while interoperating seamlessly with Java. null still exists but the community strongly discourages using it (and there's a compiler plugin that will make it a warning or an error). Standard library methods don't expect or return null (e.g. Map#get returns Option), and the ecosystem follows the same convention. Option is very widely used and supported in for/yield syntax; better still it's a normal type in the language that can be abstracted over by the usual mechanisms (e.g. scalaz defines a Monad typeclass for it, so generic methods like traverse will work for Option). When wrapping a Java library you have to use your own judgement to know whether a method can return null (it's either that or force you to check every java method call, which some languages do but makes interop awkward); best practice is to wrap any calls to a possibly-null method in Option(...) immediately so that the null never "escapes" into Scala-land.

Of late the scala-native ecosystem has grown to the point where you can largely avoid using Java libraries at all. I can't remember the last time I saw a null or a NullPointerException at my Scala job.</comment></comment>


Ask HN: Why no Cloud Storage Love apart from Dropbox and GDrive? - <AUTHOR>

Unless I am missing something. MediaFire currently offer of $2.5 / TB, even without the discount their $5 /TB is even cheaper then Google Drive.
I see no mention or news of it.
Similar thing happen to OVH Hubic, which is even cheaper at $13.5 / month for 10TB.
Why aren't these being used or talk about more often? Am i missing anything? <comment><USER2> A lot of the reason I use Dropbox is that other people do, so I can share files and folders with it easily. They made a big advertising push earlier, especially in colleges, and got my lab hooked.

Based on your recommendation I will look into MediaFire for home backups though. It is easily worth $5 per month.

</comment><comment><USER3> It goes to show price has very little to do with why people buy a service. Also, how sticky some of these services can be.

I pay Dropbox $99 per year for 100GB and have never thought about switching. It just works! It meets all my needs. I am not unhappy about anything to go look for alternatives.</comment>


Whence function notation? - <AUTHOR> http://blogs.law.harvard.edu/pamphlet/2015/09/28/whence-function-notation/ <comment><USER2> There is a certain pleasing _physicality_ to function notion, in the sense that empty parens make a circle into which you put things. () -> (1). Look, I put a 1 in there! f(x) is a notation that is strictly speaking only good for the author of f because they know how to access their independent data; any utility to the caller, by inferring what "x" should be, is purely conventional/accidental.

Function notion in this sense mirrors our counting system, which begins with an empty circle, 0, which we replace with a succession of symbols, until we hit 9, and then 10. It's interesting to imagine what "10" means if you're treating each symbol as a function. But this requires defining some sort of analog to "counting" with functions, which I'm not sure makes much sense in any general way. What is the "successor" to a function? It seems that we have a lot of options. One simple example would be to let f return a function based on an integer input, with the understanding that this is a simple function from 0-9 but then at 10 we return the composition of f_1 and f_0. In this way we describe the composition of 9 functions in any order using only a natural number.

Anyway, back to writing CRUD webapps.

<comment><USER3> > There is a certain pleasing physicality to function notion, in the sense > that empty parens make a circle into which you put things. () -> (1). Look, > I put a 1 in there!

This gets dropped as you go further in math, though. Take the function that reflects across the x,y plane, f(x,y,z) = (x,y,-z). Interpreting the notation your way, you'd want to write f((x,y,z)) = (x,y,-z), but that isn't done.

<comment><USER2> I didn't talk about how to implement (or represent) the body of the function! And besides, Church seemed to like single arguments, so actually he _would_ write something like that. :)

Physicists wouldn't (my degree is in physics).

Programmers would write f(x,y,z){return {x,y,-z};}. But actually, I would say that this is nasty because of asymmetry - it can't consume it's own output. f(p){return {p.x,p.y,-p.z}} where p = {x,y,z}

</comment></comment></comment><comment><USER4> Reminds me: is there a name for the _particular lexical operator_ "f(x)" of (what is apparently) Euler's notation, in the way that the syntactic operator "(f x)" is usually referred to as a reduction, and "f x" as a juxtaposition?

I'm aware that the _semantic meaning_ of "f(x)" in most languages is function application—but I want to know what term I should use when, say, talking about how I wish in Ruby you could do "f(x)" with Procs, but are stuck instead with "f[x]".

<comment><USER5> I don't think so. Mathematicians don't think of "f(x)" as evaluation or application, but as the value of the function f at x. The "at" is very important, because we generally deal with numerical functions that have well- defined geometric graphs, and even for other functions, we retain the graphical metaphors even if they may not apply anymore. We don't generally think of "f(x)" as a _computation_ is what I mean. We discuss functions all the time whose values we agree will exist but cannot be computed (for example, a choice function that we obtained via the axiom of choice).

We also don't generally pass functions around to other functions, and we don't care about syntax that much. After all, we are not computers, so we are quite comfortable changing syntax around according to habit and custom, even happily using ambiguous syntax when we think that our readers can figure out what we mean.

So, no. We don't have a common name for it because it's not an important distinction for us.

</comment></comment><comment><USER6> I always feel like `f(a)` invokes the idea that `f` is a value dependent on some `a` where notations like `(f a)` and `f a` are more indicative of the idea that `f` is a thing which has the operation of application to `a`.

This makes sense mathematically as it's taken a long time for people to come around to thinking of functions as things in their own right. Dependent quantities are a more historical notion to my understanding.

</comment><comment><USER7> As someone who has done a lot of work with ML and the lambda calculus, having to put parentheses around my arguments in most programming languages drives me crazy. It feels so heavyweight.

Function argument parens are particularly weird when dealing with curried arguments. `f x y z` is so much nicer than `f(x)(y)(z)`.

<comment><USER8> Naw. I hate using whitespace for function application. Having a binary operation that's neither associative nor parenthesized is super confusing to newbies.

       a+b+c = (a+b)+c = a+(b+c)  // Good!
       f a b = (f a) b != f (a b)  // WTF?

BTW, that's also a good rule of thumb for defining new operators. If your new op ~-^-~ is not associative, don't make it an op!! And even if it is, consider that users won't magically know the relative precedence of your op versus someone else's =^%^=. Looking at you, Haskell.

<comment><USER9> You provide:

       a+b+c = (a+b)+c = a+(b+c)  // Good!
       f a b = (f a) b != f (a b)  // WTF?

So, I suppose, also:

       a/b/c = (a/b)/c != a/(b/c) // WTF?

> BTW, that's also a good rule of thumb for defining new operators. If your > new op ~-^-~ is not associative, don't make it an op!!

Why should associativity be a requirement for a new op? Its not universal among common standard binary operators, after all (particularly division and exponentiation are not associative.)

<comment><USER8> I said either associative or parenthesized. People don't write a/b/c because they had 10 years of learning to use parens in arithmetic, but they write f a b all the time. For the same reason, my rule of thumb applies only to operators that you define.

The non-associativity of exponentiation does throw people off sometimes. Not all college students will correctly parse 2^2^2. IMO it's a wart in math notation. It could've been easily avoided by e.g. drawing a box around the exponent, so stacked exponentials would have boxes nesting upward.

</comment></comment></comment></comment><comment><USER5> In group theory exponential notation such as x^f (picture a superscript, like xf) or composing on the right (x)f are not altogether uncommon. It's particulary convenient for homomorphisms or the action of a group on a set. Some category theorists of the mathematical kind, not the computer science kind, (i.e the kind that cares most deeply about homological algebra) also like to compose on the right, so that you can write function composition in the order that you diagram-chase.

</comment><comment><USER10> I found some more background here[1]. It's not clear (to me, at least) whether Euler would have employed parentheses in that case if they hadn't been necessary to avoid ambiguity, i.e. if the argument had been x, he might have just written fx.

[1] [http://math.stackexchange.com/questions/636332/the-origin- of...](http://math.stackexchange.com/questions/636332/the-origin-of-the- function-fx-notation)</comment>


Investigating the Potential for Miscommunication Using Emoji - <AUTHOR> http://grouplens.org/blog/investigating-the-potential-for-miscommunication-using-emoji/ <comment><USER2> It seems like Apple's emojis are badly designed, and that should probably have been the conclusion.

<comment><USER3> Apple's initial implementation was designed to operate with SoftBank's Emoji format, and predates unicode standardisation. Their version of this icon can be seen here [http://image.slidesharecdn.com/iuc36emojifinal1-131204112121...](http://image.slidesharecdn.com/iuc36emojifinal1-131204112121-phpapp01/95/unicode- and-legacy-representations-of-emoji-iuc-36-11-638.jpg?cb=1386156321) and Apple's matches it pretty well. [Also note: this is where the Apple's smiley poop comes from too]

The main fault seems to be that the codepoints for those icons were explicitly mapped onto unicode's 'grinning face with smiling eyes', despite them not being representations of that.

The Unicode standard got 'grimacing face' a couple of years later, though, which better suits this expression. [Apple's version uses the same mouth as here, but with normal eyes]

</comment></comment><comment><USER4> My curiosity lead me to this chart of emoji on the different platforms here: [http://unicode.org/emoji/charts/full-emoji- list.html](http://unicode.org/emoji/charts/full-emoji-list.html)

This is why I stick to emoticons :)

<comment><USER5> Nice. It seems Twitter cribbed pretty strongly from Apple in their emoji, especially the facial expression ones.

</comment></comment><comment><USER6> I have a windows phone, and have regularly encountered this with my wife (who has an iPhone).

In particular :eggplant: doesn't have the same obvious meaning</comment>


Costs of Snowden leak still mounting 5 years later - <AUTHOR> https://apnews.com/797f390ee28b4bfbb0e1b13cfedf0593/Costs-of-Snowden-leak-still-mounting-5-years-later <comment><USER2> Do these costs come from the Snowden leak, the various behaviors it exposed, or some combination of both?</comment>