Hacker News Reader

Comment by mikealle233 | Hacker News Reader

I don't understand why all those product and marketing people don't form programmerless teams and cheaply outsource their initial programming needs.

This won't work for immensely complex ideas, and it won't produce award-winning code, but it'll be good enough to create a minimum viable product and see if it has traction.

If it does get any traction, THEN they can worry about finding a programming partner, and the question of what they bring to the team will be clear -- a business that has already shown traction.

View on HN

I don't understand why all those product and marketing people don't form programmerless teams and cheaply outsource their initial programming needs.

Because most of them are too broke to do that.

Moreover, when they do have a little bit of money, they're likely to get taken to the cleaners because of their inability to evaluate and manage a technical team, especially a remote one.

There's all sorts of problems with this. Usually startups don't have enough money to hire good developers, so they try to pay people in equity. Most developers who aren't personally invested in the idea or the founding team aren't going to split equity with non-technical people unless everyone is clearly bringing something to the table (marketing, fundraising, etc).

Unless there's a clearly even split of labor in the early days of a startup, the technical members of a hybrid team are taking the majority of the risk. To get the company on its feet, they'll need to sink a correspondingly large amount of time into developing the product versus their non-technical cofounders.

Software is very expensive to build. Let's say that to take an MVP from zero to market will take only one man-month of effort (160 hours) -- which, when you consider billing systems, etc. is likely a low estimate. If you paid a good consultant $100/hour to build it for you, that's about $16,000. Many startups don't have this kind of cash sitting around.

So let's say you outsource the development to offshore developers to save some money. Let's say you start to get some traction, and you want to bring on a technical co-founder. It's going to be a really hard sell to get a developer to join your project after your product is already poorly-written. Developers hate maintenance. If a group of non-technical people approached me with a post-launch MVP, I'd assume their code was bad and run for the hills. (At a minimum I would ask to see it before agreeing to anything, which would likely just solidify my viewpoint.) If you're willing to throw out the MVP code and have the new cofounder rewrite it, that might be something you could convince a developer to join up for -- but be prepared to "lose" the money for the initial MVP development.

It's not enough to bring a "business that already has traction" to the group. Maybe if you were selling me the MVP, that might be interesting, but if you were looking for a partnership, I'd want to know what you'd spend your time doing.

"Software is very expensive to build."

Not necessarily. Offshore outsourcing of programming is quite cheap. The question is whether your MVP is so complex it warrants a $100/hour local programmer to handle that complexity. In many cases, it's not complex enough to warrant it, and paying $100/hour to a developer is inconsistent with building a MVP, because you're hiring a bells and whistles developer better suited to a large corporation with millions in profit at stake if the developer screws up. But, sure, if you're building something complex, you're shooting yourself in the foot by cheaply outsourcing.

"If you're willing to throw out the MVP code and have the new cofounder rewrite it, that might be something you could convince a developer to join up for -- but be prepared to "lose" the money for the initial MVP development."

That's exactly what I'm proposing. Who cares if you "lose" the money for the MVP development? If the MVP has shown traction, you haven't "lost" the money. You've paid cheaply for a traction proving MVP. That is money well spent, and now it's time to move onto the next level.

In any event, the idea that a developer would turn down an opportunity to be a founding equity member of a startup, which has a product that's already proven traction, because the MVP contained messy code is absurd. I'm not saying some developers wouldn't think that...I'm saying such developers are irrational.

"...but if you were looking for a partnership, I'd want to know what you'd spend your time doing."

Your attitude puzzles me. You have two hypothetical choices, if you were offered such a partnership.

1) Say no and continue to build software with a 90% chance of failure.

2) Say yes and build software with a 90% chance of success.

Even if the non technical cofounders sit on their asses and do absolutely nothing while you code all day, you'd be sitting on 33% equity in an already successful startup, when they took all the cash risk up front to prove the thing works. All you've got to do now is code and build on existing success. And you think that's an offer that you should scoff at?

In reality, the non technical cofounders wouldn't sit around and do nothing. This would be a group of people who've already proven they can go from zero to traction proving MVP on their own, and surely they'd continue to work in non-technical ways to make the product a success. I don't understand why you'd be so skeptical about what they'd do with their time, unless you think their success was dumb luck.

I think your idea of throwing away a prototype is a great one. We essentially did that when we launched our startup, although it was just a major refactoring rather than a complete ditch-and-rebuild effort.

Beyond that, oh man...

It's this mindset that makes a lot of would-be technical co-founders see non-technical people as a threat. I don't care if you're a technical or non-technical co-founder, if you're not going to pull your weight somehow, I don't want to be in business with you.

Also, to be honest, the "cash risk" is essentially irrelevant to me because I have the skill set to build and validate the MVP myself. There's also a large enough market for my skills that I could sell consulting services (yes, at north of $100/hour) to cover any financial costs to test an MVP.

All you're really bringing to the table is the first 3 steps, and asking your technical co-founder(s) to handle the next 617 or so. It's better than just a "big idea", but not by as much as you're thinking.

All you've got to do now is code and build on existing success. And you think that's an offer that you should scoff at?

Oh, is that all?

Here's a hypothetical scenario: let's say Toyota builds a concept car and takes it to an auto show to demonstrate it to customers. They get fantastic feedback and decide to take the car to market. So, you'd be willing to take the concept car design and find a way to manufacture it in an efficient and cost-effective manner? I mean once the customer validation is done, all that "engineering" stuff must be simple, right?

Metaphor aside, an MVP is vastly different than a truly sustainable product. If it's a true MVP, there will be a myriad of unsolved problems (scalability, maintainability, etc.) that only a skilled engineer can solve. Not to mention, what happens when the market inevitably shifts, rendering some or all of your customer validation effort useless?

The most important aspect of any startup is the dynamic of the team. The most important part of that (in my opinion) is to have clearly delineated roles, roughly equivalent in workload and importance. The best teams have members with complementary and supplementary skills, and everyone respects the skills and contributions of everyone else.

My attitude puzzles you because you're assuming that 90% of the risk comes before the MVP. Launch is very different than break-even, which is very different than sustainability or a liquidity event.

I'm a huge believer in the lean startup (I launched and sold one myself) but you have to recognize that the initial customer validation is just the first step down a very long and arduous road. It's hard enough to walk that road in the first place, let alone if I have to carry you on my back.

My attitude puzzles you because you're assuming that 90% of the risk comes before the MVP.

Absolutely, most startups fail because they build something that people don't want. That doesn't mean things like scalability and maintainability don't matter. It means you're putting the cart before the horse if you're worrying about those things before you even have a product that people want.

Aren't your same gripes just as valid against venture capitalists? I mean, all they're giving you is money, and they're trying to take a huge chunk of equity while you have to worry about the next 617 steps?

I'm not suggesting that you worry about scalability and maintainability first. I'm saying that only a fully-invested and skilled engineer can solve those problems for you, and they are probably not interested in working for you if you aren't also working just as hard.

Aren't your same gripes just as valid against venture capitalists?

Arguably. But, good venture capitalists give you not only huge sums of money that you wouldn't otherwise be able to pool, but also advice and access to their professional network.

Arguably. But, good venture capitalists give you not only huge sums of money that you wouldn't otherwise be able to pool, but also advice and access to their professional network.

I just find it peculiar how this entire HN community seems in love with the idea of giving away equity in exchange for money and advice, to hopefully increase the odds that your programming work will eventually turn into a big payday...but you seem completely standoffish about the idea of receiving equity in exchange for working on a product that already has proven traction, which would sky rocket the odds of your programming work eventually turning into a big payday.

In other words, you'd get the same increased odds of success that venture capital brings, but you'd be receiving equity instead of giving it away.

In one case, you're bitter about the prospect the person who increases your odds not putting in as many hours as you; in the other case, you gladly accept the prospect of a person increasing your odds but not putting in as many hours as you.

My question is why you're so fixated on hours of work, and instead aren't just look at it in terms of business opportunity where you can make a ton of money? Hours of work seems to be a bad, arbitrary metric to obsess over.

Where is competition in your analysis?

Yes, there are many possible software products that can be done cheaply with outsourced labor. The problem is, because they can be done cheaply, they are done. Why should anyone use your Groupon clone when they could just use, well, Groupon.

You can go through a whole lot of MVPs and find out that all of them aren't really viable.

And then if it is viable, why should the developer work for you instead of competing with you? If you're throwing away the initial outsourced prototype and starting from scratch, what advantage do you have over him? While you're scrambling to find a technical cofounder to replace your cheap outsourced team, he could just reimplement the thing, plus all the improvements that actual usage has suggested, and keep 100% of the equity. You're just asking to get Winklevossed.

There's a reason why Paul Graham advises people to take a look at their alternatives and then do whatever's hardest. Business is about competition, about having a durable competitive advantage that other people can't easily replicate. If everybody can do it, nobody makes any money off it.

You're missing marketing, sales and business development in your analysis.

Groupon isn't successful because of its programming prowess. It's successful because of its sales, marketing and business development prowess. Groupon is a great example of a startup that's not that complicated in the technical department (or at least it wasn't when it started...now it's large enough to where it's justifiable to bring in programming all stars to make sure scalability, maintainability, etc. are in order).

So, as to why a developer should work for a proven MVP rather than building his own clone, the reason is simple...why is it more attractive to be an equity technical founder of Groupon vs. starting your own Groupon, if Groupon approaches you after it's already gained traction?

This falls through when the business guys try to build out a spec - especially to be used by outsourced developers. They use "human logic" and the bridge between the database and user experience breaks. Spending 10 hours, learning how software thinks, will make these types of teams way more practical and effective.

Reply on news.ycombinator.com