Startup Technical Diligence Is a Waste of Time - <AUTHOR> http://codingvc.com/why-startup-technical-diligence-is-a-waste-of-time/ <comment><USER2> I do technical diligence for a living so I feel like I should chime in.

1\. Many of my clients are unsophisticated when it comes to technology, regardless of whether they buy a "tech company" or not. Yes this includes both PE and VC clients. When a PE firm makes an investment in a tech company (and take 51+% of the company) they need to be confident the technology will hold up. About 90% of my work is PE, with the other being 10% in VC (mostly Series A +). Believe it or not, many commercially successful companies do not always use "today's world of SaaS tools, APIs, and cloud infrastructure". And even if they do, just because you use AWS doesn't mean you've setup a VPC correctly, you have multi-az setup, or sensitive data isn't encrypted at rest. These can have potentially costly (i.e. lose customers / brand recognition) consequences. (case in point -> [https://news.ycombinator.com/item?id=11999712](https://news.ycombinator.com/item?id=11999712) )

2\. If you're a VC, and especially an early stage one, then no, due diligence isn't necessary. At all in fact (including finance, etc). You're thesis isn't aligned with careful analysis, it's spray and pray, so diligence isn't a worthwhile endeavor. I wonder if something prompted the author to write this or if it's just a random rambling. I thought it was pretty well understood that doing diligence at the angel/seed stage was almost unanimously worthless.

3\. Tech due diligence at the later stage of VC, if done right, has more to do about scalability of operations and processes then it does about the specific tech. When you put $50M into a company, spending $50k is a pretty good safeguard.

4\. Tech diligence, by the right partner, could have certainly identified risks at Theranos or uBeam (assuming there are some there), but that's precisely what it is - risk. I'm pretty confident the investors in these companies understand the risk, they simply just don't care, because the potential outcome will return their whole fund and some. Do this 10 times and one bet is bound to pay off.

5\. I always try to remind entrepreneurs, VCs are finance professionals, not tech professionals. While some may have made their way into VC because of their previous technical ability, there are also many who do not. And just like when you stop coding for 6 months and get "rusty", so do previously technical able VCs who get older and out of touch.

<comment><USER3> I would hardly consider "spray and pray" to be a "professional" approach to investing, although this aligns perfectly with my experience with many VC firms. The key skill there is sales ability with the types of investor that also allocate large amounts of other people's capital on the basis of gut feels and lunches at expensive eateries.

<comment><USER2> Ok, I'll be more diplomatic - not spray and pray, but a "portfolio approach".

<comment><USER4> Hah.

I think you're off a bit though. There is a place for diligence at early VC stage, but it is almost entirely about the people.

<comment><USER2> That's not necessarily a technology due diligence then...

<comment><USER4> Fair, it's more of a technical (and other) competence DD

</comment></comment></comment></comment></comment></comment><comment><USER5> _A quick skim of CB Insights ' collection of 150+ startup post-mortems reveals that only ~5% of post-mortems referenced a lack of technical ability/execution. Most startup failures were caused by building the wrong product, or lacking sales skills, or not having a viable business model. The strong presence or absence of amazing engineers was rarely a factor._

"Our biggest obstacle to growth, right now? We still can't seem to attract candidates with strong CS fundamentals. Maybe we should crank up HackerRank hazing process from 3 hour-long sessions, up to 5. Because I mean, just look around -- aren't _we_ amazing? At this critical juncture for our venture, surely we can't afford to dilute our crack team with mediocre talent."

<comment><USER6> I think that the fact that these are post-mortems (e.g., dead startups) skews things a little. Could be that the founders weren't technical enough to deliver something interesting, which then caused the issues of wrong product (e.g., there was a technologically more challenging solution that would have made sense as a product), being unable to sell the product (e.g, you're peddling crap, and you know it), and not having a viable business model (e.g., noone actually cares enough about what you build to pay you for it).

That is total speculation though.

Here's how we're looking at what we're doing though. It's viable with a fairly low tech approach, and that's a good start. But we can use technology to take something that "works" and turn it into something that purrs.

It's like the phone switching terminals of old. You'd have an operator and you'd tell them who you want to speak to, and they'd plug the right wires in. It "works". Bell made money on that. They had the right product, strong sales people, and they had a business model. But to think even for a second that they could compete with that nowadays?

There's some irony that VCs investing in the industry that owes its life to computing and telecommunications are saying "Eh, the technology you're using doesn't matter".

But I do think that technology isn't the bottom layer of Maslov's hierarchy of startups. The existence of a market need is at the bottom, then whether your product is able to address this need, then whether you're able to reach that market, then whether you can get paid for doing so.

These layers are filters. It's not surprising that most startups fail on the ones that come first. That doesn't mean if you're shooting to be Uber, or Dropbox, or Facebook, or Google, that you tech doesn't need to be on point. And the best point to start using sane tech practices is, well, as early as possible, preferably once you've validated your other assumptions.

<comment><AUTHOR> (I'm the author of the post.)

There's definitely some sampling bias from the post-mortem article. Alas, this is the the most relevant public data that I could find. I do have a good (anecdotal) first-hand dataset: I've worked closely with about 50 portfolio companies at this point, and I've tracked a few dozen more that my fund didn't invest in. Maybe 5 out of the 50 had real technical risk, and 2 or 3 struggled and/or failed due to technical issues. For the remaining companies, the challenges have always been market-related, hiring-related, funding-related, and so on.

<comment><USER7> You are really missing the point of due diligence...

"Homeowners' insurance is a waste of money. 99% of the time your house doesn't burn down!"

You don't buy insurance because you expect your house to burn down. Similarly, you don't perform due diligence because you expect to find something. You do it to catch those rare 1 out of 20 events where something is f*cked up.

<comment><AUTHOR> It's a little different in Venture Capital because exits follow power laws. So the big mistakes are literally the opposite of insurance: it's okay to make a lot of losing investments as long as you don't miss Airbnb. Missing out on Airbnb because you got stuck on it being 3 designers and no engineers is way worse than investing in Airbnb and 49 companies that go bankrupt.

<comment><USER7> Perhaps you do not use the term "due diligence" the same way that it's used in the investment management industry, which to be clear, includes "Venture Capital."

"Due diligence" does not mean making a judgment call on whether three designers can build, scale, and operate a tech company. Due diligence means diving into the details of a company you are going to fund and checking, among other things, that the things they've said are valid and that there are no skeletons in the closet.

Don't get me wrong: due diligence sucks for all parties involved. If you are investing your own money, you have the right to do as little work as you want and skip it, but when you are entrusted as a fiduciary of someone else's capital -- and paid for the job -- it comes with responsibility.

<comment><AUTHOR> There are other factors, like Time, that influence the diligence process for (seed stage) venture capital. Investments are made at a fast cadence, which is good for founders and for investors. A seed fund might see 1000 companies in a year and invest in 10. That allows for a few hours spent on each company, but not much more than that. Similarly, a founder might meet with 50 or 100 investors before closing their round. 1-2 hours per investor will take a few months, but if investors spent too much time on diligence then a founder could spend all year just answering investors' questions. That would be like a twisted variant of the Uncertainty Principle, where just going through fundraising process basically dooms a company to fail because of the time required.

Given that time is a factor and given that I have 2-4 hours to spend with the companies I'm most interested in before making a final investment decision, I've gotten the most value out of spending 95% of that time on non-tech diligence. YMMV.

<comment><USER6> That does make sense. Investor & Founder time is limited, technical due diligence on the investor side takes too much time.

I'm coming more from a founder perspective though, and I think there's some dangers with the mindset as a founder, and I see it with a lot of people in the chinese startup community.

Whilst as an investor, one might get to play a bit fast and loose with technology choices, I believe that as a founder doing so is suicidal. I see startups here struggling to hire PHP programmers because they made the decision to go with PHP because they heard it was easy, and later on realized that that may have been a mistake. They try to smooth it over with funding later. PHP programmers over here have the same reputation. They learn it because they thought it was easy, and that there's a lot of companies desperate for that skill. It's a match made in hell.

Similar boneheaded decisions, preventable with a week of due dilligence reading, are made by founders here all the time. One thing I found interesting is that the people making these kinds of calls are always working on C-list ideas. It's always derivative businesses in markets that just don't care. They need to get their MVP out fast and half baked because what they're working on should have died on the drawing board. They're desperate for investor money because they think it will patch over major errors they've made up to that point.

Some of these ideas are salvageable. It usually requires restructuring on both the business side and the technology side, preferably to the point where they make sense as an integrated system. One guy I was working with, his startup is trying to create a site for farmers and rural Chinese to sell things on that, and that is so interesting, Alibaba jumped into the ring recently. Now he has a dinky site that does not solve anyone's problems. It's a website, which is greatly hindered by the fact that most villages have a single computer, and the people who wanted to trade with each other would sit at that computer, together.

I suggested to him that he change things up a little. Small farmers do suffer from information asymmetry with the people they're selling to. Technology wise, most of them have non-smart phones, but China Unicom is rolling out mobile coverage to rural China, because that's their market tomorrow. So, provide informational and automated brokering services over a website on the buyer end, and an SMS gateway on the seller end. Ship the FAQ on actual paper. Allow farmers to post their wares with a formatted text message, have offers coming in an hour later, goods shipped the day after. Give them a reason to upgrade to smartphones, pack in more features on the app once data becomes cheap. Do agricultural futures 5 years down the line, in one of the hungriest economies in the world.

The part where technology makes this interesting is that it allows you to reach a market segment that is unreachable over conventional means. Innovation is the edge startups have over large, well funded enterprises. Founders ignoring that side are blindsiding themselves to half their business.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> (I'm the post's author.)

Just to clarify a little bit, since I didn't make this explicitly clear in the article: there are certainly questions about the technical side that are useful.

One example from the blog post is trying to understand if the tech team's experience lines up with what they're building. If the founders are 2 infrastructure engineers who are trying to build a social app, or if they're mobile devs who are trying to build a streaming database, then that's a yellow or red flag.

Another example: I've gotten a lot of value out of drilling in a tiny bit when people make bold technology claims. If someone says they've developed cutting edge ML, they rarely expect an investor to ask about it. When I ask them what "cutting edge" means, if I hear words like linear regression or decision trees, then my bullshit detector goes off -- but not for technical reasons. It's not bad at all to use simple ML models, what is bad is misrepresenting your tech, because then I start wondering what else you're misrepresenting.

But for most (seed) VCs that I've met, technical diligence means asking an engineer they're friends with to talk to a CTO they're thinking of investing in. The engineer asks about system design, infrastructure decisions, deployment environment, coding practices, etc. and then tells the VC if they think the tech stack is robust. (VC: "Ah, they're using AWS and Redshift? That sounds modern. Thumbs up!") For many, many startups (SaaS, mobile apps, ecommerce, etc.) I think this type of diligence is basically useless for almost all seed stage companies.

<comment><USER8> Yes - there are many RED FLAGS. One is they skip all the hard parts(Tech Diligence), like security and and are all ready selling to the public.

</comment></comment><comment><USER9> > For >95% of startups, however, technical diligence is a waste of time for a > more fundamental reason: in today's world of SaaS tools, APIs, and cloud > infrastructure, most startup ideas don't have significant technical risk. > That means technical resources are rarely the cause of success or the reason > for failure.

While it's a tough pill to swallow for many engineers, there's a lot of truth in it.

The company I work for (Bored Panda) is a pretty good example of it. I was the first full time engineer, and the company already had 20+ millions of monthly visitors and ~2m facebook followers. Surely, there was tons of technical debt to clean up and uptime was... really poor :)

<comment><USER10> > From Google description, "Bored Panda is a leading art, design and > photography community for creative people. Our submission platform helps > artists and creators turn their stories into."

into what? :-)

<comment><USER11> That's called semantic debt

<comment><USER12> LOL. I will be on the lookout for this now, and I fully expect to see it _everywhere_.

</comment></comment></comment></comment><comment><USER13> How to run a startup in 2016:

* No homebrewed tech allowed. It's too "complex"

* We should only use off-the-shelf libraries and SDKs because bar-to-entry isn't a real investor risk ("Just trust me, I'm a charismatic CEO who played golf a few times with the best friend of the college roommate of the guy who helped the guy close Series A for Baidu")

* Soft skills, soft skills, soft skills! Smiling > coding

* I don't know what technical debt is, but I'm sure we can safely rewrite our core product from scratch in between Series B and Series C. Product owners, customer support teams, and quality assurance re-on-boarding is a money problem, not a leadership problem.

* Security audits? I have no idea what those are, but lets incorporate IoT into our product suite somehow. That seems hot right now to VCs.

Bubbles. Bubbles everywhere.

<comment><USER14> Re: No homebrewed tech

Yeah the gig I had got taken over by some guys who said "Why are you doing all that yourself? You can get off-the-shelf stuff for free!" Literally the first words out of my mouth were "We didn't write our own code because we were not _smart enough_ to use open solutions. We had product and performance requirements that could not be met." They gave lip-service to me for some months before letting me go. A year later they still are an order of magnitude below our previous performance/quality/feature levels.

<comment><USER15> Developers should definitely write their own code when there isn't an open solution that they can leverage to solve the problem, but those situations are quite uncommon for the majority of startups. Most founders aren't doing the sort of cutting-edge development that no one has seen before; they're making a SaaS app that boils down to a few CRUD forms in a browser and some nice design[1]. Building a business around that is much, much easier and cheaper if you write less of your own code.

Use open solutions where you can, and don't use them where you can't.

[1] That is in no way denigrating startups that do that. If you can solve people's problems by making a better form then that is a Good Thing.

<comment><USER16> > Most founders aren't doing the sort of cutting-edge development that no one > has seen before; they're making a SaaS app that boils down to a few CRUD > forms in a browser and some nice design

They should probably ask themselves what sort of defensible competitive advantage they're building, though.

With many founders I know, the answer is "none". This is probably necessary in the very early seed stage - it's hard to build something unique and difficult and still get to market - but it's disturbing how many companies end up with $50M in funding and the answer is still "none". Probably a good indicator of a shake-out in the SaaS world in the near future.

<comment><USER15> The competitive advantage those companies have is typically two-fold: knowledge and brand.

Knowledge is the very detailed and insightful understanding of what their industry needs at the moment, and where it needs to move to in the longer term. Founders who build those businesses are typically experienced in their industry and are solving a pain they've seen firsthand. That is _exceptionally_ hard to compete with if they're good. Just because that knowledge can be codified in a 'simple' CRUD app doesn't make it any less valuable.

The brand advantage is comes from being the first mover. If the industry knows your company, trusts that you've proven to have an impact on their bottom line (or their competitors bottom line), then you're probably in a good position to retain customers and build a market. Competition is not a problem for a business that's intent on making a market $100m bigger rather than trying to take $100m of business from someone else.

Neither of those advantages require any code.

</comment></comment></comment></comment></comment><comment><USER17> While intensive technical due diligence at the seed stage is rare (for the good reasons cited in the note), I wouldn't make a unilateral assertion that it's a waste of time.

Some startups ARE technology driven (I bet the Theranos investors wished they did more tech diligence).

I find a light / informal discussion about technology to be really helpful. What's been built gives a sense of the real (vs stated) tech skills on the founding team (we all tend to reach for what's most familiar). For example, if the first version is built on the Microsoft stack, you might want to know that.

Finally, code meant to be thrown away always hangs around longer than expected.

<comment><USER18> "Some startups ARE technology driven (I bet the Theranos investors wished they did more tech diligence)."

The article specifically addresses this:

"There are, of course, some companies with real technical risk: SpaceX, Zoox, Rigetti Quantum Computing, etc. But for a typical consumer app or SaaS tool, technical risk is low enough to be ignored."

And of course it never hurts to ask a few questions - you can quickly find out if the technical team is on-the-level without examining their entire commit history (and as he suggests, on-the-level can mean lots of different things in the context of an early stage software company, not just "10X engineer").

I think his point is that obsessing over technology when the technical challenges are insignificant compared to the business challenges is silly, and likely to lead to lost investment opportunities.

<comment><USER19> Doesn't this mean, full stop, that good developers should not even consider working for such start-ups? You know from day one that your contribution is not valued, and that if you are hired it's because management viewed you as a bargain basement sort of developer who could get the (easy, insignificant) tech job done and no more.

I don't see how the premise of the post can coexist with the phenomenon of clamoring to "only hire the best" and obsessing over e.g. HackerRank interview submissions or something.

Also, what of acqui-hires? I've seen and been part of some big corporate acquisitions in which a company buys a start-up that is not doing good work and has a stupid product, solely to get their 10-person engineering team and then drop the other employees. In which case that start-up succeeding mostly by not giving a shit about any actual business problem and just hiring a group of excellent engineers.

<comment><USER20> Experience suggests this may be wise.

I feel there's a huge "repricing" of the value of early-stage tech employment occurring as capable developers realize just how shitty the standard 90k + .1% job offer for 50-60 hours/wk, little autonomy, and zero chance for promotion is, in a city where apartments cost 3400/mo, gas is 3.50/gal and income taxes are 9.4%. (And the city wants a "tech tax" on payroll of companies)

I worked in this kind of environment for a few years, gained some great experience/connections, and enjoyed it to a large extent, but probably wouldn't do it again.

<comment><USER16> I've noticed both sides of this repricing - it works both ways.

Good, experienced American developers are realizing that $90K + 0.1% equity is a really shitty deal relative to what the rest of the tech industry pays, and they're giving up startup work for AmaGooAppBook.

At the same time, entrepreneurs are realizing that they don't actually need a good engineer to build v1 of their product, and so they're relying more on international contractors sourced through UpWork, Alibaba, etc. _Most_ startups I know actually have entirely-international dev teams now, and hiring your first local engineer is considered a milestone like getting funded (and often comes after getting funded).

I suspect that the real losers in this are entrepreneurs - the startup field has become so competitive lately that there's likely to be a shake-out where the vast majority of startups fail, and many founders are paying for these outsourced dev teams out-of-pocket.

<comment><USER20> Thank you for the very insightful comment.

This is yet another example of what I call the "Hollywood-ization of tech", where the industry (we?) are trying to sort out the relative value of being attached to something big vs. money vs. relationships.

I think our industry is maturing. I see it all around me. The industry-wide career ladder is starting to solidify, we're getting more concerned about credentials/pedigree, salaries are going way up, people are getting more concerned about their "careers", etc. I don't know that it'll ever get to the point of, say, law or banking, but it's a hell of a lot closer than it was 15-20 years ago, when there was much more of a "homesteading" feel to everything, and the suggestion that software could be a prestigious career choice was the last thing on anyone's mind.

To be clear, I don't know if any of this is good or bad, but it's definitely happening.

</comment></comment></comment></comment></comment></comment><comment><USER21> > "The ability to scale with success is important, but designing products for > high scalability from Day 1 is usually a mistake."

In my opinion, and having helped dozens of startups (friends or work), this is the biggest mistake I've seen. Engineers love to make things that scale, while business logic imply to leave it for when it is actually needed. I'd say it's #1 waste of time in a startup (in Spain). Also, when doing so mostly it's done without measuring anything, just doing it "for the sake of it".

</comment><comment><USER22> I understand the reluctance to evaluate a startup based on a prototype, but there are prototypes that are designed from the start to be incrementally refactored and replaced, and there are prototypes that are monolithic dead ends in hell. There are people who use technical debt to get to the next level so they can repay the debt, and there are people who use technical debt like Donald Trump uses bankruptcy court to screw people who trusted him.

</comment><comment><USER23> It appears to me that the OP is making a very serious, fundamental mistake: He keeps talking about "most" startups.

Alas, in shockingly stark terms, as a VC he is quite definitely, necessarily, in very strong terms not looking for "most" startups.

Instead, he is looking for exceptional startups. How exceptional? A few or so each decade.

What is true for most startups is no doubt close to irrelevant for the exceptional startups he is looking for.

Sure, due diligence is not important for lemonade stands, but it was just crucial for, say, the Lockheed SR-71. And for any startup that is using new, advanced, original, powerful, valuable technology, proprietary intellectual property, barrier to entry, technological advantage, due diligence stands to be crucial for, say, estimating the exit value of the company. Sure, a lemonade stand may have _traction_ growing rapidly right away, but it will never have much exit value.

Moreover, don't do due diligence on just the code or the architecture but also on the crucial core technology, e.g., some original applied math. We're talking theorems and proofs here, guys, maybe with some pure math grad school prerequisites missing among nearly all chaired full profs of computer science. Did I mention technological barrier to entry?

Uh, again, we are looking for the exceptional, and that may look different from the "most".

<comment><USER24> This. Upvoted.

Does anyone have the data to do the math and see what the difference in ROI is between startups in general and startups which a) should have technical due diligence done and b) which have or would have passed tech due diligence? Maybe we could call these something like "tech startups" to distinguish them from the others. :)

It would be good to see how much delta exists between these two different pools of startups. This would be a fairly easy filter for VCs to apply.

<comment><USER23> Would be good.

In the meanwhile, pretend you are the Johns Hopkins University Applied Physics Lab (JHU/APL) working for the US Navy, and they have explained that for their nuclear armed, submarine launched intercontinental ballistic missiles they have one heck of a navigation problem. They tried inertial navigation but are not pleased with it.

So, some physics guys thought about some satellites sending out signals, the Doppler shift, etc. Some back of the envelope physics was some convincing due diligence. The system was built and deployed as planned, and a receiver on the roof of the lab routinely navigated itself within one foot.

No question. No doubt. Worked great the first time.

Disclosure: Have to track the satellites quite carefully and update the data on their orbits frequently, and the JHU/APL had a group doing that. At one time I was a programmer, on the fast Fourier transform with passive sonar data, in that group and heard the stories.

There are many more examples where some such applied math/physics, etc. worked great. The due diligence was carefully done, and the batting average for the projects was terrific.

Instead of empirical pattern matching, just do due diligence on such projects one at a time. That's what the US DoD has long done.

E.g., look at that truck with some long tubes on the back the US just deployed to South Korea. Each tube has a missile that can get up to altitude like right now and hit an incoming warhead. So, given several warheads and several missiles, how to assign missiles to the warheads? There's some nice applied math there. And don't have to wait for a pattern of nuclear wars to know that the math will work.

Maybe the lack of enough data for pattern matching is the bad news, but, then, the good news is that same lack of data -- we're talking greenfield here, guys!

To heck with the pattern matching: Instead pick a problem, one that with the first good or a much better solution enough customer/users will care enough about to yield spectacular revenue and earnings. Then, use applied math, physics, etc. to get the crucial core of such a good solution. Write the software. Go live. Get publicity. Please the target audience. Smile on the way to the bank. The core tech permits better or first good solutions to challenging problems, gives crucial technological advantage, barrier to entry, proprietary intellectual property, etc.

But, as for the JHU/APL project for the US Navy and many more US DoD projects, have to do the due diligence one project at a time. Sorry 'bout that.

</comment></comment></comment><comment><USER25> I actually disagree with this. Of course, building the wrong product and having poor sales/marketing and all that other stuff matters a lot, BUT if the startup's technical people are weak and cannot quickly iterate, then this startup will bleed money really fast, while not being able to quickly modify the product as needed. So, I would say, you need to do technical diligence on the founders, but not necessarily on their code

<comment><USER26> I've worked one at least two or three little startups where they were iterating fast but the code never really worked (core functionality broken) and the non-technical people' didn't even find out until I came in to 'fix a few bugs' and found a pile of spaghetti which could not possibly function correctly.

So just be careful how you define 'iterate' and how much emphasis you put on 'quick'.

<comment><USER25> exactly, so that's what happens when a startup tries to iterate quickly, but doesn't have the right technical people who can pull it off.

</comment></comment></comment><comment><USER27> I relate with most of the points, also from my experience with due diligence (bought by the vc from an external consulting company) they cannot say all is good, since if it fails then they could be blamed, they cannot say all is bad otherwise you'd just need to sell once and you prove them wrong, so pretty much the outcome is always in between. That due diligence was really not worth the money spent.

</comment><comment><USER28> Another supporting argument for this is from The Innovator's Dilemma: disruptive technology (startups tend to leverage this) tends to be constructed from pre-existing and commercially available components. Think Snapchat, Instagram, tablets, digital pianos, and all-in-one PCs. All the major building blocks had already existed at the time of invention.

This is in stark contrast to sustaining technology, which tends to require expensive teams of scientists and engineers to make incremental improvements to an existing business line, making it palatable only to large organizations with deep pockets. Samsung can afford to have its physicists to find tighter SSD data packing. Google can afford statisticians to tune their search algorithm with complex models. Startups simply can't, nor should they!

<comment><USER29> Startups can do this, but they need to have very, very good people and go niche. The are millions of smallish niches out there that can be attacked with a sustaining approach provided you have the right people. The problem is really good people are hard to find and most niches are too small to support investor funding.

</comment></comment><comment><USER20> What about cases where "poor technology execution" is the root cause behind "we didn't move quickly enough" or "we didn't build the right features" because you didn't move quickly enough, and the product architecture made change too difficult?

</comment><comment><USER30> Anecdotally, I'll mention that for the two founder level pitches/seed raises I've been involved in, there was absolutely no technical diligence at all. Nor was there really any technical discussion at the YC pitch (we did not get selected, admittedly).

I've always conjectured that this is why vetting the team is considered such a critical element. For instance, I have a Ph.d. and so I've found people just assume I know what I am doing in terms of tech and algorithms. This can be a disadvantage when I want honest feedback, actually.

Most VCs are much better equipped to discuss the business related aspects than anything technical. In fact, I would be hard pressed to evaluate most start-up technology outside my fields of study, because it becomes so specialized so quickly.

<comment><USER31> My anecdote tracks with yours. Ours was a materials startup, no code involved, but totally dependent on a then-new type of plasma chemistry.

Intel Capital brought over their Wall of Faces (mostly technologists) for a "tech DD meeting". They asked almost no tech questions. All the questioning went to our business model, transition from custom proto to volume mfg, and building protectable IP. Our tech PowerPoint stack remained unrun, and I was very glad we'd stayed up all night doing 5-year financial pro formas.

I.C. invested. But I was surprised at how little they vetted our technology before signing the terms sheet.

</comment></comment><comment><USER32> Technical debt can absolutely kill a company if you have competitors who are fast-following while already knowing where the map will lead them. They have a chance to avoid some of the problems.

I would suggest this isn't addressed in post-mortems because most of the time customers won't or can't tell you why they chose a competitor, sales doesn't know or doesn't communicate that to engineering, or engineering is too dysfunctional to act on the information and has a vested interest in justifying their own decisions.

Sometimes it isn't even tech debt per-se, just bad decisions that make implementation of critical features much more expensive... sometimes so expensive everyone feels it would take too long to implement so it isn't done.

</comment><comment><USER33> In my experience as a software developer... Technical diligence, and technical debt, only matter in the way they affect revenue & growth. Technical people are usually more acutely aware of how they will be crushed by the current debt they are accumulating. Business is more acutely aware of how the business will fail when growth goals are not met. Both things should be everyone's concern. Striking that balance, and communicating serious pitfalls and shared goals should help give perspective.

</comment><comment><USER34> The headline for this post is far too broad. More accurate would be to say that "very early stage startup technical diligence is usually a waste of time". That is often the case, for many of the reasons the author outlined.

Later on in a company's life, however, technical diligence becomes very important. If anything, VCs should do a _better_ job of it. Countless companies have struggled, stalled or failed because they didn't become aware of or address technical issues early enough and scaled the business side too far out in front of what could be managed technically. This gets your company upside down fast, and in very difficult to unwind ways. Customers become dissatisfied at instability and lack of rapid improvements. Internally, strife between revenue owners and technical owners can easily increase as tech tries to balance delivering new funcitonality and addressing old technical debt.

After you find product-market fit and start really scaling-- ie _after_ the early stage-- technical diligence should be a _much_ higher priority than it currently is, for both VCs/investors and for company operators within their own orgs. Better technical assessments of issues and opportunities would serve most startups very well.

</comment><comment><USER35> Probably most of the time technical due diligence is not necessary but this is not my experience working with startups where the commercial success is strongly connected with a technical solution. Some examples:

i/ An startup wants to enter as an automatic security escrow in a Bitcoin multi-signature wallet (please forget for a moment this is about a sector with too much hype). If you do a basic analysis you will realize that multisig wallets are well supported but there is a missing link: there is no standard out-of-band way to setup these wallets and you should do many manual steps. These manual steps add a lot of friction for user onboarding and undermine the startup success.

ii/ A security startup wants to integrate their app inside Microsoft Outlook via an add-on. They are confident because they look at the API and it seems you can extend Outlook but they discover very late that a specific feature can't be achieved.

iii/ An startup wants to virtualize Windows applications (e.g. VMware ThinApp) using binary instrumentation and/or filtering drivers. They will find that some few but critical applications (e.g. legacy Java applets) require an ad- hoc solution for specific issues that significantly increases the development costs.

</comment><comment><USER36> Sigh. This article just sets up a bunch of false dichotomies. You can ship good code and put a product in the hands of people at the same time. You can also ship shit code and do the same. It obviously takes more expertise and diligence to ship the better quality code but it's not like taking 5 extra minutes before every commit is gonna break your business if you didn't have a proper business model to begin with.

<comment><USER37> This. "Go fast!" is often an excuse for putting zero thought at all into sane design or basic layering, which is basically just as fast as doing it the wrong way.

</comment></comment><comment><USER38> The main reason why investing in start-ups is hard is not because of the ones that die, it's because of the ones that remain afloat but only barely so.

</comment><comment><USER39> I naively assumed this article would be saying "don't be diligent in adhering to software quality in your startup" not "when investing don't worry about the quality of the software - it's a numbers game"

This is one more example of how what's good for the VC (with a large portfolio) is not necessarily good for the startup (with a portfolio of one)

</comment><comment><USER40> Flawed logic all around. First 4 points:

1\. Early version of a product especially when in hurry with features delivery are going to be "temporarily definitive" implementation. As soon a feature reached the production the code has to be considered "legacy code"

2\. Technical debt is a choice, and when you have too much of it you enter in a spiral of death.

3\. The quote from Donald Knuth is only a poor excuse to slack and to justify bad development habits. Writing efficient code most of the time doesn't require more time than not (choose the right container or the right algorithm for example).

4\. It's a so generic statement that adds no info at all.

"For >95% of startups [...] That means technical resources are rarely the cause of success or the reason for failure."

that's the best statement of the whole post that more or less sounds like this:

"In Africa 90.3% of people die due to: nutritional causes, hearth disease, cancer and diabets, why send over there good doctors then?"

</comment><comment><USER41> There isn't a distinction made here between product+technical diligence (e.g. is something possible to build given the funding sought) and execution+technical diligence (e.g. is the team building it the right way).

I would argue that the former is always important.

I agree that the latter is less important, but with some caveats. The number of engineering hours put in during the first year is going to be a tiny fraction of the second year, etc, so tech evaluations will change drastically over time. The author argues that this makes them a slight waste of time.

However, I've been very successful in using rough technical diligence in the early rounds as a proxy for measuring the decision making abilities of founders. This is hard to measure, so I still find technical diligence useful. You have to know the constraints they are working under, and not hold technical debt/differences of opinion (like homebrew vs stock) against them, the purpose is different.

Just my 2 cents.

</comment><comment><USER42> He is looking at obituaries of startups for advice. If you look at successful startups, did they face early technical risk?

Google won early by having the best algorithm. Facebook's early competitor Friendster died due to technical issues. It seems less clear at what stage companies like Uber and AirBNB faced substantial technical risk? I'd guess Slack and DropBOx had significant technical risk in early stages. I suppose WeWork probably had less technical risk.

I suppose the early prototype's code may not be totally indicative of whether the company can overcome the technical risk. Still, I think you need to evaluate whether the founding team can deal with the technical risk.

Technical due diligence isn't about looking for beautiful. It is about looking for an ability to manage technical risk. This includes an ability to hire and manage good engineers.

</comment><comment><USER43> but there is some minimum required. You want to avoid situation where you are investing in a team that litterally does not know what they are doing and are scamming you for money. Zero tech dilligence can't be the answer. But it should be pass/fail not graded for an A+.

</comment><comment><USER44> As a technical founder having gone through a few VC rounds, I was initially surprised by the lack of technical diligence but eventually came to the same understanding as the author: product-market-fit and sales/marketing execution make-or-break most companies.

I would add though that the impact the technical founder has on the design of the product and the quality of execution is immense and often hidden behind the non-technical founder selling the company to VCs. Good technical founders do a lot more than code. If I were a VC, I would look for teams with technical founders that have skills extending into product management, people management/recruiting, and operations.

</comment><comment><USER45> Because odds are high that you'll fail, in which case you default on your technical debt.

<comment><USER46> Technical debt is a temporary leveraging to achieve productivity at the expense of ultimate quality. So assuming the business failed for non-technical reasons, or if the business succeeded, both are examples of _why to use technical debt_ as a strategy.

The case for not acquiring technical debt is when a business fails because it can't pay down the debt or fails because it is bitten by the debt in some way.

<comment><USER47> "Technical debt" is actually an unhedged call option

<comment><USER45> Exactly. (An unhedged short call option to be more precise.) And a startup is a long call option. So a startup can bootstrap itself to a certain level of success by mortgaging its higher-upside states.

What would this look like in practice?

<comment><USER46> It happens all the time, not just via technical debt but also via management debt and various other leveraged choices.

For a young startup to be successful, it needs to offer evidence to investors that additional funding will lead to exponential revenue or market share growth. Those are the hard things.

Building code without taking on technical debt is actually easier than building it with _just the right amount_ of technical debt for the business's uncertain future.

In my opinion, the kind to avoid is sloppy, non-strategic technical debt, such as what you often get when developers are burnt out and need to complete aggressive milestones so that management will be satisfied with the rate of development. This debt tends to break modularity and lead to bad system design, whereas stategic debt can simply mean building a quick and dirty black box for desired functionality that has clearly defined interfaces that can likely remain once the debt is removed and will not necessitate a rewrite of other modules.

Similarly, management debt can be strategic if it teaches young or inexperienced managers useful lessons that they grow from and apply as the company grows. But management debt that results in burnout and high turnover also gets rid of the valuable lessons and lets someone with slightly more experience make some of them again.

</comment></comment></comment></comment></comment><comment> c-smile Truth is as usual in between of two polar opinions - in the golden middle.

Just hire at least one professional for the startup. He/she will simply not be able to do complete garbage. That's meaning of "professionalism" at the end, right?

Good Experienced Professional Engineer also understands real life compromises. For him/her it is not that hard to make initial architectural decision that allows to implement something fast but has a foundation for future expansion. Usually it takes about couple of days for the person that "been there, seen that" to make good architectural decision.

Startups: "We are not so rich to buy cheap things". Well, at least CTO / architect.

</comment><comment><USER48> Anything that starts with "For the most part, I was wrong." gives me a boost of trust and respect for the author of the post. It is hard to admit your own fault and it is much harder to admit to it publicly.

</comment><comment><USER49> Technical due dil doesn't just need to look for poorly architected systems and bad code. It should also look for code that's prematurely optimised and over- engineered.

If an early stage team is building a massively complex microservices based product, using a new type of database and deploying it via kubernetes — where a Rails CRUD app on Heroku would easily satisfy requirements for years. Then someone seriously needs to ask the question as to whether using bleeding edge tech is necessary, and whether it will impact the ability to iterate and hire.

<comment><USER50> Due diligence is less about code and more about robustness, licensing and operating costs.

Common questions are what would happen if the data storage failed/datacenter went dark and do you have an up do date list of all libraries used, yes including copypasted stuff out of stack overflow.

Due diligence != code audit. Sure if you get in that level detail for the td then it's a waste of time, but otherwise knowing that the tech team is not sitting on a landmine it's kinda important

</comment></comment><comment><USER51> "Most startup failures were caused by building the wrong product, or lacking strong sales skills, or not having a viable business model" <\- the first one of these is the biggest cause of startup failure, and is technical.

Startup technical diligence needs to check for a minimum level of ability and beyond that, ability to find the right direction to build in.

The idea that what product you build is _not_ the responsibility of the technical team is almost certainly why you think there's no point in doing technical diligence.

</comment><comment><USER52> Solid engineering may not be needed from a business standpoint, but good engineers want to work on solidly-engineered products. If you've got a pile of hacks, and you keep telling developers they can't take the time to clean it up because business needs come first, then speed of feature implementation is going to slowly degrade and eventually grind to a halt. The good ones you'd have tapped to clean everything up will be long gone by the time this happens.

</comment><comment><USER53> This article re-confirms that most of the money in Silicon Valley is being made without much real technical innovation. Not a surprise, but I still find it depressing.

</comment><comment><USER8> Steve Jobs rule 4 should come in here somewhere.

I agree, the first software produced is just a proof of concept and will be re-written. I even believe the only way to write good code is to build it fast in some intransitive language and then throw it away and do it over in something compiled.

So I agree with this post except, to become great, you need to know upfront you are just proving the idea and you will do Technical Diligence of the final product and NOT SELL CRAP.

<comment><USER54> "will be re-written"

From my experience working in startups, this is never the case. Crap code persist because rewriting it would take time, they would rather spend on new features. Feature creep sets in very fast.

</comment></comment><comment><USER54> "The ability to scale with success is important, but designing products for high scalability from Day 1 is usually a mistake. ("Premature optimization is the root of all evil." \-- Donald Knuth)"

He is using the quote wrong. A scalable product and an MVP are build entirely differently. Both scalable product and MVP can have technical debt, but I wouldn't say the scalable product is the optimized version of the MVP.

</comment><comment><USER55> And then you get hacked and your customer data is leaked.

</comment><comment><USER56> All aspiring programmers, pay heed to this. If you want to become a good programmer, startups are thus a waste of your time, at least the ones that think like this.

The devil/fun is always in the details. Deprive me of that, I will never work for you.

</comment><comment><USER57> It seems that the Internet and mobile technologies are established technologies at this point. Most internet startups are not technology driven. They are all about marketing, customer relations, service and business as normal. MBA's are more important than engineers.

High-tech startups still exist but they are not the norm.

</comment><comment><USER58> >only ~5% of post-mortems referenced a lack of technical ability/execution

I'd be curious to see how he arrived at that number. In my experience poor technical execution manifests itself as other problems, like slow time to market, poor user experience, or even building the wrong product.

</comment><comment><USER59> Is the article arguing that ability to execute is not a distinguishing factor for startups? Or just that non-technical execution is more important than technical execution?

</comment><comment><USER60> Great post Leo. Most startup "diligence" is a waste of time, usually just investors checking the box after they've already made a decision.

</comment><comment><USER61> What's the typical cost of bringing in someone to investigate and write up a technical due diligence report?

</comment><comment><USER62> Dealing with technical debt is the privilege of a successful business.

</comment><comment><USER63> The world very soon is going to be the opposite of it, where you just release software and wait. An anonymous person launches a company without any capital, registration, employees, marketing, sales, which is ipo from day 1 and the founder is a billionaire just by releasing a piece of code. With blockchains it is possible to do so.

</comment><comment><USER64> Provocative title! Substantive points to back it up?

> Early versions of a product are often prototypes that are intentionally > meant to be rewritten or heavily refactored in the near future.

Cool, but surely a check of basic physics is in order for certain ideas? (see: uBeam)

> Because getting a product in the hands of users is a top priority, even > great engineers will intentionally take shortcuts and accumulate technical > debt in order to launch sooner.

Agreed for the most part. I see technical debt as incurring a price to get to market faster. Sometimes the price is too high, though I'd wager 9 times out of 10 it's the product-market fit that would kill a company faster.

> The ability to scale with success is important, but designing products for > high scalability from Day 1 is usually a mistake. ("Premature optimization > is the root of all evil." \-- Donald Knuth)

Sure, but I don't think this is technical diligence necessarily. To me, the diligence would be researching whether or not the product/service _could_ scale, either by seeing other examples of similar companies, understanding how AWS works, understanding manufacturing processes, etc.

> "CTO" is an ambiguous title at small companies. > Because code is likely to > be temporary and the CTO's role is likely to change quickly, it's not > obvious what should be measured during technical due diligence.

Ok... but can one not measure or research the person (and team's) ability to create technology or manage those who can?

> (An aside: in addition to tech diligence having questionable value, many > seed stage founders consider it overbearing and passively resist it. Given > that engineering resources are scarce and that there are plenty of investors > who write $100k+ checks after one or two short meetings, founders often > prioritize "lighter-diligence investors" instead of submitting to an hour or > two of technical grilling.)

Jesus Christ I need to move to California already.

> in today's world of SaaS tools, APIs, and cloud infrastructure, most startup > ideas don't have significant technical risk. That means technical resources > are rarely the cause of success or the reason for failure.

That's actually a very fair point. In the specific domain of web product companies that are leveraging the heavy lifting of others, a few Business Bros can get very far.

But does this cover ">95% of startups" ?

> A quick skim of CB Insights' collection of 150+ startup post-mortems reveals > that only ~5% of post-mortems referenced a lack of technical > ability/execution.

Yes but did none of these startups have any technical due diligence? Maybe they did, and that's why the rate is so low.

> But for a typical consumer app or SaaS tool, technical risk is low enough to > be ignored.

Sure, just double-check that the engineers on the team did more than a coding bootcamp.

> On the recruiting side, a technical founder needs to be someone who can do > recruiting and someone whom other engineers want to work for. This is > especially true in today's hiring market, which is extremely competitive. > The best ideas won't go far if a company can't attract enough talent to > launch a product.

This sounds like a great reason to vet the technical prowess of the team.

> Notably, these tests don't require having a technical background.

Oh come on now. A GitHub filled with shit code and poor technical decisions on past projects would completely escape you folk.

> Instead, they require the ability to read a resume, common sense, EQ, and a > few reference checks.

Reference checks maybe. Everything else you can get duped. Even reference checks.

> If you're a seed investor and you're doing tech diligence on a company, > you're most likely wasting your time and the founders' time.

Perhaps for your narrowly defined web product startups, which apparently are 95% of startups. But when someone starts talking to you about drones delivering packages, all of a sudden it might be nice to be able to draw some free body diagrams and verify the feasibility of a payload claim.

> A well-built product that doesn't solve a problem will always be inferior to > an ugly, buggy product that addresses a burning need.

Sure, but I don't think this logically leads to the conclusion "technical diligence is a waste of time".

Overall a pretty meh post. Focuses on a narrow subset of startups for which, it's mostly true, the tech is a commodity. I don't even consider web products to be "technology" anymore quite frankly.. Not until you need to scale some sort of real-time computing with millions of users and build your own datacenters.</comment>


Show HN: EEnglish.com – Test, and then improve your English pronunciation - <AUTHOR> http://eenglish.com

<comment><USER2> A cute game to train your ear to hear English and click on a square to show that you heard that particular sound.

If you choose correctly, you will eventually reveal an underlying picture. If you choose improperly, you get a beep.

Even as a native English speaker, I lost focus a few times and clicked the wrong square. It can also be a good "attention" training game as well.

</comment><comment><USER3> I would focus on simplifying the steps a new visitor to the site takes. I found it confusing. For example, I got to the screen with the h1 text "Welcome", but at the top left was an animated arrow pointing to another Welcome button. Where am I supposed to go?

<comment><AUTHOR> Fair enough! Thank you for the feedback! It's tough as the developer of a product to get an objective 'feel' for how others may receive their first impressions.

The h1 "Welcome" is where we are letting the visitor know what our product is about and how it can help them.

The "Welcome" button is the 'Main Menu' where the visitor can navigate through the different modules of the app.

The text of this button changes depending on which module the visitor is in... so.. when on the Welcome page, it says, well, "Welcome".

I wonder if it would be better to change the way the text of the button operates, or adding in a 2nd main-menu control with all the modules listed within the welcome page, or something else?</comment></comment>


My Y Combinator interview. - <AUTHOR> http://www.korokithakis.net/node/125 <comment><USER2> "I got an email from Paul Graham saying basically that being a single founder put me at a disadvantage, because two founders can talk each other out of bad ideas, but I appeared too stubborn."

Fortune 500's biggest company is a single-founder company. Most Fortune 500 companies were founded by a single person. Don't let detractors tell you single-founder companies don't work.

<comment><USER3> Fascinating. Source?

<comment><USER4> [http://money.cnn.com/magazines/fortune/fortune500/2010/full_...](http://money.cnn.com/magazines/fortune/fortune500/2010/full_list/)

and Wikipedia. I went through most of the list. It's right to me.

<comment><USER5> If you look at the wikipedia page for Sam Walton, the founding looks a little more nuanced: "Walton went on to open more Ben Franklin Stores with the help of his brother, father-in-law, and brother-in-law."

<http://en.wikipedia.org/wiki/Sam_Walton>

<comment><USER4> Sam Walton's autobiography mentions that his father-in-law provided the initial capital (that was about it), and his brother played an insignificant role (like buying things from suppliers). His brother, who was younger, was more of a helper while Walton built his first store (a Ben Franklin store that he later sold and started Walmart on his own based largely on his Ben Franklin stores).

<comment><USER5> Perhaps I'm quibbling, but an autobiography that downplays the contributions of others? Quel surprise!

</comment></comment></comment></comment></comment></comment><comment><USER6> > I got an email from Paul Graham saying basically that being a single founder > put me at a disadvantage, because two founders can talk each other out of > bad ideas, but I appeared too stubborn. I'm not entirely sure what this > means, as I was under the impression, from reading his essays, that Paul was > against single founders because they might give up too easily, so a founder > who sticks to his idea would be desirable.

Having worked both solo and with partners, I will never again run a business solo for an extended period of time. If the business is already profitable, I'll hire a competent GM-level person to help run it. If it isn't profitable enough to do that, then I'm going to spend a majority of my time recruiting someone for whom the company will be greater than the sum of its parts.

Having someone to talk to is _huge_. If they pick out a single one of your blindspots or bad points, that could make the business 20% more successful. Really, there's a long list of things that can go wrong in business. Tweaking and refining at _any_ stage could easily give a 1%, 2%, 5% edge. Those stack up really fast.

Solo isn't so good. Partners are good. If profitable, you can hire some talented to take that role. If not profitable, I'd strongly encourage you to get over your... well, I was about to call it delusions of grandeur, but that isn't fair to say. For me, in the past I've fallen in love with my ideas, thought they were worth more than they were, and thought the execution would come fairly easily. I was delusional. Maybe you're not, but if you don't have money coming in and an _obvious_ winner on your hands, you might rethink what the business is worth and go recruit someone. Have some sort of vesting or buyout provisions if it doesn't work and go get a cofounder.

I was the biggest pro-solo guy in the world previously, but I was mistaken. You got a high fever? Tough shit, it's just you running the business, make it work anyways. You ripped the cartilage in your knee and can't walk? Tough shit, hobble over the taxi stand, get a taxi to the bank, and limp/drag yourself in to do your business.

Having a team is good. If profitable, hire a GM-type, that'd work. If not strongly think about recruiting a cofounder.

<comment><USER7> I interviewed as a single founder as well. They spent the entire interview trying to directly match my idea to existing markets. I probably appeared stubborn as I tried to explain how my idea was different.

How could I appear other than stubborn?

If they had said, OK I think we understand your idea but your market doesn't seem big enough (or something to that effect), maybe things would have turned out differently than 11 minutes of what seemed to me like "we don't get it," when they probably did and didn't believe in it.

Well, in any case, I got some good feedback and I still appreciate the opportunity to discuss my company with them.

Hindsight may be 20-20, but I still have to fend off the regret for not redirecting the conversation.

As a word of advice to future single founders, they are going to aggressively push you the entire time. Be prepared to concede to them at some point even if they don't "get it." Otherwise, you will appear stubborn.

<comment><USER6> Okay, another lesson I learned the hard way. People tend to like their own opinion more than your opinion. If they say you might be wrong, they usually want you to say, "Wow, that's a really, really fascinating point you bring up. I'm going to strongly think about that." Maybe not YCombinator, but like 99.99% of the rest of the world.

> As a word of advice to future single founders, they are going to > aggressively push you the entire time. Be prepared to concede to them at > some point even if they don't "get it." Otherwise, you will appear stubborn.

People need that. And y'know, you might be wrong. Or not. If you have a _great_ reply, then maybe say, "You know, that's a fantastic point, I spend a lot of time thinking about that myself. Can I show you the numbers I ran on that?" Then show them, and say, "I still think about it. Do you think these numbers look good to go, or would it be worth considering more? What would you do about that concern, in my shoes?"

I'm going to keep the details vague here, but I remember one time I was selling something. The client wanted something else, that was stupider than my idea. But I was swallowed my pride and did it their way. Y'know why? _Because I wanted their money more than they want my expertise_. Oh, it was still a good deal for everyone. But they demanded it a certain way, and okay, you've got the money, you win, let's do it your way.

You wanted someone's money. Okay, they win, let's do it your way. Well, not _that_ wishy-washy. But "I'll strongly consider that" (and then do! maybe even follow up on that point later with a few page brief/plan/strategy or something) is good. If you've already got the answers, stress how you think the other side is _brilliant_ to bring that up, and you think about it and worry about constantly. Nobody wants to give money to someone that makes them feel stupid.

I don't know. Maybe this doesn't apply to YCombinator, they seem like the top 1% of intelligent and savvy people. But the other 99% of the world, definitely.

Edit: Once you've got a proven track record for doing massively amazing things, you can maybe just tell people how it's going to be and insist you're right. But that comes much later. If you seem like a commodity at all, you pretty much have to do it the way the people who have the money want it. When they bring up a concern, they _really_ don't want it dismissed by some kid as not a big deal. Even if you're right (which you might not be).

</comment></comment></comment><comment><USER8> I hope you continue your startup. YC is NOT the end of the line.

<comment><AUTHOR> I will, but it's very disheartening, sadly...

<comment><USER9> > _I got an email from Paul Graham saying basically that being a single > founder put me at a disadvantage, because two founders can talk each other > out of bad ideas, but I appeared too stubborn._

This applies equally for being talked out of good ideas.

And if your idea is good to start with, then there would be no point in changing it until you've pursued it long enough to see where it leads.

The thing to remember about YC is that it becomes a sort of self-fulfilling prophecy. For example, let's say that Cal State Chico (not a top school) somehow convinced all the top students to attend next year. Pretty soon, it would start to be known as a top school. And let's say Stanford only got applications from the bottom 5%... you see where this is going.

Paul Graham's evangelizing means that, regardless of the utility of Y Combinator, if he convinces the top start-up prospects to join the program, it will make the program look good. They are looking for people who would be _successful even without them_.

Y Combinator could be _minorly_ helpful and they would go on to success; it could be a wash, and they could go on to success; it could be a slight negative, and the strongest candidates would mostly still go onto success.

People could also FEEL that it's an incredible experience, even if this isn't objectively the case. Many people join various kinds of self-help or self- empowerment groups and enjoy the events and believe in them strongly, even if there is demonstrable practical harm.

Y Combinator could also have a net negative effect on the startup landscape, because NOT getting in can be so disappointing that it can lead people to give up (I wrote that before your post, but the link expired; I reloaded, and made this a reply instead of top-level comment); in other cases, they've found people who applied and got in, who considered _getting in_ to be the accomplishment. Paul's viewpoints have been increasingly dominating the national conversation on startups the last few years, so the hypothetical indictments are meant to address its success as propaganda. Obviously if it really WERE the best approach, criticizing it for being too successful _in its results_ would be disingenuous.

There's also a huge emphasis on getting funded being an accomplishment, which is a big distraction from the real priority for a business, which is making something that makes a profit. (A nice big funding round also means now you need an even BIGGER exit. This can actually reduce your chances for personal success. Xobni couldn't sell to Microsoft for $20 million because it wouldn't have been a big enough ROI for its investors. Perhaps they really thought they could be a billion dollar company and didn't want to sell anyway, but you see the point.)

Paul's talk about angels and super-angels and valuations focused on the main point being "the percent chance that the start-up is Google," if I recall correctly.

To me it looks like Y Combinator has the wrong model for that. The resources and timeframe favor much smaller ideas. According to the unofficial YClist.com, the top exit was 280 North at $20 million, which means not only have they not had another Google, they haven't yet had another ViaWeb.

It would be interesting to find a list of angels and their investments for the last 5 years and see which ones had bigger deals than that. I'm guessing a lot. So, that covers instincts and judgment, at least so far.

As for changing your idea, there are market segments that have been goldmines which I have yet to see a single YC company delve into. Thus, I'm not so sure on the advice portion.

There is a pretty big generation gap with the hot web properties and I don't know if any of the YC principals really grok it.

If PG reads this I expect to be told I'm wrong on every point except perhaps for a token concession for decorum. It's hard to talk people out of bad ideas when they're stubborn ;)

<comment><USER10> Two parts that seem incorrect:

1) YC has one company with very high potential of a billion dollar exit in Dropbox. An IPO in a few years isn't out of the question either. They also have at least a half dozen that are likely to be as big or bigger than Viaweb:

2) Google took seed funding early and then raised VC. That is the model YC uses.

<comment><USER11> Dropbox is AFAIK a one founder company. Go figure.

<comment><USER12> "It was founded in 2007 by MIT graduates Drew Houston and Arash Ferdowsi as a Y Combinator startup" <http://en.wikipedia.org/wiki/Dropbox_%28service%29>

<comment><USER11> This therad disagrees: <http://news.ycombinator.com/item?id=801503>

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Djangy got an interview and then after several days, a rejection letter. We're too similar to Heroku.

You know what? I'm not really that upset. They made a good decision from their point of view. But we have 200+ beta users, lots of positive feedback, and have a good product.

We don't need YC to tell us that. So just keep on truckin. Get users, iterate, and make YC regret rejecting you :-)

<comment><USER13> I could imagine YC might consider there might be a conflict of interest in funding you (although they have funded competitors before).

<comment><USER8> Right. Like I said, it's a totally reasonable reaction. I really enjoyed the interview and talking to the other companies while we waited.

If I was them, I probably would've made the same decision. But we're still kicking ass :-)

<comment><USER13> Out of curiosity, are you going to apply to TechStars ?

<comment><USER8> Didn't plan on it.

EDIT: to clarify, YC was never about the money for us.

<comment><USER13> Was it specifically the Heroku-connection that made YC attractive to you (i.e. their expertise in this marketplace) ?

<comment><USER8> No way. It actually had very little to do with Heroku. We wanted to be involved in the network (I already know several folks from recent YC batches), to contribute, to tap the collective wisdom of the YC alumni, and the connections to publicity outlets.

Like I said, it had very little to do with Heroku and the money. We have a product with users and we wanted some help and to contribute.

</comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> I would like to post here to thank you all for your amazing support, you are a fantastic group of people. I hope everyone who didn't get accepted to this batch can see this, I know it will help their morale, as it has greatly helped me.

Thanks again!

</comment><comment><USER14> It's not clear from the article, but I hope you had the chance to spend a bit of time in California, looking around, seeing some of the sites, and so on. It'd be a pity to go all that way and not have a look around!

Also: it looks like you live in a part of the world that is particularly nice and beautiful in its own way. You ought to do something to encourage visiting hackers to stop by so as to have some people to chat with once in a while.

<comment><AUTHOR> I'm in LA now, and it's great! I'm glad I have friends here and can take a small break.

Greece is fantastic, it's just amazingly beautiful. Maybe we can organise sprints on the beach, that would be quite nice...

</comment></comment><comment><USER15> Καλημέρα , Κατ΄αρχάς συγχαρητήρια που έφτασες μέχρι την συνεντευξη! Η γνώμη μου ειναι οτι δεν θα πρέπει να απογοητευτείς αλλά να το δεις σαν ευκαιρία για ένα νέο ξεκίνημα. <http://www.iol.co.za/lifestyle/the-power-of-no-1.746628> George.

<comment><USER16> I see this is the Greek corner of the comments section, so I should also congratulate Stavros for going through the experience, and hopefully it altered his perception in ways that will help him in the future. Stavro, my offer still stands, if you're ever back in London, drop me a line and I'll buy you a beer.

<comment><AUTHOR> Thank you, I think it has. I'll definitely be coming to London soon, so I'm not missing that beer :)

<comment><USER16> Looking forward to it. Good luck with everything.

</comment></comment></comment></comment><comment><USER17> _"I was under the impression, from reading his essays, that Paul was against single founders because they might give up too easily, so a founder who sticks to his idea would be desirable."_

Discussion of determination vs flexibility: <http://paulgraham.com/founders.html> <http://news.ycombinator.com/item?id=1820561>

<comment><AUTHOR> I see. However, when your users like your service so much that they volunteer their time building browser extensions and integrating it into their services, I don't think it's "too stubborn" to follow through...

EDIT: I realise that's not the point you were making, I am just commenting with my thoughts on the matter.

<comment><USER17> No comment on this specific scenario. I don't know you, and what do I know anyway? But it's so hard to distinguish 'determination' from 'stubbornness' that I've decided those labels are useless. No matter which you are, people will call you stubborn until you succeed.

<comment><AUTHOR> I know, I reflected that in my edit. I agree with the latter, I think history decides if your stubbornness was misplaced or not.

<comment><USER17> Max Levchin: "Being an entrepreneur is not about being in love with an idea, it's about being in love with running a company." [http://www.quora.com/Max- Levchin/What-are-your-greatest-less...](http://www.quora.com/Max-Levchin/What- are-your-greatest-lessons-learned-as-a-young-entrepreneur)

When he puts it like that, I'm not sure I'm an entrepreneur.

</comment></comment></comment></comment></comment><comment><USER18> Have you considered applying to The Openfund (<http://theopenfund.com/>) or HackFWD (<http://hackfwd.com/>)?

<comment><USER19> Or perhaps techstars.org too.

<comment><USER18> Yeah, too bad the application deadline for Techstars NY was closed couple of hours ago. I suggested Openfund because it's also based in Greece, but it's Pan European.

</comment></comment></comment><comment><USER20> I would see this as a win for you :)

Being invited is a strong sign that you/your idea have merit. But instead of having to deal with funding/investors/other crap, you get to work on your idea, in a "remote area of Greece", be your own boss and grow the company how you want. I can very easily see this idea being modestly successful and giving you a lot of freedom to work on other ideas.

<comment><AUTHOR> Thanks, I think that would be ideal. Still, I think YC would facilitate this in that you don't really need to put as much effort into networking (they do it for you), so I can work on my idea in Greece while still getting introduced to interesting people.

</comment></comment><comment><USER21> Your site and idea look great. I would probably move away from the paid accounts and try to monetize another way. I am sure you probably do have some paid users but I wouldn't pay for a service like this even though I like the idea. You'd probably be better off with an advertising model.

<comment><AUTHOR> Thank you. I've found that paid users actually provide the most revenue at this stage, as the advertising model needs a bit of scale to work well. I think it does have great potential to work in the future, though.

</comment></comment><comment><USER22> A very well-thought out site and a good implementation (I've just tried it). I'm going to use it.

I'm a single founder and whilst I've never reached a point with stratospheric income, the businesses that I have built in the 15 years I've been an entrepreneur have been great. I've enjoyed life. For me, being a single founder has always meant quick decisions and I employ people to compliment me. I'm not a 'finisher' - I'm an ideas person - and so I needed to employ people who would keep me on track and help me finish. There is no right or wrong way in terms of the number of founders, my opinion, and indeed I have both seen and experienced that having more than one founder can lead to disagreements. Good luck with Historious. I really like it

<comment><USER23> perhaps your income would be more stratospheric if you hire fewer employees that compliment you and more that complement you :)

<comment><USER22> Yeah, and maybe check my spelling :) Thanks for pointing that out!

</comment></comment></comment><comment><USER24> Ah darn, would have loved to meetup with you Stavros, as a fellow Greek startupper. :) I'll let you know next time I'm in Greece.

<comment><AUTHOR> Dude stop thinking about Greece and write that notifo Android client!

Also: I'd love to meet up.

</comment></comment><comment><USER25> excellent writeup, great perspectives -- thanks for sharing!

> They did seem to be a bit dismissive about the product (as in "why would I > use this, I already have bookmarks in my browser"), but I'm sure that's just > standard procedure in this sort of interviews.

i'm curious what others' experiences are on this front?

</comment><comment><USER11> Nevertheless, you kick ass. You are from Europe (me too), from "secondary" country (me too), one founder (me too), you did make it to the interview (I didn't).

</comment><comment><USER26> Just an aside on histori.us, it's a useful feature, we wanted to do the same but never got round to it. I noticed today however that when you're logged in to Google, and search, there is the option to just search "Visited pages". Although a super-set of your bookmarks, it's still useful, and free... I'm not sure how long the option has been there.

</comment><comment><USER27> what did you tell them when they said 'i have already bookmarks in my browser'?

i started hacking on a similar idea (a chrome extension that monitors every url I visit and logs them with a web service that performs snapshots and full text searches), but then realized chrome's history already performs full text searching.

<comment><AUTHOR> I said that it's not comparable, as the browser only stores the title and gives you lists, etc. Something like Google Bookmarks is a more direct competitor, but I don't think that's the thing to watch out for either, as it seems to be someone's weekend project and they don't really develop it any more. I'm much more worried about Pinboard, for example.

</comment></comment><comment><USER28> I can't speak for your specific case, but I would guess that stubborness would indeed work against you. The rules for single cofounders work the same as for teams: call out YC when they incorrectly correct something you know to be valid (and back it up) but if the criticism/idea they inject is good then roll with it and riff on it with them. You'd do the same, presumably, if you were chatting with your entrepreneur friends... I'm not sure it's really that different; it's basically a panel of hackers :)

<comment><AUTHOR> I wasn't aware of them suggesting anything that I dismissed. It's my policy to consider every suggestion, be it from users or not, and I don't recall them suggesting anything...

</comment></comment><comment><USER29> I really admire you for posting your details about this.

Are there other blog posts by other people that have been through this experience?

<comment><AUTHOR> Thank you, I'm not aware of the YC guys saying anything about not talking about the experience, and I don't think I'm being disrespectful to anyone, so here it is!

</comment></comment><comment><USER30> I have to ask what benefits your idea offers over something like diigo.com or even delicious.com. You present the idea slightly differently from diigo, but in the end diigo does exactly the same things, and then some (a lot more actually). I don't mean to discourage you at all, I'm just wondering what I may be missing here.

<comment><AUTHOR> The disadvantage I see in all these services is, actually, the fact that they do more. Most people don't want to think about bookmarks, they just want an easy way to add them and then find them again. The fact that you never really have to visit the site, and that you can just click a button to bookmark things and then find them just by recalling the slightest detail is what sets historious apart, in my opinion.

However, different people will need different things. I just think there's a market there for both approaches.

</comment></comment><comment><USER31> I really like the design of your site.

<comment><AUTHOR> Thank you, it's a themeforest template! Having no cash presents interesting challenges.

</comment></comment><comment><USER32> It's great that you are going forward with your idea.

From a user point of view of your application, my main concern would be privacy, how do you address this?

<comment><AUTHOR> Well, your bookmarks and data are never shared with anyone unless you make them public, so we take very good care of your private data remaining private...

</comment></comment><comment><USER33> Please continue your startup. I use it constantly.

<comment><AUTHOR> Thank you, it's already profitable enough to run so it's never going away!

</comment></comment><comment><USER29> i'm trying to create a web page with links to information by people that made it to the interview round:

<http://ycuniverse.com/interviewees.php>

If you have links to posts/blogs/etc about the interview experience, please forward the links to me. thanks.

</comment><comment><USER34> Glad the ride was enjoyable :)

</comment><comment><USER35> it's good feedback, find more people to join your cause, keep up the good work!

<comment><AUTHOR> Thank you, I did find out that referrals work well, so stay tuned :P

</comment></comment><comment><USER36> don't give up!

</comment><comment><USER37> The reason why I think they rejected you is because you are a single founder. That means if you get hit by a bus they're fucked. Whereas, if you had a team or a co-founder the company can still go on without you.

<comment><AUTHOR> Maybe so, but I wouldn't be averse to recruiting a cofounder...</comment></comment>


Falsehoods Programmers Believe About Pagination - <AUTHOR> https://www.hezmatt.org/~mpalmer/blog/2018/12/12/falsehoods-programmers-believe-about-pagination.html <comment><USER2> I'll add

* pagination is the only way to let the user browse a large amount of data

* you have to let the user browse to any arbitrary page (google doesn't)

* you know how many pages there are (google guesses)

• users like pagination

* pagination is the best and most efficient user experience

• pagination is the only possible user interface</comment>


Fie – A Rails-centric front end framework running over a WebSocket connection - <AUTHOR> https://fie.eranpeer.co/ <comment><AUTHOR> Stumbled across this after reading this Medium post [https://medium.com/@undergroundpost/painlessly-managing- long...](https://medium.com/@undergroundpost/painlessly-managing-long-running- processes-in-your-views-using-ruby-on-rails-a83f57b51c31...very) intriguing! I've always wanted a clean way to do this type of real-time without having to go deep into js hell.</comment>


Show HN: To-Do app as a serverless application using AWS Lambda and Go - <AUTHOR> https://github.com/smalleats/serverless-todo-example <comment><USER2> Would be really valuable if you could also show how to deploy the web app that can talk to this API on AWS as well.

<comment><AUTHOR> Thank you for the suggestion. We created the sample project to demonstrate our approach to error handling in SAM setup, see [https://medium.com/2pax/fe0e10808732](https://medium.com/2pax/fe0e10808732). However, it may indeed be interesting to add a web app as well to show how this would be deployed as a "complete" stack.

For the time being, I added a note to the project readme to clarify the scope of the repo.</comment></comment>


Who says RSS is dead ? - <AUTHOR> http://tekunik.blogspot.com/2009/10/who-says-rss-is-dead.html

<comment><USER2> Who is actually saying RSS/Atom is dead? I use it heavily - via Google Reader. I even have feeds of certain Twitter users, bypassing the need to follow via Twitter.

<comment><USER3> Techcrunch said it...morons (them, not you).

<comment><AUTHOR> <http://www.techcrunchit.com/2009/05/05/rest-in-peace-rss/>

btw it has gained more importance after pubsubhubbub and rsscloud.

</comment></comment></comment><comment><USER4> I've got a more interesting question: Is RSS the best technology for delivering daily reading?

I tended to think so and I have been an avid user of Google Reader, which diligently delivers a new stuff to read every day.

But after some time I discovered one negative side of feed reading - namely, it fosters the attachment to always check whether there is something new to read. For example, I go through all my feeds, and then one hour later I again would check whether there is something new. Of course, everything can become an addiction when one does it too much, but in case of RSS, it seems to me that it is something innate in this technology. Simply, the way it works it might create a feeling of "obligation" to clear all unread feeds.

Currently, I am working on developing another system, which would deliver interesting stuff to me more efficiently and my ultimate goal is to get rid of feed reader. For same websites I read daily like HN, I am now using old- fashioned bookmarks.

Then, there are some other areas I want to follow, for example, "minimalism". Now, instead of subscribing myself to 10 feeds about minimalism and check them several times per day, I am now using twitter search and services like Tweetmeme. The rationale behind this is, that if someone writes something worth reading, it will almost sure be retweeted. At least in my case, I think the future is to use some service built on twitter to find what is being tweeted, without being psychologically shackled by "subscriptions".

</comment><comment><USER5> RSS is alive and kicking, plenty of really big applications depend on it for their functioning. FB, Google News, Twitter and a whole pile of others would be unthinkable without RSS as a service underneath to take care of a good bit of the 'plumbing'.

RSS is not very 'sexy', but then again neither is a transistor.

</comment><comment><USER3> I use RSS/Atom all the time from an API standpoint. It's an excellent starting point for publishing data to an external 3rd party.

</comment><comment><USER6> I guess it's in vain to ask people to stop calling feeds 'RSS' when there's a better format we should all be standardising around...

<comment><USER7> Atom was created because the RSS people refused to fix the ambiguities with RSS. Almost immediately after Atom was finalized, the RSS people changed their mind and fixed the big issues. So now there's really not much reason to choose Atom instead of RSS. Atom ended up being a big waste of time; actually, it wasn't a mere waste of time, it is actually harmful. Now everybody who deals with feeds has to deal with 4 kinds of RSS + Atom, instead of just 4 kinds of RSS.

<comment><USER5> You could argue that Atom wasn't a waste of time because it got the RSS people to fix their stuff.

It's a great example of why competition is good.

</comment></comment></comment><comment><USER8> Nobody.

</comment><comment><USER9> RSS isn't dead, my sisters just discovered it a year or two back.

</comment><comment><USER10> i'm trying this out now: <http://gr.aiderss.com/> I can see it becoming useful</comment>


Deep Learning notebook walkthrough in Clojure - <AUTHOR> https://github.com/gigasquid/cats-dogs-cortex-redux/blob/master/Cats%20and%20Dogs%20in%20Cortex%20(Redux).ipynb <comment><USER2> Great writeup. BTW gigasquid's talks from various Clojure conferences are fascinating.

</comment><comment><USER3> why though

<comment><AUTHOR> Great question. I, (and other people from the Clojure community) think that the Clojure language has a lot to offer to the Deep Learning/ Machine Learning space.

Step 1 - Build bridges to other Deep Learning communities using Jupyter notebooks, etc.

Step 2 - Bring innovation. In this area I see Clojure particularly useful in joining the symbolic logic and the deep learning model realms.

Step 3 - TBD (Depending on how the various time lines shake out to the singularity ;) )</comment></comment>


How Technical Advisors Can Help Non-Technical Founders - <AUTHOR> http://www.thisisgoingtobebig.com/blog/2014/8/21/how-technical-advisors-can-help-non-technical-founders.html

<comment><AUTHOR> Good advice from the article:

 _" This happens all the time on the funding and business side--where someone experienced in business helps two developers figure out a funding or revenue strategy, intros them to customers, etc. I haven't seen it done much on the technical side, but there's a huge opportunity out there to help promising ideas connect to the technical community."_</comment>


Show HN: Moon by Ai Weiwei and Olafur Eliasson - <AUTHOR> http://moonmoonmoonmoon.com/

<comment><USER3> Seems similar to [http://www.drawball.com/](http://www.drawball.com/) , except that Moon requires registration while Drawball is anonymous. Ironic, considering the artists.

<comment><USER4> Indeed, the login thing kind of kills it.

<comment><AUTHOR> We initially wanted it to be anonymous but ended up going with login for two main reasons:

\- Social login means sharing is only a click away, encouraging conversation and possibly more thoughtful contributions.

\- We wanted to give people equal chance of contributing and avoid the scenario where a handful of users (vandals?) find the site before everyone else and take over it all. That meant limiting the number of marks a person can make in a given time period - and that's easiest to do when you have users.

Would love to hear your thoughts on these points. This is still a work in progress after all...

</comment></comment></comment><comment><USER5> Summary for those of you on text-based or js-free browsers:

It's a sphere, subdivided into squares. Everyone shares the same space, so you can draw in a random square (if you login) or browse other peoples marks.

<comment><USER6> All I see is a black screen on Chrome...?

<comment><USER7> If you have ghostery it blocks stuff the site needs. This was the problem for me anyway.

<comment><USER8> mmmm. So ghostery is reporting blocking the following:

* Facebook Connect - Widgets * Google Analytics - Analytics * New Relic - Analytics * Typekit by Adobe - <USER2>

Are you saying the website _needs_ one of all the above to display some webgl content ? Or something else is being blocked by this extension?

<comment><AUTHOR> Will look into it. We haven't had time to test with ghostery/disconnect but the site definitely doesn't _need_ any of those things to work (except maybe it wouldn't look very nice without the fonts from typekit). It's a bug, not a feature :)

<comment><USER9> It's Facebook Connect that's causing the issue. Unblocking that makes it visible.

</comment></comment></comment></comment></comment></comment><comment><USER10> "A Year of Drawball" is one of the most fascinating videos of collaborative social phenomena I've ever seen: [http://www.youtube.com/watch?v=ovG- t_JPGB4](http://www.youtube.com/watch?v=ovG-t_JPGB4)

The mechanics are very similar to Moon, each individual user only had a tiny amount of ink on an extremely zoomed in canvas so large artworks would require co-operation from hundreds of people.

</comment><comment><USER11> Just curious...what is the submitter's relation to Ai Weiwei and Olafur Eliasson? Is he/she their developer, or actually either Ai/Olafur? Either would be pretty cool :)

<comment><AUTHOR> Creative director (and developer). I doubt the artists have time to read HN :)

<comment><USER12> can you describe the process of working with the artists to develop this?

did they come to you with the finished idea, or a general concept, or ..? was there a lot of iteration on the idea?

<comment><AUTHOR> It was an incredible collaboration experience. We talk about this in the "making of" video that should be coming out soon (assuming we make the cut...)

</comment></comment></comment></comment><comment><USER13> Really nice, though the 'my marks' and 'tags' boxes don't load for me, meking it impossible to find back my cute little efforts at office procrastination :(

</comment><comment><USER14> This is really nice, but what happens once it hits 4Chan?

<comment><USER15> The authors probably know about that, and I think it's part of the experiment. It's much harder to make giant drawings here though, because the entire thing is divided up in little patches; Drawball is only limited by your screen size.

</comment></comment><comment><USER16> I'm surprised by the lack of penis drawing. Is there a review process or do people just suddenly decide to behave better?

<comment><USER16> I take it back. Just found four of them.

</comment></comment><comment><USER17> My browsers do have WebGL, yet the site says they don't. Chrome + Firefox on OS X. Other Webgl sites/games work.

</comment><comment><USER18> Pretty neat. Reminds me a lot of curiosity by 22 cans.

</comment><comment><USER19> This is really cool! I like the message. Aloha!</comment>


RichCopy, an Advanced Alternative to RoboCopy - <AUTHOR> http://technet.microsoft.com/en-us/magazine/2009.04.utilityspotlight.aspx

<comment><USER2> I seem to run into everyone that hasn't heard of robocopy (or at least doesn't use it when they should be) and think, how can you not known about that... but I hadn't heard of richcopy, so I guess I better stop doing that.</comment>