7 ms·

"Hard tech startups Some people think YC only funds software startups." Kinda strange that software is not seen by YC as "hard tech". I think there's lots of

by hoodoof 10y ago

"Hard tech startups Some people think YC only funds software startups." Kinda strange that software is not seen by YC as "hard tech". I think there's lots of hard tech in software but the way venture capitalists/angel investors tell it, you should only ever build software that can be made in a weekend and then iterated upon. The outcome of this is the X thousandth dog walking social network for uber drivers staying at AirBNB - i.e. stuff that you can build in a weekend and iterate on. And this is why demo days are full of such lightweight software applications - people are actively discouraged from taking the time to build something large scale and, well, "hard". Sometimes it makes sense to make a big bet on building some complex software that might take months or years to build, with lots of moving parts, but once complete solves a big problem. That is software that is "hard tech".

striking 10y ago
Edit: I'm awful at this reading thing. Please see the replies to this comment for a correct definition of "hard tech". My original comment follows. . I think "hard tech" in this instance means "technology in the form of hardware" or "technology that is physically manifest" and not "technology that is difficult."
- nhaliday 10y ago
  I think the latter is the intended meaning actually. AI/machine learning seem to be thrown into the "hard tech" bucket in VC jargon.
- tedmiston 10y ago
  There's a definition from Sam in the footnote: > [1] I use 'hard tech' to mean a startup is whether there is doubt that the technology can be built at all. Edit: I'm glad he defined it for this post. In general though, there's definitely ambiguity around the term.
- throwaway729 10y ago
  No. From the footnote: " I use ‘hard tech’ to mean a startup where there is doubt that the technology can be built at all."
- tjalex 10y ago
  From the footnote in the original post: [1] I use ‘hard tech’ to mean a startup where there is doubt that the technology can be built at all.
  - roymurdock 10y ago
    This conflicts with the way he uses the term "hard tech" to differentiate from software startups, as if the two are mutually exclusive: It’s relatively easy for a software startup to take short cycle times and low-costs to an extreme, but hard tech founders are often surprised by how effectively they can do this, too. What I think he is really referring to as "hard tech" is the move from the consumer electronics and office automation markets to the grittier, less-visible industrial verticals: Automotive, industrial, energy & utilities, aerospace & defense, etc. Verticals which have generally been dominated by a GE/Siemens/Boeing/ABB/Schneider etc. due to the high R&D costs needed to realize a certified, generally safety-critical solution in a highly bureaucratic environment. Dropbox is down for a few hours? We'll have a few pissed customers. The ADAS system in a customer's car failed momentarily? They'll be lucky to survive and massive lawsuits/loss of business could ensue. As an aside he should really define key terms up front to avoid this sort of confusion and to allow us to focus on his main point: YC is trying to move into and disrupt this lucrative but hard-to-broach space.
    - throwaway729 10y ago
      Exactly. I think that itself actually an interesting "hard tech" problem: how do you move fast, iterate, and be first-to-market without killing anyone?
      - mountaineer22 10y ago
        I don't think you do. You want to be number 2, and swoop in when the time is right.
      - haimez 10y ago
        You do not move fast and iterate if you care at all about the cost of failures. Period.
- hoodoof 10y ago
  The first line of the post explicitly makes a distinction between "software" and "hard tech". I really challenge the accepted wisdom of "build something tiny and iterate" as being the only way to build software.
  - paulryanrogers 10y ago
    Games can be really complex 'hard-tech', but compare Elite Dangerous's small+ iterative to Star Citizen's big+all-at-once approaches. Even with things like nuclear energy and particle colliders I'd guess those who succeeded probably started small and iterated.
  - tedmiston 10y ago
    Of course there are many approaches to build software [1]. I also read that comment as more of a philosophy for product development than software development. [1]: https://en.wikipedia.org/wiki/Software_development_process#Approaches https://en.wikipedia.org/wiki/Software_development_process#A...
hiou 10y ago
I have a hunch it is because many people, myself included, see a lot of software development getting replaced by generalized AI in the next 10 years.
- nostrademons 10y ago
  Building these AI systems is itself a form of hard software development. (I disagree on the premise, BTW. I saw a number of successful machine-learning systems at Google, and the most successful were always the ones that combined machine-learned functions - sometimes many of them - with traditional algorithms. AI is a tool that extends the reach of software into new problem domains, it's not going to replace software itself.)
- imtringued 10y ago
  What makes you think that we'll see generalized AI this soon? Is there some kind of progress beyond machine learning that I missed?
tlb 10y ago
It's always better to develop most of the software with real users using it. So although the goal may be huge, start by building a piece that does something in a month and get real users using it, so the rest of the project can proceed with a compass.
- hoodoof 10y ago
  "It's always better" - words like this make me think "unchallenged accepted wisdom". Accepted wisdom remains accepted until eventually people start to realize that it's not entirely correct.
  - zmitri 10y ago
    As someone who has gone through YC, I think a lot of the kind of absolute talk you are pointing out has to do with consistent messaging and providing general advice to an entire group of people who might not have the experience to understand for themselves what the best way to proceed is. Obviously in reality, things are a lot more nuanced than 'always', but when your goal is to help as many companies at once, where the degree of experience varies, it often help to simplify the problem. In one-on-one situations, the partners can give you more personalized insights and in general are quite insightful.
  - tlb 10y ago
    There is considerable experience with doing large software projects in one shot. Many corporate and government software projects are done, or at least used to be done, that way. Results were pretty bad. It's hard to be positive of causation, but correlation (long time to initial customer contact <=> software doesn't make customers happy) is pretty strong. If you want to challenge it, you could try to deliver a successful large multi-year software projects with no prior customer engagement, and document the process. People can then make informed comparisons against the accepted wisdom.
  - tedmiston 10y ago
    Sure, one counterpoint, or at least nuance, is when you give too much focus to the wrong users. Then wrong users can oversteer your product. For example, BigCo wants Feature X and will pay $100k/year for it, you add it but it complicates the experience for others and delays the rest of your roadmap. Another is knowing when your users are wrong, they request Feature Y, but really what they want is Benefit Z. Of course there's also nuance around how exactly you define minimum viable product (i.e., the part built before you start exposing it to users). I've seen experienced non-startup business people describe an entire app with every feature that they envision, then claim that's the MVP. It can be a hard model to adjust to.
AndrewKemendo 10y ago
As someone in the hard tech space I can tell you that it's not completely irrational on their part. When you look at exits and probabilities of exits, the types of software companies you describe make up the bulk. The biggest (by val) technology startups that we know of (Uber, Lyft, AirBnB, Snapchat, Dropbox, Pinterest) are by no means hard tech. Even the public ones aren't hard tech (Facebook, Linkedin, Twitter). So that's what these investors look to as the types of investments that make sense for them. The question is, do hard tech companies have similar probabilities of outcomes or bigger?
- purplelobster 10y ago
  I'd say Google was hard tech
  - Animats 10y ago
    Google was working, using Stanford resources, before it was funded. Low investor technical risk. Also, Google's founders had patent coverage of their idea.
    - deleted 10y ago
      [deleted]
- nostrademons 10y ago
  DropBox was hard-tech when it came out; they reverse engineered the Finder so that your DropBox folder would appear like a normal Mac folder. They may seem like a commodity now because everybody's doing stuff like that (and in many cases, APIs have appeared that make it trivial), but when they first launched, they did stuff most people assumed was impossible. Twitch/Justin.TV was also hard-tech when it came out, though now the hard parts are built into every iPhone. Other than that, I largely agree. The last software hard-tech company to strike it really big was Google. There've been a number of open-source projects doing what I'd consider hard-tech software, though - Bitcoin, git/Mercurial/Darcs, Bittorrent, TensorFlow, etc. (My definition of hard tech, as applied to software, is "Software where you need to use scientific-method trial-and-error to build core pieces of the product." If you can read an online tutorial or reference manual and build the product, it's not hard tech. If you need to poke around at things, observe the responses, and build your own model of how things work, it is.)
sAuronas 10y ago
My idea for a startup weekend was such a hard-tech/software problem that lost out to a couple of social weekend apps. While a lot of people got behind my idea and we put together a strong presentation, the lack of a finished app sank us. How do you compete with something launched on mobile in a weekend when your at power points and mocks?
- chillacy 10y ago
  The judging criteria for Startup Weekend is 3 parts: Business Model, Customer Validation, Execution: http://www.techstars.com/content/community/startup-weekend-judging-criteria/ http://www.techstars.com/content/community/startup-weekend-j... If your mocks were sufficient for gathering user feedback, that may be okay. I've certainly seen groups with no written software place in the top 3, off of designer mocks alone.
  - tedmiston 10y ago
    Another point on judging criteria is that it varies widely based on who your judges are too. Those categories are pretty broad with plenty of room for interpretation intentionally. If the judging panel is less technical, you'll have to sell your idea differently. I've seen cool tech hackathon projects fail because of bad presentations, either because they're ineffective or they just didn't practice. It's kind of less than ideal that you're judged for the whole weekend based on how well you can sell in a 2-minute pitch, but then again it's not all that different from the real startup world.
- sAuronas 10y ago
  Edit: I guess with the premise being "startup [in a] weekend", I shouldn't have expected my idea to win even with the team I picked up. Perhaps a startup month would work?
- tedmiston 10y ago
  I've been an organizer of several hackathons and participated in Startup Weekend. The judging guidelines vary across organizers, theme, and city. In general, Startup Weekend events focus on business model generation and customer validation, with building an actual product following. And remember, it's a weekend: the "winners" typically don't turn the project into an actual startup. I think of like in school, you can learn because you want to know things or you can learn to the test because you want the mark to move on. Would you rather build something hard or build something more likely to win? From my experience, it's not the same apps that do both. I also don't think one approach is necessarily better than the other, just personal preference, plus also depends on the team dynamic you end up with. For example, I wouldn't try to solve a hard tech problem on a team with mostly non-tech people because their expectations can be unrealistic. But if my team is 3 experienced startup engineers that can iterate, well why the hell not?
yvsong 10y ago
Software have a poor image due to lack of perfectionists in the software industry. Buggy software are happily released. Correct software are very hard to build. I wonder how many have ever existed.
- cloudjacker 10y ago
  buggy software makes money perfectionists don't
  - mountaineer22 10y ago
    This should be a plaque somewhere.
    - TeMPOraL 10y ago
      So that it could be pointed to people who start wondering why almost everything in software industry is utter garbage built upon a pile of shit. Yay, business interests.
      - mojuba 10y ago
        One of the consequences of that being tons of cheap disposable software jobs everywhere, crappy recruitment process, good engineers literally drowning in the sea of the above.
  - nercht12 10y ago
    No kidding. Just ask the Japanese - They were known for going through their software with a fine-tooth comb before releasing, but they started to realize how far behind the Americans they were (and arguably still are).
  - mojuba 10y ago
    Buggy (and bloated by extension) software never has my money at least. I never trust, for example, my battery life and my mobile traffic to software houses that are not exactly perfectionist. Perfectionism should become a skill, not just a characteristic.
nbadg 10y ago
I agree wholeheartedly. I think that treating software as dichotomous with "hard tech" (instead of orthogonal) is a profound mistake that really proliferates, not just through VCs, not just through the industry, but through our entire culture. So, so many (especially older) hardware guys I know don't see software as a real field, and I think this is a big part of the reason why. And much of the discussion about technical debt, about "the web toolchain sucks", or "operating systems suck", or X, Y, Z, they all suck... so often, I think that's just a different way of saying "we have this really hard problem, and we've spent decades piling really innovative partial solutions to it on top of other really innovative partial solutions, but nobody has come along with something that really, really works." And it's a tremendous problem. The response I've seen in the past is, "We love those ideas, they're just more appropriate for, say, YC research." But for hardware, the bar is automatically different: it's understood that there must be some degree of longer-term research and development that goes into a product. And I think that's completely untrue: both require experimentation, both require feedback, both require upfront work to get right. And to be honest, this misunderstanding probably stands at the core of the strongest arguments I've ever heard against the maturity of the software industry.
goatherders 10y ago
Hard = hardware, physical. Not "difficult"
- jasonlotito 10y ago
  FTA: "I use ‘hard tech’ to mean a startup where there is doubt that the technology can be built at all."
the_watcher 10y ago
I read it as tech that is hard to build because of barriers to entry and an assumption that there isn't a good way to iterate rapidly.
sama 10y ago
There are plenty of hard tech software startups. But I see how unclear this is; fixing now. Thanks.
amelius 10y ago
> Kinda strange that software is not seen by YC as "hard tech". Could the reason be that pure software patents have a weaker status than hardware patents and/or are more difficult to enforce?
deleted 10y ago
[deleted]
vmarsy 10y ago
The quote you put isn't what is said on the blog post. I assume they edited it after your comment, Thanks! Adding that straightforward adjective removes the ambiguity. > I use ‘hard tech’ to mean a startup where there is doubt that the technology can be built at all. > Some people think YC only funds straightforward software startups.
- hoodoof 10y ago
  Yes the original post has been edited.
jdoliner 10y ago
I too found it a bit strange that the list didn't include software, or at least some specific types of software. I can assure you though that YC does invest in this and doesn't exclusively look for software that can be built in a weekend. My startup, Pachyderm [0], is a pretty good example of this that they funded in W15. A ton of other hard tech software startups have come out of YC including: Docker, CoreOS, Memsql and RethinkDB. In general I think it's one of their more successful verticals, although probably not quite as successful as consumer software. In general I think you are right that VCs have the bias you're talking about though. Not all VCs but many. It's not totally irrational, software that can be built in a weekend has fewer risks associated with it and can have just as much upside. However there are many very problems that are worth solving and can only be solved with complicated, hard tech, software. Investors with this bias cut themselves off from this opportunity. [0] https://www.pachyderm.io https://www.pachyderm.io
deepGem 10y ago
Sometimes it makes sense to make a big bet on building some complex software that might take months or years to build, with lots of moving parts, but once complete solves a big problem. That is software that is "hard tech". If and only if, a market for such a software still exists and continues to grow when you deliver the product.

by hoodoof 10y ago

striking 10y ago

Edit: I'm awful at this reading thing. Please see the replies to this comment for a correct definition of "hard tech". My original comment follows. . I think "hard tech" in this instance means "technology in the form of hardware" or "technology that is physically manifest" and not "technology that is difficult."

nhaliday 10y ago
I think the latter is the intended meaning actually. AI/machine learning seem to be thrown into the "hard tech" bucket in VC jargon.
tedmiston 10y ago
There's a definition from Sam in the footnote: > [1] I use 'hard tech' to mean a startup is whether there is doubt that the technology can be built at all. Edit: I'm glad he defined it for this post. In general though, there's definitely ambiguity around the term.
throwaway729 10y ago
No. From the footnote: " I use ‘hard tech’ to mean a startup where there is doubt that the technology can be built at all."
tjalex 10y ago
From the footnote in the original post: [1] I use ‘hard tech’ to mean a startup where there is doubt that the technology can be built at all.
- roymurdock 10y ago
  This conflicts with the way he uses the term "hard tech" to differentiate from software startups, as if the two are mutually exclusive: It’s relatively easy for a software startup to take short cycle times and low-costs to an extreme, but hard tech founders are often surprised by how effectively they can do this, too. What I think he is really referring to as "hard tech" is the move from the consumer electronics and office automation markets to the grittier, less-visible industrial verticals: Automotive, industrial, energy & utilities, aerospace & defense, etc. Verticals which have generally been dominated by a GE/Siemens/Boeing/ABB/Schneider etc. due to the high R&D costs needed to realize a certified, generally safety-critical solution in a highly bureaucratic environment. Dropbox is down for a few hours? We'll have a few pissed customers. The ADAS system in a customer's car failed momentarily? They'll be lucky to survive and massive lawsuits/loss of business could ensue. As an aside he should really define key terms up front to avoid this sort of confusion and to allow us to focus on his main point: YC is trying to move into and disrupt this lucrative but hard-to-broach space.
  - throwaway729 10y ago
    Exactly. I think that itself actually an interesting "hard tech" problem: how do you move fast, iterate, and be first-to-market without killing anyone?
    - mountaineer22 10y ago
      I don't think you do. You want to be number 2, and swoop in when the time is right.
    - haimez 10y ago
      You do not move fast and iterate if you care at all about the cost of failures. Period.
hoodoof 10y ago
The first line of the post explicitly makes a distinction between "software" and "hard tech". I really challenge the accepted wisdom of "build something tiny and iterate" as being the only way to build software.
- paulryanrogers 10y ago
  Games can be really complex 'hard-tech', but compare Elite Dangerous's small+ iterative to Star Citizen's big+all-at-once approaches. Even with things like nuclear energy and particle colliders I'd guess those who succeeded probably started small and iterated.
- tedmiston 10y ago
  Of course there are many approaches to build software [1]. I also read that comment as more of a philosophy for product development than software development. [1]: https://en.wikipedia.org/wiki/Software_development_process#Approaches https://en.wikipedia.org/wiki/Software_development_process#A...

hiou 10y ago

I have a hunch it is because many people, myself included, see a lot of software development getting replaced by generalized AI in the next 10 years.

nostrademons 10y ago
Building these AI systems is itself a form of hard software development. (I disagree on the premise, BTW. I saw a number of successful machine-learning systems at Google, and the most successful were always the ones that combined machine-learned functions - sometimes many of them - with traditional algorithms. AI is a tool that extends the reach of software into new problem domains, it's not going to replace software itself.)
imtringued 10y ago
What makes you think that we'll see generalized AI this soon? Is there some kind of progress beyond machine learning that I missed?

tlb 10y ago

It's always better to develop most of the software with real users using it. So although the goal may be huge, start by building a piece that does something in a month and get real users using it, so the rest of the project can proceed with a compass.

hoodoof 10y ago
"It's always better" - words like this make me think "unchallenged accepted wisdom". Accepted wisdom remains accepted until eventually people start to realize that it's not entirely correct.
- zmitri 10y ago
  As someone who has gone through YC, I think a lot of the kind of absolute talk you are pointing out has to do with consistent messaging and providing general advice to an entire group of people who might not have the experience to understand for themselves what the best way to proceed is. Obviously in reality, things are a lot more nuanced than 'always', but when your goal is to help as many companies at once, where the degree of experience varies, it often help to simplify the problem. In one-on-one situations, the partners can give you more personalized insights and in general are quite insightful.
- tlb 10y ago
  There is considerable experience with doing large software projects in one shot. Many corporate and government software projects are done, or at least used to be done, that way. Results were pretty bad. It's hard to be positive of causation, but correlation (long time to initial customer contact <=> software doesn't make customers happy) is pretty strong. If you want to challenge it, you could try to deliver a successful large multi-year software projects with no prior customer engagement, and document the process. People can then make informed comparisons against the accepted wisdom.
- tedmiston 10y ago
  Sure, one counterpoint, or at least nuance, is when you give too much focus to the wrong users. Then wrong users can oversteer your product. For example, BigCo wants Feature X and will pay $100k/year for it, you add it but it complicates the experience for others and delays the rest of your roadmap. Another is knowing when your users are wrong, they request Feature Y, but really what they want is Benefit Z. Of course there's also nuance around how exactly you define minimum viable product (i.e., the part built before you start exposing it to users). I've seen experienced non-startup business people describe an entire app with every feature that they envision, then claim that's the MVP. It can be a hard model to adjust to.

AndrewKemendo 10y ago

As someone in the hard tech space I can tell you that it's not completely irrational on their part. When you look at exits and probabilities of exits, the types of software companies you describe make up the bulk. The biggest (by val) technology startups that we know of (Uber, Lyft, AirBnB, Snapchat, Dropbox, Pinterest) are by no means hard tech. Even the public ones aren't hard tech (Facebook, Linkedin, Twitter). So that's what these investors look to as the types of investments that make sense for them. The question is, do hard tech companies have similar probabilities of outcomes or bigger?

purplelobster 10y ago
I'd say Google was hard tech
- Animats 10y ago
  Google was working, using Stanford resources, before it was funded. Low investor technical risk. Also, Google's founders had patent coverage of their idea.
  - deleted 10y ago
    [deleted]
nostrademons 10y ago
DropBox was hard-tech when it came out; they reverse engineered the Finder so that your DropBox folder would appear like a normal Mac folder. They may seem like a commodity now because everybody's doing stuff like that (and in many cases, APIs have appeared that make it trivial), but when they first launched, they did stuff most people assumed was impossible. Twitch/Justin.TV was also hard-tech when it came out, though now the hard parts are built into every iPhone. Other than that, I largely agree. The last software hard-tech company to strike it really big was Google. There've been a number of open-source projects doing what I'd consider hard-tech software, though - Bitcoin, git/Mercurial/Darcs, Bittorrent, TensorFlow, etc. (My definition of hard tech, as applied to software, is "Software where you need to use scientific-method trial-and-error to build core pieces of the product." If you can read an online tutorial or reference manual and build the product, it's not hard tech. If you need to poke around at things, observe the responses, and build your own model of how things work, it is.)

sAuronas 10y ago

My idea for a startup weekend was such a hard-tech/software problem that lost out to a couple of social weekend apps. While a lot of people got behind my idea and we put together a strong presentation, the lack of a finished app sank us. How do you compete with something launched on mobile in a weekend when your at power points and mocks?

chillacy 10y ago
The judging criteria for Startup Weekend is 3 parts: Business Model, Customer Validation, Execution: http://www.techstars.com/content/community/startup-weekend-judging-criteria/ http://www.techstars.com/content/community/startup-weekend-j... If your mocks were sufficient for gathering user feedback, that may be okay. I've certainly seen groups with no written software place in the top 3, off of designer mocks alone.
- tedmiston 10y ago
  Another point on judging criteria is that it varies widely based on who your judges are too. Those categories are pretty broad with plenty of room for interpretation intentionally. If the judging panel is less technical, you'll have to sell your idea differently. I've seen cool tech hackathon projects fail because of bad presentations, either because they're ineffective or they just didn't practice. It's kind of less than ideal that you're judged for the whole weekend based on how well you can sell in a 2-minute pitch, but then again it's not all that different from the real startup world.
sAuronas 10y ago
Edit: I guess with the premise being "startup [in a] weekend", I shouldn't have expected my idea to win even with the team I picked up. Perhaps a startup month would work?
tedmiston 10y ago
I've been an organizer of several hackathons and participated in Startup Weekend. The judging guidelines vary across organizers, theme, and city. In general, Startup Weekend events focus on business model generation and customer validation, with building an actual product following. And remember, it's a weekend: the "winners" typically don't turn the project into an actual startup. I think of like in school, you can learn because you want to know things or you can learn to the test because you want the mark to move on. Would you rather build something hard or build something more likely to win? From my experience, it's not the same apps that do both. I also don't think one approach is necessarily better than the other, just personal preference, plus also depends on the team dynamic you end up with. For example, I wouldn't try to solve a hard tech problem on a team with mostly non-tech people because their expectations can be unrealistic. But if my team is 3 experienced startup engineers that can iterate, well why the hell not?

yvsong 10y ago

Software have a poor image due to lack of perfectionists in the software industry. Buggy software are happily released. Correct software are very hard to build. I wonder how many have ever existed.

cloudjacker 10y ago
buggy software makes money perfectionists don't
- mountaineer22 10y ago
  This should be a plaque somewhere.
  - TeMPOraL 10y ago
    So that it could be pointed to people who start wondering why almost everything in software industry is utter garbage built upon a pile of shit. Yay, business interests.
    - mojuba 10y ago
      One of the consequences of that being tons of cheap disposable software jobs everywhere, crappy recruitment process, good engineers literally drowning in the sea of the above.
- nercht12 10y ago
  No kidding. Just ask the Japanese - They were known for going through their software with a fine-tooth comb before releasing, but they started to realize how far behind the Americans they were (and arguably still are).
- mojuba 10y ago
  Buggy (and bloated by extension) software never has my money at least. I never trust, for example, my battery life and my mobile traffic to software houses that are not exactly perfectionist. Perfectionism should become a skill, not just a characteristic.

nbadg 10y ago

I agree wholeheartedly. I think that treating software as dichotomous with "hard tech" (instead of orthogonal) is a profound mistake that really proliferates, not just through VCs, not just through the industry, but through our entire culture. So, so many (especially older) hardware guys I know don't see software as a real field, and I think this is a big part of the reason why. And much of the discussion about technical debt, about "the web toolchain sucks", or "operating systems suck", or X, Y, Z, they all suck... so often, I think that's just a different way of saying "we have this really hard problem, and we've spent decades piling really innovative partial solutions to it on top of other really innovative partial solutions, but nobody has come along with something that really, really works." And it's a tremendous problem. The response I've seen in the past is, "We love those ideas, they're just more appropriate for, say, YC research." But for hardware, the bar is automatically different: it's understood that there must be some degree of longer-term research and development that goes into a product. And I think that's completely untrue: both require experimentation, both require feedback, both require upfront work to get right. And to be honest, this misunderstanding probably stands at the core of the strongest arguments I've ever heard against the maturity of the software industry.

goatherders 10y ago

Hard = hardware, physical. Not "difficult"

jasonlotito 10y ago
FTA: "I use ‘hard tech’ to mean a startup where there is doubt that the technology can be built at all."

the_watcher 10y ago

I read it as tech that is hard to build because of barriers to entry and an assumption that there isn't a good way to iterate rapidly.

sama 10y ago

There are plenty of hard tech software startups. But I see how unclear this is; fixing now. Thanks.

amelius 10y ago

> Kinda strange that software is not seen by YC as "hard tech". Could the reason be that pure software patents have a weaker status than hardware patents and/or are more difficult to enforce?

deleted 10y ago

[deleted]

vmarsy 10y ago

The quote you put isn't what is said on the blog post. I assume they edited it after your comment, Thanks! Adding that straightforward adjective removes the ambiguity. > I use ‘hard tech’ to mean a startup where there is doubt that the technology can be built at all. > Some people think YC only funds straightforward software startups.

hoodoof 10y ago
Yes the original post has been edited.

jdoliner 10y ago

I too found it a bit strange that the list didn't include software, or at least some specific types of software. I can assure you though that YC does invest in this and doesn't exclusively look for software that can be built in a weekend. My startup, Pachyderm [0], is a pretty good example of this that they funded in W15. A ton of other hard tech software startups have come out of YC including: Docker, CoreOS, Memsql and RethinkDB. In general I think it's one of their more successful verticals, although probably not quite as successful as consumer software. In general I think you are right that VCs have the bias you're talking about though. Not all VCs but many. It's not totally irrational, software that can be built in a weekend has fewer risks associated with it and can have just as much upside. However there are many very problems that are worth solving and can only be solved with complicated, hard tech, software. Investors with this bias cut themselves off from this opportunity. [0] https://www.pachyderm.io https://www.pachyderm.io

deepGem 10y ago

Sometimes it makes sense to make a big bet on building some complex software that might take months or years to build, with lots of moving parts, but once complete solves a big problem. That is software that is "hard tech". If and only if, a market for such a software still exists and continues to grow when you deliver the product.