Tomorrow i will be joining a set of well respected coders, designers and architects as a mentor for #in50hrs a rapid "idea to product" sprint organized by the startup centre. By this time tomorrow a lot of teams would have started writing code to give life to their product ideas. So before the day starts i thought i would enumerate a set of tips that the teams will find useful for the codeout. Get Your Version Control Ready Yes we know that you are writing a prototype and it is a proof of concept, and you may dump the entire codebase to write the product all over again after validating your idea. All that is fine! But I still think you should go with a VCS. Your entire codebase will be in a state of flux the next 50 hours and you dont want to get into a situation where the only way to get back to a previously working state (which was say a few hours ago) is by pressing a sequence of Ctrl + Zs. I suggest you setup a no nonsence local repository like Git / Bazaar / Mercurial. Additionally these VCSs also help you in merging code bases automatically and hence improving your teams productivity. Have a Process Of Development Never forget the  two golden words of development: Incremental Development and Iterative Development. Try to break down your ideas into Minimum Marketable Features. In other words break down your ideas into logical chunks that make business sense and then start implementing these pieces one at a time. This is the essence of Agile / Lean development. Dont get scared by the use of process jargon here, the reason why I insist you must follow some kinda process against a no process 'cowboy style fire at will' coding is because, you are extremely time constrained. This breaking up of features and piece wise implementation will ensure that on the worst case scenario you will have a product with most of the features implemented against a situation where you will have a huge piece of code that is hopelessly broken and that essentially does nothing. In other words this is a sure shot formula to ensure that you have atleast something ready for demo hour. I would suggest you to also have a look at this presentation that my colleague Siddharta had done for the previous in50hours. Use an IDE that works for you Lets face it you need an IDE, notepad is not going to get you anywhere. So decide on the IDE you are going to use right now. Make sure you know it enough to work productively. More often than not I have seen people deciding in a whim to use an IDE that they have never used before. I have done this heinous crime myself (a lot of times), and all these times my productivity sucked. I not only had to face the intellectual monster that would become my codebase, but I also had to tackle at the same time the challenges thrown at me by a new IDE. Trust me its just too much to handle. If you really are wanting to try out a new IDE during the code sprint atleast make sure you get yourself used to it in what ever little time is left until the start of coding. Tests Yes you read me right. I said tests. I am not talking comprehensive functionality / acceptance tests written in selenium here. But simple unittests. Every modern language worth its penny (yes even Google go) comes with a unittesting framework. Make sure you use it to test, if not all your interfaces, atleast your core business logic. I would go to the extent of asking you to do a bit of TDD on the business logic bit. Its going to take you a little longer to write the test cases and the code. But hey it ensures that your core business logic is bug free. Besides this also ensures that you are testing your product through the development in a systematic manner, instead of testing all of it at the end of development  in a shoddy haphazard manner that will put you in the “oh god let this work – shit let me fix that bug” vicious circle.  You wouldn't want to go into demo hour with a product that is not systematically tested out, would you? Murphys Law always will follow. Stacks and Standard Libraries Look and use standard libraries as much as possible. They help you a long way in reducing the amount of code you need to write. Assuming that you will be writing a product for the web / mobile space, I am pretty sure you would have already decided on what language you will be using for the backend and I am also assuming you have considerable experience in it. If you are going to try out a new language then the quick advice for reasons stated earlier: Don't. So yes I hope you will be using as much of existing code as possible. That way you can concentrate on writing your business logic instead of worrying about implementing an HTTP server. And as far as the fronted is concerned I suggest you use jQuery. Hands down. I will refrain from commenting on the stack that you should be using to develop your product. All databases are awesome, all servers are good. You really should not be thinking about mecached and rabbitMQ and finally windows is a big OK. I would however recommend you to use a language that is elegant, that favours rapid prototyping and that is easy to debug (read as: not PHP). In case you do want to write it only on PHP then all the best to you, I have written considerable amounts of PHP to know that it is NOT the language for prototyping. Finally, make sure you remember to keep your code clean. Remember to Reduce, Reuse and Refactor code as much as possible in the next 50 hours to create the product that you always wanted to create. All the best!