FWIW, no one is indespensible in a startup; some are merely harder to replace than others. I'll bet that "original idea" guys are getting equity even though they cease to be indespensible.

I have been in too many startups that died because they lost or failed to recruit one particular person---or in the case of LMI survived (for a while) because I recruited one indispensable classmate who made their LAMBDA processor work---to believe this.

A reverse example would be the receiving clerk at Intel who single-handily almost killed them as mentioned in Chringley's book.

In my experience, just about every founder of a startup is "indispensable" after you shake things out a bit---make a single mistake with any of them, and you're not likely to survive.

I suppose that means this is an "appeal to authority", but, still, if a person critical to making software work is gone, and the company fails specifically because they can't make their software work, what else am I to assume?

(Needless to say, sometimes I've been that person.)

They leave as soon as something better comes along. Giving them equity [with vesting] prevents that from happening. If the person is okay with just a salary, he'll go work at Microsoft or Google and additionally collect the "intangible" benefit of job security.

These aren't difficult concepts.

Economists like to divide all spending into two categories: consumption and investment. Consumption is spending for things you'd like to have now, that'll give you an immediate benefit. Investment is spending for tomorrow, in the hopes that you will gain more benefits later.

Technology organizations face the same tradeoff, but with time rather than money. Developers can work on features that immediately benefit users and pad the bottom line (consumption). Or they can work on refactoring, infrastructure and tools that will make it easier to add features in the future (investment). There's always a tradeoff. If you spend too much time on investment, you're customers will wonder why you haven't done anything for them recently and stop giving you money. If you spend too much time on consumption, you'll wonder why it suddenly starts taking 10 times as long to implement each feature, why the system is grinding to a halt, and why your developers have no clue what's causing your latest dozen bugs.

In my experience, the best developers spend 80-90% of their time on investment and 10-20% on consumption. They'll apparently do nothing for 3 months and then crank out an app in a week (for an extreme example, check out PG's On Lisp: he writes a whole book on building up tools, and then in the very last chapter, he's like "Oh, by the way, here's a Prolog interpreter. In 50 lines. Done"). The worst programmers reverse that - they'll spend 80-90% of their time implementing your feature requests and only 10-20% cleaning things up, moving common code into functions, etc.

So here's your problem: under U.S. law, all "investment" that an employee creates is owned by their employer. Meanwhile, their salary is dependent upon how good you think they are, which depends upon how much they've done to improve the bottom line. In other words, they have every incentive to "consume" (push out quick features for the boss) and no incentive to "invest" (clean up code, setup infrastructure, build tools). The only way to rectify this is to make them part of the company's capital structure, so that they are effectively part-owners of the code they build.

You might think that you know better and can compensate people based on how well they actually do, but in practice it's virtually impossible. Ask yourself: how would you feel if your development team did nothing for 3 months. Because that's what it'll look like if they're doing their jobs properly. You say that you've got a terrific programmer who's working for no equity, but you're seeing him at his best. It's easy to crank out impressive stuff on a small green-field project; it's much harder to keep it working as the project grows. The choices he makes now will determine the future development of your software, even if you fire him and get someone else later.

Don't do this to your startup. If you're a tech company, spend your equity getting a top-notch tech person, then give him the discretion he needs to do things right. Otherwise (assuming you've gotten all the marketing/PR/idea stuff right), I can predict the path your startup will take. You'll get lots of buzz and lots of users, and they'll love you for cranking out features quickly. You'll dominate the market. Then, about 1-2 years in, you'll hit a brick wall, and every feature you add will result in lots of mysterious bugs. Fixing these will result in dozens of new bugs, and you won't be able to add any new features at all. Competitors will arise and start catching up to you. You'll fire your tech team, thinking that they must be incompetent. You'll start a rewrite-from-scratch project, which you'll abandon when your investors come calling. Then you go out of business.

I've gone through it once and probably would've gone through it a second time had I not just left my last employer. It's not pretty.

That's not such a big deal with JS, but it's a very big deal when your backend is in the toilet. You may as well flush.

I am not involved in any startup but like to do my job with creative energy and scripted quite a few time saver solutions for my group. Until now all my manager were thoughtful enough to allow me but this new guy thinks that he can replace any person with any person without looking at the unique attributes of each of the person. He wants me to do the work others can do without looking at what i can do and others cannot... I am sorry but you are sounding like my manager so get a job in big company. Startup make you respect your talent and looks like you do not want to do that... Coders may be dime a dozen but believe me true developers/hackers are not...

But if you want someone to work a practically unlimited number of hours as is most often the case then you are going to either need to pay the person to work two 8 hour shifts, hire additional programers, or give the programmer some equity in the business.

Hacking doesn't work that way; software engineering does. If you don't understand the difference, your startup is in trouble.

But beware the code that is written it will be hard for another programmer to pick up on. Everyone writes code differently and it is just suprising in one language how many different ways there is to create a solution.