Where can i find a knowledge base of the worst ever deals done between investors of any kind and entrepreneurs?

AngelList is your best bet. Since you're asking the question, chances are you don't have a way to get introduced to these investors. The simple truth (like it or not) is the chances very low that you'll get a deal done without an introduction from someone they trust. AngelList can help with that, so can going to networking events. And finally, If you're the introverted developer type, you can also get their attention by just building something really cool on your own, followed by some serious traction. Arguably the best strategy of them all.

Convertible notes are by no means "earned." They are often easier to raise for early-stage companies who don't want to or can't raise an equity round. Equity rounds almost always require a simultaneous close of either the whole round or a defined "first close" representing a significant share of the raised amount. Where there are many participants in the round comprised mostly of small seed funds and/or angel investors, shepherding everyone to a closing date can be very difficult. If a company raises money on a note and the company fails, the investors are creditors, getting money back prior to any shareholder and any creditor that doesn't have security or statutory preference. In almost every case, convertible note holders in these situations would be lucky to get pennies back on the dollar. It would be highly unusual of / unheard of for a convertible note to come with personal guarantees. Happy to talk to you about the particulars of your situation and explain more to you based on what you're wanting to know.

If you want information that matters in "Creative Financing Techniques" find a person with the experience/insight. Most of what is in books is dated. Many of the more creative methods are a function of current tax code and market factors (like QE).

The more important first impressions to leave a VC with are: 1) That you both are credible and inspire confidence that you can execute the plan you're fundraising on. 2) That there is good chemistry and a great relationship between the two of you; 3) That you can adequately address the concerns/objections/questions the VC raises. The CEO is expected to do most of the talking because the CEO should be the best person in the company at articulating the vision and value of the product and company you're building. If your CTO is comfortable presenting part of the pitch, it would be ideal for the CTO to speak to the product slides. The most important thing is for the CTO not to be a "bump on the log" meaning that you don't want them sitting there for most of the presentation with nothing to say. If you feel that's the case, you really shouldn't bring your CTO. Most VC meetings will not get technical and under the hood. Each question answered should be answered by the person best qualified to speak to that question. You should make eye-contact with your partner and use subtle body language to find a way to cue the other person to speak to that question or simply offer "CTO, would you like to answer that?" Bottom line, make sure that the CTO can speak confidently enough about the product and vision, otherwise -unless specifically asked by the VC - come alone. Fundraising is a big distraction to building and a good VC will always respect that in a first meeting, the CTO can be excused from attending in priority of building product. Happy to talk to you both on a call about helping get you feeling a bit more confident and prepared before your meeting. I was formerly a VC associate for a $500m fund and have raised money from VCs as a serial entrepreneur.

Whenever you assign them a task, break down the task into small chunks. Make the chunks as small as you can (within reason, and to the extent that your knowledge allows), and tell your devs that if any chunks seem large, that they should further break those chunks down into bite size pieces. For instance, for the overall task of making a new webpage, _you_ might break it down as follows: 1) Set up a database 2) Make a form that takes user email, name, and phone number and adds them to database 3) Have our site send an email to everyone above the age of 50 each week When your devs take a look at it, _they_ might further break down the third step into: A) Set up an email service B) Connect it to the client database C) Figure out how to query the database for certain users D) Have it send emails to users over 50 You can keep using Asana, or you could use something like Trello which might make more sense for a small company, and might be easier to understand and track by yourself. In Trello you'd set up 4 columns titled, "To Do", "Doing", "Ready for Review", "Approved" (or combine the last two into "Done") You might want to tell them to only have tasks in the "Doing" column if they/re actually sitting at their desk working on it. For instance: not to leave a task in "Doing" overnight after work. That way you can actually see what they're working on and how long it takes, but that might be overly micro-manager-y At the end of each day / week when you review the tasks completed, look for ones that took a longer time than average (since, on average, all the tasks should be broken down into sub-tasks of approximately the same difficulty). Ask them about those tasks and why they took longer to do. It may be because they neglected to further break it down into chunks as you had asked (in which case you ask them to do that next time), or it may be that some unexpected snag came up, or it may be a hard task that can't be further broken down. In any case, listen to their explanation and you should be able to tell if it sounds reasonable, and if it sounds fishy, google the problem they say they encountered. You'll be able to get a better feel of their work ethic and honesty by how they answer the question, without worrying as much about what their actual words are. Make sure that when you ask for more details about why a task took longer, you don't do it in a probing way. Make sure they understand that you're doing it for your own learning and to help predict and properly plan future timelines.