Why You Don't Need A Programmer | Hacker News Reader

Why You Don't Need A Programmer

thinkopen.ly

146 pointsbendingoutward97 comments

I think, and maybe here I'm stating the obvious, that a big problem is how people sometimes think that their idea is the real deal, while the implementation is just a matter of paying somebody.

I think that most people don't realize that most ideas aren't original, and that if you think of something, just by sociological statistics, most likely somebody else has already thought of it.

So what really matters isn't a detailed plan, but a person who builds it well.

Making a very good programmer a technical co-founder is probably the best move.

Giving away 30% of your startup, but locking in a very good technical person, is probably going to give you more success than that 30% that you wanted to keep.

Maybe somebody can point at some statistics, but I feel like that it shouldn't be difficult to have a rough idea of the success rate of technical founders' startups vs non-technical founder ones.

My experience is that usually people haven't actually thought their ideas through. Not even the parts that are within their grasp to imagine and design. In trying to implement stuff, or just in preplanning discussions, you as the programming are always asking, "So what about here? What should happen in this case?" And then there's a pause making it clear the person has never considered this, then they throw out an answer like they had thought about it. But after a little while their answers start to contradict, and their idea is not even conceptually possible.

Looking through the list of Hi-tech companies on Wikipedia [1], almost every single company that lists founders' backgrounds have technical founders. Of course the common statistical caveats apply.

[1] http://en.wikipedia.org/wiki/List_of_Hi-tech_companies

To the biz guys here who might think that we're unicorns, I'd like to point out that there are definitely people out there who are very technical and would love to co-found with someone more business-oriented.

We generally have simple conditions for that to work: - you have to respect our work, because for us it's an art form and a craft, although we do realize that creating business value comes first. We spend decades refining this craft and want to take pride in every line of code (even though it might not always be possible). - We are concerned that you will treat us like codemonkeys and it will be a PBH-like relationship, where you'll be asking us for status every day, while doing little to no work yourself. You won't be able to code and optimize a large scale distributed system no matter how hard you try. I can most likely figure out whatever it is that you do with a bit of time and elbow grease. However, I'd still much rather work on the product, which is where you come in. - We're also concerned that you will not understand anything about how software works, and will still insist on having a large say in the day-to-day engineering. You'll need to pick one, either you learn fast about how things work and contribute bit by bit, or you let us run the show where you're not the domain expert.

Amen to that. I'm a programmer and an idea guy (http://ideashower.posterous.com). But what I sorely need is a bad ass bizdev who I can team up with and git r done.

"while doing little to no work yourself. "

Why that assumption?

Added:

"I can most likely figure out whatever it is that you do with a bit of time and elbow grease."

Have you? Or are you just assuming that as well?

Regarding the first question, I have been burned before by non-technical co-founders who turned the project into their own little "I want to learn how to program" experiment, while spending zero to no time actually hustling, talking to people, getting feedback, finding more early adopters, engineering requirements and so on. I have learned to be a better judge of character through that experience, and am much pickier now.

About the second one, I was actually paraphrasing something I heard Max Levchin state at one of his talks years ago. Not sure how much it's worth, given his partnership with Thiel.

I have another possible explanation for that first question, and I am making the assumption that I'm not the only person that has had to work on not feeling this way:

Even though we really shouldn't feel this way, a lot of us developer sorts wrestle with the idea that we're the only ones ever really working, specifically in the pure development phase of a project.

Granted, I'm sure everybody feels that way at least once during a given venture. I've forced myself to stop thinking that way, but it seems a fairly human thing to think.

Already said (far) below in this post, but the work on the part of the technical team to produce an MVP is often front-loaded, which means that the technical person (team) assumes most of the initial execution risk. Equity distribution should recognize the assumed risk.

If the technical person does not execute on the MVP, the idea guy mostly out only lost time-to-market. On the other hand, if the technical person delivers, he/she is now "all-in" before the idea person typically contributes meaningful execution-value towards the business.

Its probably most fair to view the first "execution" contributors (technical team building MVP) as the first investors in the business, and therefore should be recognized with more favorable terms (equity distribution). If the idea person can create actual execution value in tandem with the MVP, then an initial 50/50 split is fair.

If you have an "idea" person, you're screwed. You need a product person. I don't know how to code, but I can help with wireframes, customer interviews, feedback, marketing plans, pricing strategies, partnership opportunities, etc. The very idea of an "Idea Person" needs to go away and people need to be accountable to providing value. And you don't need an MVP for the Product Person to start working. And I use that term very loosely. Because if they aren't building the product, they should be supporting/defining/selling it.

Why shouldn't we respect each other's work simply because we're people, and we suffer when we try to cooperate with those who don't respect us?

Doesn't this go both ways?

This puts into words very clearly my feelings and experience. I have a friend (very smart) who graduated top of class MBA. He has a 'co-founder' with him working on their idea who is also an MBA. They are looking for a coder, and offered %5-%10 stake in the company for virtually building the whole app and everything with no salary. Completely warped view of an app/online service startup.

Of course they would have every right to give me no equity if they payed me the going rate of 100k year.

Is that the going rate for a job that has a high likelihood of not existing in a year's time?

I don't think I understand this question. No job you take (in the U.S.) is guaranteed to be there in a year's time. You might work for a month (being paid a month's salary) and poof the job's gone - company folded, political bullshit got you caught in the crossfire ... whatever.

You keep a fraction of your income in savings for just such an occasion. You add that month to your résumé and move on to the next job that might not last. This assumes you're not the reason you lost the job, of course.

If you know where jobs with guaranteed longevity exist, please give the rest of us some pointers.

The parent's point is that some jobs are more likely to disappear than others, for example working for a company that seems likely to fail. And when the risk is higher, the skilled programmer might justifiably require that compensation be commensurately higher as well.

Too often in discussions of risk management, someone points out that I could be hit by a bus.

Its a very different statistics, the chance of your job being around vs the chance of the company being around, in a year.

Jobs come and go all the time, even at Dell, even at GM. Rockwell (has a local plant in Cedar Rapids IA) hires and fires hundreds of engineers yearly, as the contracts come and go.

He wasn't talking about guarantees, just likelihood.

Depending on the area, sure. Not everyone gets Valley rates.

Why do the technical people always seem to get the short end of the stick? I have people approaching me on a monthly basis with their 'great idea' and 'all I need is someone to code it', and compensation varies from 'money when it gets big' all the way up to a very enticing 20% equity. After working on a few of these I now ask for cash up front, no equity. I have plenty of my own ideas and not enough time to work on them, tvym.

Technical skills and business acumen aren't necessarily the same thing. Technical people have a tendency to discount the market value of their abilities because they often seem "trivial" once mastered. Also time spent developing technical skills often comes at the cost of developing interpersonal skills that are important at negotiation time (and for detecting BS).

But anyway, my sense is that a lot of these "needs technical co-founder" people have sufficiently poisoned the well that it's getting difficult for them to find bright, bushy tailed nerds still naive enough to accept their terms.

Now if only programmers would demand what they're worth from the game industry..

On the subject of triviality, I've made some discoveries about demoing software to non-programmers. Of course a pretty appearance is very important, but even in just describing features, how hard they were to implement is of zero interest. And what you can sell people on is stuff that is absolutely trivial, or even stuff that is commonplace and every competitor out there does just as well. You feel like you're going to be found out when you brag on the fact that your bike design features a foot activated swing-down ground support to hold it in a vertical position when not in use. But people eat it up.

That's a really good point that I've begun realizing more frequently in my work. People are blown away by most things, and there is almost no correlation between how difficult the problem was and how amazed they are. In fact, I frequently find that the easy stuff tends to impress more (simple UI tweaks, small jQuery animation).

I try to get my highly technical kudos from my technical friends, because my non-technical co-workers begin to glaze over when when I really want to talk about something tricky and fun I did.

We often do get the short end of the stick, and the article addresses that bit, but probably not clearly enough.

The message that I've taken away from it is "dude, hustlers need hackers and hackers need hustlers, so equal footing is probably a good idea."

Heck as far as I can see I can't see the value of the business person at all, except for whatever connections he has.

Now I am biased, but why would one go into a partnership with a business person in the first place.

Yeah. I think a business founder looking for free tech work has already failed the first test as a businessman: He hasn't been able to raise the $40k-$80k in seed funding needed to build an MVP.

If he can't convince a guy who doles out capital for a living to give him a tiny bit of it, why should he expect a programmer to front him that value in highly skilled labor?

Then they've failed the second test - getting a good programmer who doesn't want to leave.

A programmer on no pay with 10% equity is bound to be look for a new position if the company goes through a rough patch (hint, it will). A programmer with 50% equity will stick it out.

Alright, let's say that business founder gets $60k in seed funding. Would a technical cofounder expect that $60k as salary or towards some specific asset for the company? I don't think that $60k of seed funding is what stands between a businessman with his idea and success.

I would think he would invest the $60k towards things needed to make his idea into a business. For an internet company, software development is going to be a major component, although there are others, like design.

Point is, there are people structured to accept risk. These people include investors and entrepreneurs. There are other people who provide services that businesses need, including designers, lawyers, programmers, etc. These people generally aren't structured to accept risk, they need an hour's pay for an hour's work.

Because programmers can often be confused as to what role they play in a business through fast-talk, there's this notion that has developed that there are lots of programmer/investors available, who are willing and able to accept risk in lieu of payment.

There are clearly programmers who will accept that arrangement at least once due to their naivety, but they they generally learn pretty quickly, and I think it's becoming more common knowledge in the programmer community that it's an arrangement best avoided.

I think the notion of programmer/investors, as you put it, is mostly wishful thinking fueled by a basic lack of experience. Until people get burned, they don't realize that what you can get for $1500 on elance.com will, when it fails, end up costing you more than what you'd get for $15k from a skilled developer. If you flip the equation, you could say it's the clients who are naive until they've actually managed developers a few times and seen what they can expect for their money.

> Now I am biased, but why would one go into a partnership with a business person in the first place.

Because they know the bureaucracy and can get on with handling the paperwork and legal admin while you get on and do the actual work?

If they do actually know how to handle the business end, then they are in fact valuable, but that is assuming much.

A lot of the "business-side" cofounders you run into in the real world are just glorified "idea men", willing to "generously" cut you in on 5% if you just code up their "Facebook, but for Cats" site they've been thinking about for the past year.

lol. Facebook for cats.

Reminds me of Pets.com

I've actually heard a pitch in the last year that was "Facebook, but for college students."

I may have died a little inside.

From my own experience for the same reason why architects work with construction engineers. If your business person is actually the pointy haired manager type, well then you're screwed.

But that's not all a busíness founder does. For me, these guys are providing the market, the process knowledge and the knowledge about the needs of certain markets, espacially when the markets are not merely apps for Android and iOS. When your product is aiming at non-tech market, let's say health care, as a programmer you better have a co-founder who knows his trade since in these occasions programmers usually are only the guys crunching through poorly specified code.

Equal footing is the way to go. respect the skills of each other, and at least as important understand the language and the needs of one another. Being able to do X or Y doesn't necessarily make you a better person or founder, you know?

"business person" is very broad. Same as "programmer". In each group there are wide differences in abilities. Certainly if you're good at anything (boating, photography, skiing, programming) you've had people who don't know anything about those things think you are the "expert".

The right business person can be a tremendous benefit. The wrong one can kill your business. Obviously it all depends.

Aside from connections, any partner who can help you get to market faster with $ from real customers is going to be worth it.

Obviously there's a lot of BS "biz" folks. A good barometer is if they have taken the time to learn the skills needed to get their own ideas to market (coding, design, w/e)

I thought this was going to go somewhere else. I was totally excited until the sixth paragraph - the first mention of the technical co-founder. The author got it all wrong. The main downfall is that, as a non-technical person with an idea, you aren't just going to go and find a technical co-founder out of the blue. It's highly unlikely that you'll find a techie who will drop everything to work with you on your idea in hopes that you will both someday strike it rich. And if you do find a guy like this, they're probably a bit delusional.

The technical co-founder has to be built in to the core, a part of the equation from the very beginning. Co-founders (technical or not) have to be compatible. You can't just go and find a technical co-founder on the street. That doesn't work.

Now, instead of getting emails inquiring how to learn to program, I'm going to get emails that say "Hey, I have this great idea but I need a technical co-founder. I read your blog and I know you can code. We'll be rich. What do you think?"

What I don't quite understand about this piece is the motivation for saying that the biggest value-add would be to 'kindly inform the person that the correct term is 'co-founder'" (I am purposely trying to keep this comment symmetrical by leaving out "technical" here...). Why would it be valuable or even 'charitable' to do this? Them calling programmers 'programmers' or vice-versa has no negative effect for the named person- IN FACT it has a large positive one as it marks those people who don't have proper respect for their counterpart co-founder role. 'Kindly informing' the transgressor of such a misphrasing is like giving them the secret password without them having earned it themselves via a proper, self-driven cultivation of proper respect for their counterpart role.

I think this comes into the "You don't find a technical cofounder, you earn one." category. And trying to get a programmer to build this for you without even giving them founder recognition or founder shares is absurd. No one will work for the biz guy who wants to outsource all the work for meaningless amounts of the company. As a Biz guy, the person who holds the biggest share of our company is our technical co-founder.

I liked this piece. I'm a designer, not a programmer, but I a lot in this piece would resonate with designers as well. So many times I have been asked to illustrate or design something, in exchange for "exposure" - "how great this opportunity is to get your design out there." One thing that I disagree on this piece is that I don't think there is a specific formula: that "you need" a technical co-founder and a business co-founder for a startup to work. Although programming is obviously a big part of this business, in my view successful entrepreneurs can come from a variety of backgrounds, and make it work - it's more about how they can draw from their backgrounds and how they can learn/contract what they need in order to make the idea fly.

Also depends on the particular idea and what you are trying to do. It is entirely possible to start a business, hire someone to do the "programming" and make yourself a nice living. Not every idea needs to knock it out of the park and result in multi millions. And as everyone knows most will not.

I get the point, but there's another side to this:

9 out of 10 of all startups out there are a business method, they don't need 10x engineers to build new technologies, and what they want can be done by a freelancer using a CMS and some elbow grease.

A freelancer capable of "CMS and some elbow grease" has a few attractive options right now, including building "CMS and some elbow grease" for clueful clients who will compare his invoices to the change in the bottom line and pay accordingly, or taking "CMS and some elbow grease" and getting seed funding for it, or going to one of the numerous companies selling "CMS and some elbow grease" who are desperate for engineers and saying "I have two years of PHP experience and have shipped products. You are looking for an intermediate engineer. How much do you offer?" and then getting offered $120k plus benefits on the spot.

Periodically, I get a cold lead asking for work. A half dozen recently have been for Twilio development. The projects are typically not terribly technically challenging: solving real business problems for money, good ideas, probably 6 man-weeks on average. I quote my usual weekly rates (in preference to saying "I know where this conversation is going. The answer is no.") and regularly get told that a) I'm out of the budget and b) 5~10% of this deal would make me rich.

I am polite in the emails but, just between us geeks: that's cute.

P.S. Do you do Twilio development? Need work? Find my email, I'll filter out the jokers and pass you anyone who sounds serious. Do you do "CMS and elbow grease"? Pick up Twilio and double your bill rates. Or just double your bill rates.

Sent you an email.

I don't mean to discredit the content of this post, but is anyone else tired of this argument circling around HN like a windmill? (Why you need a technical X to launch your idea). If the title of this post were (perhaps more appropriately) titled "Why you need a Technical co-Founder," I don't think this would have gotten any eyeballs.

When I first clicked this article, I thought it was going to be linkbait. I was surprised to find that he concisely and accurately expressed what I'd been unable to for the past few years: that non-technical founders shouldn't look for "programmers", they should look for "technical cofounders". This is after reading many articles on HN stating the exact same point, just less to the point. I'm slightly embarrassed because people sometimes come to me asking for a "programmer" reference, but I've never able to concisely tell them what why their question was wrong to begin with. The way he phrases the problem captures almost all of the talking points, and it's the phrase I'm going to use going forward.

Good piece. I've talked with numerous people looking to start a startup with the assumption that implementation is just a case of hiring a few devs or outsourcing to n freelancers.

I especially liked the wake up call to developers at the end. Would be very interested to read any reciprocal articles on why technical founders need a business co-founder.

Totally agree, I'd love to read a reciprocal piece. I think programmers (myself included) often feel that a non-technical person can't write a single line of code* whereas a technical person can figure out enough of the business and product side of things and make up the rest as he goes along. A lot of times this works out, but I'm sure there have been many cases where a failed startup might have succeeded if they'd had a good non-tech cofounder and made better strategy decisions.

* unless he/she decides to learn to code well enough to hack together an MVP, but that's not what the article is talking about

A smart programmer can B.S. his way through business. However you can't B.S. your way though programming and still make it work. The worst possible idea I could think of is for a non technical founder to try and "hire" someone unless it is a really simple app. Implimentation > Idea

Some Reasons Programmer Co-Founders Can Be Picky and Elusive

1. Risk is typically front-loaded for the programmer so they have to be more cautious. A programmer with no skills is much easier to spot early on than a business person with no skills.

2. The "programmer" role can often include many tasks that have nothing to do with programming. Often times "programming" means UI, UX, server management, DB management, server-side coding, API coding, website coding, and mobile development. For really inexperienced business co-founders this role may also include business card and flyer design, video demo creation, and remembering the company Wifi password.

3. 10% equity after doing 85% of the most important work is not a good deal, especially in a market where you're skills are in high demand.

4. Quality programming is not a commodity. Programming is more akin to painting or novel writing. A programmer may have an idea or possibly an outline to start but when the time comes their still free-styling most of it while forming new ideas as they go.

5. Technical co-founders are often willing to learn the business side of things. Business co-founders typically want nothing to do with learning the technical side of things.

This is a tired sentiment in the valley. There seems to be a power/control needle that swings back and forth between the business people and the technical people. The truth is you desperately need both.

While we're all familiar with the "I just need a coder..." stories, there are at least as many coders working on projects that have zero business prospects. At the moment this is actually the greater sin as technical talents are in shorter supply so dedicating your (limited) resources to an idea with no long-term prospects is basically shooting yourself, and the valley, in the foot. You'd be much better off partnering with a business co-founder and raising money.

On the other hand, Silicon Valley has a long history of exploiting engineers and we're all right to be incredulous when working for limited equity and no salary.

I am surprised to see this question resurfacing last half year because I think that the answer to this question was pretty much nailed down by Vinicius Vacanti in his blog post in Sep 2010 http://viniciusvacanti.com/2010/09/27/should-you-hire-a-prog...

In short - it depends on the nature of your start-up and the challenges your start-up is tackling. Depending on those you 3 options:

1. Find tech co-founder (and don't do start-up w/o such person).

2. Learn to code.

3. Outsource the programming.

If your case is #2, then read the guy's post http://viniciusvacanti.com/2010/09/13/cant-find-a-technical-... and some other posts in his blog.

I work at a typical web agency and in my experience one of the red flags for a project is the entrepeneur whose company's success relies solely on the website that we build for them (as opposed to most of our other customers who are building a website for an existing company). Hiring an agency to build a startup is a recipe for disaster. As well intentioned as they might seem, the agency just can't care about the project as much as a technical co-founder is going to care. Often when the business model turns out to be crap and there's no money left, the agency is blamed for building a website that doesn't "work".

I used to be of the opinion that the technical people did all the hard work and hence they should get the majority of the equity. However, once I tried to do everything myself I realised that the technical side was only one piece of the puzzle.

Business, design and marketing may not be as intellectual as programming but they are no less hard and often more important.

I really think that if two people are involved, the equity split should be 50/50 regardless of the skill set each one brings. If the equity is unbalanced, the level of effort each founder brings will be too.

1. Whether they're "no less hard" depends on who's doing it.

2. Many people claim they can do these things (at least, the "business" and "marketing" parts) - hence the surfeit of "nontechnical cofounders". But not all of them can.

3. There are fewer potential technical cofounders available in most areas.

4. Therefore, as a technical cofounder, you should pick only the best nontechnical partners, who will justify an even split of the equity. If you really don't find anyone who measures up in terms of demonstrated ability to hustle, connections that can actually be used, great business plans/prototypes and/or an impressive work ethic, then is it really worth starting up with a mediocre-or-worse cofounder?

5. If you insist on taking a nontech cofounder and you have only multiple mediocre suitors to pick from, it makes sense to me to offer less equity. If your potential partner feels it isn't fair, then look for someone else who understands that the product makers have precedence in this market.

Personally, I think making a good business plan and doing marketing may be as hard as programming at times, but at this time, more people claim to be able to do business-side things than coding. That fact in itself justifies the tech cofounders' being picky with their partners.

I think tech cofounders shouldn't let the thought that "oh, they work as hard as me" mislead them into partnering with someone who doesn't have capabilities that equal theirs, adjusted for supply and demand.

The problem is that, often times, much of the technical work is front-loaded, leaving most of the initial risk disproportionately in the technical person's lap. It's only after an MVP is built that the business side of the operation has to perform. Equity split should reflect the assumed risk.

That’s a fair point. However, there could also be front loading in the business role. Sounding out the market, figuring out who your customers are and what they want - the sort of stuff that should be done before writing any code. Isn't that still a significant amount of work?

This is exactly what I've been experiencing. It's been immensely difficult to find a technical co-founder so I've resigned to have a programmer build the basic prototype...

Ditto. Business founders need to be able to pitch to investors and customers, to even garner that initial interest. Since there seems to be an inflation of technical cofounders' "unwillingness" to partner, there's no other choice than to outsource development of an MVP. At least with that, you can get customers, and thus traction. At that point, there's less risk and thus less available equity for a technical cofounder. Nowadays, it's either you have a technical cofounder or you don't.

Very insightful. Originally I was thinking along those lines and trying to find someone to simply construct what I'd dreamed up. Once I formed a team and we became equally invested in our work together, things really started to move.

Are programmers really willing to put together a site for someone else while the other person has a view to make money from the idea, even if the programmer is payed at the going rate? what is the going rate?

This sounds like you're asking if an employee is willing to work for an employer who makes a profit off the employee's labor. And that, my friend, is exactly how business works.

So you disagree with the cofounder idea?

A co-founder is not the same as an employee. 1) don't make assumptions about a different subject from the one I'm commenting on; 2) if you actually want to have a discussion, ask a better question.

What about the money? Most technical people is not looking for a risky undertaking but want just a determined salary. This is where the conflict of interests begins.

Is this not arguing semantics? Technical co-founder / programmer / coder / whatever . Someone who produces software?

No, this is not arguing semantics. A contract programmer and a technical co-founder are two totally different things.

Bookmarked for easy access so I can send this out on a regular basis. Nicely summarized and stated.

If I recall, the successful Photo365 app was created with completely outsourced programmers.

A rare exception to a solid rule; outsourcing your core thing rarely works.

Is there a good place to match non-technical and technical founders?

Founder Dating claims to do that to an extent, but you have to apply and be accepted to one of their events.

As a non-tech looking for a technical co-founder, I got fed up with this search and decided I'd be better off just learning to build and code my idea(s) myself. It was actually the questions on the Y combinator app that made me realize that once you push out past the second or third degree of separation in your social network ("oh yeah the friend of my friend of a guy I used to work with can code") you're too far removed from this person, and a co-founder you don't know or can't trust seems like far greater a risk than investing the time to learn to do it yourself. Plus once you build your first project, I suspect it gets exponentially easier to make the next and the next thereafter!

Is anyone getting major Déjà vu from this article? I feel like I've read this exact article before, complete with the linkbait title.

If someone hires me to write something for them I write that for them, if they ask me for advice I give them advice. I don't get into arguments about how their idea won't work, or call them 'stupid', I charge them my rate for the work they ask me to do and I thank them when they pay me.

You think the guys at the general store in 1849 told the gold prospectors that they were stupid and would lose their money? Or do you think they smiled, told them about the guy who just discovered millions in gold, wished them luck and sold them tents, picks, and levis?

That's not the point of the post. The OP is saying that a lot of would-be entrepreneurs are vastly underestimating the amount of work involved in creating the actual software, and that the would-be entrepreneurs need a technical cofounder rather than an employed programmer.

To use your analogy, this would be more like the store owners telling the prospectors, correctly, that they would also need to find legal help to protect any land they found, security to keep them from getting mugged, etc.

I think OP's point to this is that doing that would not be a good business move. I don't believe that in the canonical scenario simply telling the party in question that things are much more complicated than they can possibly imagine and expecting them to accept that is realistic.

I have been a part of projects where first day in discussing the basics of the project the entrepreneur in question has the design "95% complete" which then after the first four hours fluctuates somewhere between 0-20% complete. And all these numbers may as well be randomly chosen for how much of a relation to reality they have at any rate.

Sell them the picks and tents, let them figure it out themselves. When they come back to you with their problems and ask for advice they will finally actually be listening to reason without thinking that their individual case is an exception to the rules and you're just trying to drain their precious equity.

It's true. They won't listen until after the journey. See Wizard of Oz.

So very right. This is why I charge by the hour and refer clients who don't like it to India. They come back eventually, defeated, but you know they're worthless dorm room hacks. Some of them will end up on wall street, and a few of them might eventually find jobs where they actually have to work to, y'know, make something. The rest will live on daddy's trust fund. We're towing them, not the other way around. Screw 'em. Let them beg on the street.

If God had truly blessed these people with big enough brains to come up with brilliant ideas, He would have given them the capacity to learn, at the very least, enough PHP or Ruby to build a wireframe. I don't see how anyone who can't do that could have an idea that would be worth wasting time on.

>This is why I charge by the hour and refer clients who don't like it to India.

Why don't you refer them to people in your own country? Why India?

I'm interested in how and why you would use PHP or Ruby to build a wireframe.

"and that the would-be entrepreneurs need a technical cofounder"

Part of the problem with this idea (as someone else commented "goes around like a windmill") is that a non-technical person is even in a position to judge the skills of a technical person (or vice versa).

At least if you hire a programmer you can fire a programmer. If you take on the wrong co-founder (who doesn't have the ability or skills you thought they had) then what do you do?

Try, try again. Like anything else, you have to take risks.

People who buy into "I can't make all the judgement calls with perfect accuracy" don't become entrepreneurs.

Development work is nowhere NEAR the same as selling somebody something.

It involves defining scope, deliverables and timelines. It involves a long-term commitment from two parties: you to provide skill and effort, and them to support you (because there WILL be gaps in the requirements) and pay you.

In my experience in these "I've got an idea" situations, once you attempt to define the project concretely the client frequently realizes how far in over their head they are and changes their mind. And if you're not defining these things upfront then you're running a very risky business model: if you don't know timelines, how do you know how much budget they need to afford you? If you don't whether they can afford you, you're taking a big chance accepting the project.

(And if you are defining these things and realize the guy isn't going to succeed but take the work anyway without warning him, you're unethical).

You've not been a contractor? All you have are hours to sell, and its very similar to selling a pick or shovel.

Unethical? If you had a crystal ball that could predict the success of every new idea, sure its unethical to keep it secret. But just because you don't personally think its a good idea- well, it'd be unethical to put your bias in the way of this guy succeeding despite your doubt.

I am an independent contractor.

There are two types of contractors, and I have been both:

1. The "warm body" that does indeed just sell hours, usually via a labour broker or development house. They fulfil a "development resource" capacity required on the project, and typically there is already a project structure (plan(s), schedule(s) and management) in place. They are not directly responsible for the deliverables of the project. I am a warm body contractor because (2) freaks me out.

2. The "development house" (can just be one person despite the term) who initiates and manages the project in addition to doing the work. They have to define the project, agreeing on scope, timeline and budget because they are party to a contract and are directly responsible for the deliverables. If they screw any of these parts up (and that includes due diligence, e.g. can the client actually pay them, and how can you answer that question if you have no idea and agreement on project duration?!), their business stands to suffer losses. This has nothing to do with predicting success -- it has to do with contractual obligations and legal liability. They get to charge higher rates than (1) because of this additional skill required, risks involved and the associated differences in supply.

If you are a non-technical entrepreneur with no idea how to run technical projects and you seek out a warm body, you will get burned because that is not what you need (and this is part of what the linked article is about).

If you are a warm body who accepts such work - just selling hours and not a plan, a schedule and budget, yes I believe you are unethical because you are not ultimately providing what somebody expects, despite knowing their expectations, and that's the definition of misrepresentation (it's like selling somebody a car without a working engine and not stating that anywhere).

If you explain to them the risks, give them a plan that you honestly believe you can meet, and they still want to go ahead, shrug that's fine. But if you just say "yah I'll build it" knowing full well it's not going to be useful, or worse you're too naive to know how to manage projects but you're selling yourself as a professional developer that'll deliver, you're unethical.

I've been #2, and always explained the risks, options and my estimate of success. I Always recommended the MVP approach. I felt fine about what I did.

Warm bodies don't often choose their projects. Its hard to call them unethical when they're helpless to choose.

And its really hard to 'know full well its not going to be useful', isn't it?

Ditto, I too think this discussion is a bit tired. It's a free market, if someone agrees to do something for a certain pay, let them. Obviously, in most cases, you are going to get more commitment and possibly even higher quality work from said person as a co-founder. It all depends on what you need. There are thousands of examples of successful projects with hired work (I can speak for the European market), just not so many on the web, but I would guess the lack of success in that area correlates with other factors.

You sound like a mercenary, which is fine for those without viable options.

However, the article is saying the chances of success is higher if you find someone who also believes in the vision.

The approach you suggest works fine in the short term: most of your customers will fail, but only after paying you, and there's a line of suckers behind them.

However, in the long term, if you help a customer thrive by helping them understand what they really need, you might make a bit less off that customer right away, but you'll have a customer for life, and many more where that came from via word of mouth.

I don't think they are suckers, I just have no idea which will succeed and which will fail.

I always try to leverage my expertise to help them but at the end of the day the customer is always right.

You know, this post had me nodding in agreement up until the last paragraph:

"Note: I could easily switch this whole article around to all those programmers that think creating a company is as simple as launching an app. You’re just as stupid, so start asking for someone to help you grow what you’re working on, ask for a co-Founder."

No. Frankly, we're not just as stupid. It's not as if just because marketers can't figure out how to program, the inverse is true and programmers for some reason lack the creative thinking skills to come up with new ideas or the capacity to market their own product.

Non-technical founders may have some purpose, but to a coder with marketing ability they're redundant, and worse, in the way. So no, you can't just flip it around; to say that a programmer who goes it alone is "stupid" is, above all, a very stupid comment.

It's not about having, or being able to develop 'marketing skills'. That's too shallow a sketch of all the tasks a non-technical founder fulfills. I'm an employee of two technical founders that have developed all the skills necessary, but if I see which they are and which tasks they fulfill (all kinds of business administration, HRM, legal, PR, sales, marketing, company strategy and planning, procurement, CRM, etc.) then I would be glad to be able to let a future non-technical co-founder that actually likes a portion of that stuff deal with that. They hardly have time to code anymore :(.

So, in short: a non-technical co-founder fulfills many tasks and likes them. A technical founder would be smart to associate with a non-technical founder, so both can do what they're good at.

Agree. When I go out to start a company (I've started 3 failed companies) I went to my lawyer and accountant, a marketing person from the local business chamber, I asked their advice, and followed it.

For some reason the people on the business/finance end seem to think they can just delegate everything and know how everything works based on whatever they heard in the news. They already decided on using the cloud, thats the hard part! Actually using it is just implementation right?

Let's put it this way. We've all heard of the lone programmer who built something entirely alone and made a million bucks from it. We've never heard of the lone businessman whose idea grew legs and programmed itself to make the guy a million bucks :)

Actually, that's not true at all. I personally am a non-programmer, who've hired people to write my code for me, and built a successful company that now employs many people. I wish I had a technical co-founder, for all the reasons mentioned in this article, but most importantly, that technical solutions would be solved by someone invested in the company and from their domain of knowledge. As it is, I have to come up with solutions and ask my for-hire freelance developer to code it for me. It's been successful, but it could be so much more.

But, this in no way means that a non-programmer can't go it alone. I have, and am now doing it. And in the case of the lone programmer building something entirely alone and making a million dollars, what's to say he wouldn't have made $4 million dollars had he a non-technical co-founder?

I think your line of reasoning is equally as incorrect as you're implying the OP's was.

The only point I'm making is that a non-programmer has to hire someone to do the work or learn how to do it themselves (and thereby become a programmer).

In my experience the latter is a hell of a lot more rare than the programmer learning business skills. Consequently it's far more likely to see a programmer developing a successful business solo than a non-programmer developing a successful business solo, so in my opinion you can't just flip the argument around and say it works both ways.

Note I'm not suggesting that a co-founder isn't important or valuable, simply that the argument cannot be flipped around; I'm personally looking at recruiting an old friend once my product reaches MVP because a co-founder is important for some products.

I'd say it's more about having time to do all the marketing and similar tasks.

Reply on news.ycombinator.com