That's what I'd do if I was in that situation... structure it as separate holding companies for the IP or whatever so you can flip each product individually if needed, but don't unnecessarily duplicate resources. Of course you're probably going to get into a world of fun "internal accounting" taking this approach... you will probably want to "bill" the appropriate holding company for time spent working on that project, etc.
You only really need to do enough accounting in order to pay your taxes correctly. You might need more than that if you want to try to go public, but the rest can be repaired retroactively. And if you just sit down with the relevant IRS publications and read through them, you'll find that the tax code isn't as scary as you think it is. A tax return is about as complex as, and makes about as much sense as, a typical Microsoft API.
does anyone know if there is/will be any video or audio to go with these slides? The takahashi-ness of them suggests to me that there might be more in the delivery that we aren't getting with the slides alone...
Agreed... The hardest thing is to cast of the PHPisms and Java patterns that you may be used to, a lot of Rails is idiomatic Ruby code, so really knowing Ruby makes it a lot easier to understand.
Sometimes people can become overly fixated on what's hidden from them. You say you prefer PHP, but when was the last time you looked at the source code for any of the myriad extensions? Can you explain how mod_php works within apache?
Whilst I do think that it's good to have a broad view of how things fit together, knowing what every line of code is doing says to me that you are either working on incredibly trivial code, and/or you're not using existing, well-tested libraries as much as you could be.
not in most startups... I don't see anyone here getting into defence contracting any time soon.
Granted, there are some common sense aspects that are slam dunks (c'mon, version control, why wouldn't you use it) but a lot of it still favours serious software where all the engineers wear dark suits and ties and do big design up front.
Most startups would run out of time and money just getting to level 2 CMMi compliance before they even started to really cut any code.
If you look at it in really objective terms, what is a fair RoI for the paycut you take? Pick a number, if say you want a 5x return and expect to be there for 2 years, that's $200k you should bank after acquisition. if they go out at $10mil... then you want to have at least 2% equity.
Obviously, the longer you hang around, the lower the actual return you get for sacrificing the extra $20k/pa you could get elsewhere. If you wanted to take an even gloomier view, you could calculate the yield on investing $20k/pa, take into account consumer price indexes and any rising market rates. Oh and don't forget the potential for dilution.
Unless your employer is going out in many multiples of $10mil, it's probably better to take market rates elsewhere, and use the extra $20k to invest/bootstrap your own startup on the side :)
"if I had a cofounder who INSISTED on raising VC, he would have to be DAMN GOOD seller for me to buy into it"
The question that has to be asked is "why does he want to raise the VC money?" Unless you need big money up front to build this thing (and you don't seem to think that's the case), I get the feeling that he desperately wants to be seen as an entrepreneur.
Entrepreneurs market the hell out of their product, but "Wantrepreneurs" just market the hell out of themselves.
Or to put it another way, is he in love with the product, or in love with the idea that he's an entrepreneur?
the one thing worse than secret ideas are the "like X but for Y" startups... eg "It's like Digg, but for Nerf Herders! We've done the market research, honest!"
(sure there are exceptions to the rule; "Google, it's like AltaVista...")
mentors are a great thing to have, and good ones are hard to find. It's not someone you bug every time you have a little problem with your code, but someone who's been where you are now and can give you advice over a few drinks after work.
I can think of two colleagues who were critical in me ditching wage slavery and becoming a freelancer, one is a programmer, the other is a CTO but started as a network guy. I didn't learn much from them about being a developer, but I sure learned a lot about being a professional.
