Ok so when trying to make a new project the biggest decision is chose the right tools for your needs. To do it you need to know what your application is about and if there is already something that will help you write it. That's because when you are in small team if you try to write everything by yourself you will simply waste a lot of time.
Ten years ago to solve software development problems I needed to read book, find people that are writing software in my technology dig trough their blog, ask questions on mailing lists or think about solution and implement it by myself looking at manuals.
Now the software making is hundred times easier, all thanks to opensource movement. Well show me person that thought in 90s that microsoft will make profits by running linux and other third party software. Opensource and all the online courses are the biggest community of developers I ever seen in my life. And because most of the challenges were already solved thanks to tools like stackoverflow or github, where millions of people share their knowledge.
Let me just explain that by example how simple it is now to hire 328 people for free just by showing you github project bar with 328 contributors.
Of course I cannot tell them what to do but I can freely use all their work for my own project and if it will make me profit I can appreciate their work later. And that is how it works, that's amazing times. It's not something that you see in other businesses, but it's changing THANK YOU OPENSOURCE for that.
The biggest challenge I see now is now to find those projects made around the world and compare them with each other, but maybe some smart guys will find the way to do it.
Back to the topic, first things you need to do before starting prototype is gather development requirements. It could be done just by find and isolate all components you need in your application. Distinguish all interaction between users. Do it just by asking questions and googling possible answers, make mistakes, repeat and finally you will have everything in place.
Ex. I want to make an application, and I want to start with web application.
Some questions on backend.
Do I need user account? Do I allow to login using social network.
Do I allow to interact between users ?
Do I need a search and what I want to search ?
Some questions on frontend.
What components I need, a table, calendar, list.
Is it a single page application or multiple pages ?
Do I need to get it working on mobile devices ?
Could it be an mobile app ?
Do I need some special components like sortable table, autocomplete, calendar, treegrid ?
The second thing is to find right projects. Right projects is the tricky part cause software development is all about uncertainty, technical depth and turnarounds of technologies. That's the things you, business companies, and customers need to realise, software is obsolete before the start. Your new products when are started to be written by developers are already old because of nature of the world. We as a people don't live forever and all the code we wrote will be either replaced or put to trash. That's exactly what is happening with cobol software now and this is one of the biggest challenge in the software development history. So the less code your company wrote the less code it need to maintain. The more modular the application is the more easy it is to replace some outdated components. And there is no right answers to questions only possible found temporary solutions. There is no one master language or technology, one database that will drive your product.
There is also a cloud that is trying to solve some of above problems but I won't write about it now, because even cloud is evolving and can be easily outdated by containers and lambdas.
Some of the important questions when find a project you need to ask are:
What is the license and is it permissive so I can use and modify code?
When was the last commit in this library ?
How many contributors it has, and are they only from one company, country or multiple sources ?
How big is the company, companies that are developing/using this library ?
How frequent are the library versions update and are they backward compatible ?
Is this library need to be developed or those standards won't change in 10 years.
The last question is usually most subjective and based on current market situation.
Ex. Frontend development. Browsers are the most used and frequently developed software in the world now, but at least for now they are also backward compatible. So you can use some old library but you need to face that most of the users are migrating from it and you won't find support when encounter problems.
And software development is mostly problems, mistakes and solving them.
Ok so you got components defined (at least 2 of them), some initial view planned, some requirements are written either on the paper or using some fancy software. Don't lie to yourself that you are safe now at this point cause everything will probably change hundred times between development cycles, so be elastic.
To start writing some code all you need to do is take your favourite editor make some imaginary duct tape in your mind and connect those pieces. Maybe make some decorators if you are certain about it. Ex. on the frontend part. When you find two libraries that you want to use you need to put them in the same webpage and find if they play together nicely. Their css styles don't overlap.
Make some interactions, put some mockup data, don't read the manual unless you are stuck. If you want to be a good duct taper write code.
Make a small working thing, only a proof that what you are trying to achieve is possible. don't waste your time on starting from authentication cause you don't have users, or you are writing some CAS product. Don't start with interactions between users unless you are writing chat.
Start with something minimal, let it be only a "Hello World" text but using all the tools you need. All the servers you need so you run it and try to modify this text to buttons you want, layout you want, protocol you want, data you want to get.
Let code be ugly, but working.
Being perfectionist is good but if you are not fixing any critical parts of software and only writing some prototype, it don't have to be perfect at start. It never will be and in a year hopefully you will see this code and ask yourself why I wrote this so dumb, just because we are only humans we make mistakes and evolve by learning and practice. The more you practice, the earlier you find your mistakes the better software you will write. Don't write fast code, for sake of readability, make multiple variables to be more expressive so you can understand it later. Name your methods by what they do even if it will be long named. Ex. Instead of writing stupid documentation one liners how this method interacts with database and how smart it is name method insert,update,delete not add,replace,remove.
And most of all keep asking yourself a question do I need to write this code or should I find and use library to do it for me.
Be a duct tape developer, contribute your work to opensource when you can and save the world from software flood. Happy coding.