I really like what you are doing, but after seeing what happened to RailsCasts I am a worried what will happen to this business model once it hits 400+ episodes. Hopefully your "other plans" have this part worked out?
You'll be doing all the work up front and then all the work maintaining and improving.
You're also not a flight risk as it sounds like you're in it for the long haul.
They also sound like they're not convinced, which means they either haven't though it through or they're not worth the risk.
Good luck with the decision. I would vote a no for them as it sounds like you deserve better and if you keep looking, you'll find some cofounders worth taking the startup risk with.
The following are some of the main misconceptions of what's floating around between the blog, TC comments and HN comments.
Misconception 1: answering programming questions tells if the developer is awesome
No it doesn't. When an interviewer asks you a programming language-specific question, they are wanting to know how awesome you are at the language to see if you can hit the ground running on your first day. These sorts of questions only tell you one thing though, that the person you are interviewing has spent a lot of hours in front of the one programming language. I personally do not rate these types of questions for an interview because anyone can learn syntax, data structures and best ways to implement language-dependent code.
Misconception 2: brain-teasers don't tell you anything
This couldn't be more wrong... The reasons why an interviewer throws you a brain teaser or design question is to understand your thought logic and problem solving skills. While you talk through how you would solve your problem, they are assessing your communication skills, your process in solving a problem and also what knowledge you have as part of your experience.
Misconception 3: degrees don't tell anything
There is a lot of "show us your projects" being thrown around. While this is a fair call, one should not dismiss the degree. Simply being, that the degree is a project. It means that the candidate has had to spend three to five years juggling multiple subjects (read as 'projects'), while working part-time (read as 'projects') and managing their social life (read as 'drinking beer' and 'tuning hot people'). A degree is a testament of the students ability to see something through from start to finish... it's an example of their dedication.
Misconception 4: degrees aren't teaching students how to
code, so how are they expected to code
Again, this is a fallacy. The degree is teaching students how to collaborate through group projects. How to work unsupervised and be resourceful while working unsupervised. It teaches the fundamentals so they can pick up any programming language (just another tool) and apply the fundamentals they have been taught.
I strongly agree with @marcamillion's statement about "developers being better over time". This is why I disagree with Misconception 1, as all this is doing is showing how much experience the interviewer has with the language they are quizzing someone on.
Overall, give the new coder a break. They most likely got hired because they:
- fit into the work culture
- possess strong problem solving abilities
- can work unsupervised
- can work within a team environment
- have imagination
And if the new guy is asking you a question, it's because they're wanting to learn, so respect that as they're trying to be awesome like you.
Disclaimer: Sometimes people make mistakes though, and a dud ends up being 'that' coder that can't code ;)
At my first professional job, the director of the company was a pathologist for 20 years. It then occurred to him that his industry could be run more efficiently so he embarked on developing his own pathology system. With no previous software background, he had his wife bootstrap his development of the system for a few years before he was able to implement it for production use. He ended up running his new software company for 12 years before he sold it for millions!
He is a prime example of someone with no software experience moving into the industry. However, I believe it worked wonderfully for him because he didn't shift from his primary industry where he held all of his domain knowledge.
Congrats if you're wanting to shift professions and industries as it is a brave move. I would suggest surrounding yourself with talented and experienced people in the software industry. There should be Ruby on Rails and web meetups in your area where you will be able to network and learn from approachable people.
How is heroku doing these days:
Recently acquired by Salesforce and expanding their add-on range means that they will be around for a long time and it is promising that they are catering to a larger variety of developers.
Reliability:
They run off Amazon web services which are continually expanding their regions. So they are highly reliable (especially after the EC2 outage in 2010).
Cost:
In my experience, heroku has saved me a lot of time and my clients a lot of money. Yes, I can setup and manage my own servers and it can be for as little at $10/month. heroku on the other hand costs up to $100/month for my production servers. Why am I willing to pay this much? Because I put a higher price on my time than $100/month. I don't have to worry about infrastructure or redundancy issues. Furthermore, my clients can afford these hosting costs as I explain to them that $100/month is cheaper than my hourly rate if I have to troubleshoot network/server issues and also perform server maintenance... which none of these I have to do on heroku.
Limitations & hiccups:
I've found that I've needed to employ alternative ways of doing things due to some minor heroku limitations. Overall, everything is achievable with some resourcefulness and some extra money.
Overall, heroku is easy to get started with, especially if you've got sys admin experience! Hope this helps and good luck with your job interview!
Thomas, J.P. & Robert, H.W Jr 2004. "In Search of Excellence: Lessons from America's Best-Run Companies", Harper Paperbacks.
Ignore what the critics say about this book because I think this book's strengths is in their case studies on the company cultures and qualities that made them successful decades ago. This is more about how to treat people and direct a company, while providing examples of how these companies had dedicated passionate micro teams who were their "lean startup" champions that drove their innovation and success.
Do you know how your friend feels about the two current interested VC's? Does friend not agree to their terms, are the VC's open to negotiations, does friend want to go after larger funding? If you can gauge friend's response to these questions, then you should be able to answer Q(1) and be comfortable doing Q(2) without burning bridges.
Friend should also give VC's more credit than to play them against each other or use them as bait. VC's are in their business because they know their stuff and can smell a good/bad idea a mile a way... when they don't understand an idea, it's because we as entrepreneurs have failed to help them understand.
This is a tough question because your ideas fall into many industries and most of them sound interesting so all the answers you get will leave you back to square one... which to pick?!
I would suggest trying to narrow down your choices based on your strengths and weaknesses (and those of your co-founders if applicable) and which ones you believe in the most; which would you buy/use/subscribe to as a consumer? This should give you a short-list where you could then perform a SWOT analysis^^ on each to help you trim the short-list of ideas down further. Get it down to one idea you are passionate about! Bring that to HN for feedback and you'll definitely have a great start!
^^ You mentioned you have done countless hours of research for an idea... Sometimes 'searching' isn't enough. Put your energy into 'doing' instead. If you're technical, create a prototype and unleash it to some people in the industry you are targeting. If you aren't technical, go find your pilot customers you want to target this to and present them with some wireframes and your elevator pitch for the product. Both of these methods will ensure you only spend a few days max but you'll be able to receive invaluable feedback to determine if you need to adjust your idea or try another one completely.
Like @rdon stated, lawyers cost a lot, and that's fine if you have the capital. But if you are in the early stages of a start-up without the resources, all you need is a written document that states your terms that you would liked 'formalized', make a copy of it (prevents people from conveniently misplacing it), then both sign it with dates (consider having a witness sign it too). Then in the event that you need to 'sort' things out, both your pieces of the signed document act as your contact.
Try a simple answer: "Which one would you use?" Answering this helps you determine which one you're most passionate about as well as a foundation for looking into a user-base.
I second @elgato75. If you're concerned now, then you guys aren't right together... Your co-founder has to be of all things reliable. It doesn't matter how smart they are or how many hours they put in, if they aren't reliable and there's no trust then your startup will have a difficult time succeeding.
Hence the reason why investors are just as likely to invest in a tight team as well as a good idea.