Do first two steps for whole project at the beginning to get a full picture, then repeat all steps for each supreme system component/service. In case of large team with different tech stacks - each team (or just a team member in smaller teams) might be responsible for a single component of the system: auth, profile, news feed, settings, back-end, UI/front-end, testing, etc.

What you are asking for is called a Software Development Life-cycle (SDLC). Below I tried to provide short review of the whole process:

1. Business analysis, UX engineering, specification writing, building UI kit and instructions, designs of each page, breakpoint and state itself (I am not going to go deep into design process itself, you may get more about it in this awesome answer)
2. System analysis, team analysis, trend analysis, competitor analysis, how it is done elsewhere, tech-stack selection, research and basic benchmarking also might be done here.
3. Software design, what 3rd party tools and APIs will be used, what components system will have and how they will communicate with each other.
4. Data structure and database design - how exactly you are going to store data, where, what will be SQL table structure and relationships, UMLs or basic DB diagrams
5. Software Architecture - detailed design of each component and their relationships, diagrams, flow charts, documentation, API/Header/Interface-driven development - imagine how your own ideal API would look like so you would enjoy using it before it is written. For myself or for collaboration I'm using Google Drive docs and draw.io, basic stuff is just sketched on the paper and for simple apps there is no need in diagrams.
6. (Optional) You may use here Test-driven development (TDD), writing tests before code, providing test-cases, use-cases and instructions how system will be tested. For most new projects and small teams I would say you don't need to TDD, especially in startups and other environment where requirements might change too fast. However, having basic test plan is a must-have.
7. (Optional) DevOps, server installation, configuration, administration, orchestration. Depending on the team size and predicted high load on the system. For beginning and for small projects lead engineer might do it himself on the company's server or in a cloud/VPN, for example, using DigitalOcean for 5$/month, MailGun for outgoing emails for 10k mails/month for free. AWS can also be used here for both. For bigger bandwidth and more complicated infrastructure AWS, Azure, Google GSuit (previously Google for Business) and other clouds. You must have detailed description of whole infrastructure, deployment instructions, codes/passwords in a single secured place. You must have plan for failover, backups, load balancing, scalability in the future, etc.
8. Software engineering - implementation itself, local environment and dev environment set-up, Git repo set-up, giving access to team members, considering using some task management systems. Trello, Slack GitLab issues, GitHub issues (my prefered and most simple way, even users can create there bug reports) might be used, JIRA for larger teams with experience, Asana, etc. Build/compilation process set-up. Framework, library writing/configuration, each component, all services, set-up of all the 3rd party services and APIs. It consists of UI (front-end) engineering and back-end engineering. In the ideal situation design with 1) GUI kit and 2) instructions - should be ready before UI engineering. And for back-end it is required to have at least layouts ready and index page (or main screen) fully UI programmed. It is recommended to do a pair-programming and code-review.
9. Software testing (QA) - Checking that implementation does what specification says. Detailed test plan and check-list development, testing every single part of the app on different platforms which should be supported. Automation testing might be considered here (Unit testing, System/End2End/App/Browser testing). Checking that system is secure, reliable, emails are sending/receiving, logs are writing, exceptions are logged, handled, notifications sent to responsible persons, database transactions are used, etc.
10. (Optional) Technical audit - in the ideal situation someone else (in corporations it might be other companies) should just do a project-level "code review". Something like QA for QA done by a someone who was not evolved in the project development at all. Are there no hacks left by engineers. Is software compatible with international standards like ISO 25010, is software accessible, does software fits the market and local law, etc.
11. Release, deployment and bug fixing - after everything is done, set up production and staging environments, release first public version, set up all the required 3rd party services and apps like Facebook App for login, Google App for using G+ auth, Google maps, etc. Test everything on production again. If some 3rd party apps requires approval, for example to using Facebook location, friends and other scopes - you should record videos, explain how you are using each scope and submit the app for approval. Invite test users. Make changes in the system according to a feedback or new requirements, fix found critical and serious bugs. Launch.
12. Maintenance, support, documentation - finally, just keep the system healthy and operational. If there is no documentation, write it and keep it up-to-date. Set up monitoring, all the critical dev notifications, test backups time-to-time, check logs, clear logs, keep fixing bugs and making small changes. In future when new requirements will come, repeat the whole process again. Maintenance also means keeping following the trends and updating all the dependencies, frameworks and even OS kernel, packages to the latest versions.

I do a number of types of builds, so I'll go through what my process would be:

Partial Layout

This could be a new layout for an existing website, a new modal design, or a re-usable part of the design that we might be using in more than one layout. Usually what's given to me will be a PSD (rare), an image-based mockup (common), a wireframe (very common), or sometimes just a verbal description (rare) or some combination of those. My job is to realize the needed design in HTML + CSS, and build the frontend part of it, adding any JavaScript interactivity I can, and then prepare it to be handed off to backend programmers for addition into a web app.

Here's how I would begin:

• start a fresh HTML file so I can work on this piece on its own page (in isolation from the rest of the codebase)
• create HTML markup necessary for the design, using as few elements as I can get away with and still have all of the content present
• begin writing CSS styles to flesh out the markup I've chosen. At this point any mistakes I've made in my HTML decision-making become apparent.
• Usually I will update my HTML or add a few things like a class or ID if I need it
• Style the CSS to 100%, then add responsive variations for when the design is too wide or too narrow. If I'm designing a re-usable design module I may use element queries instead of media queries for the breakpoints
• Add JavaScript interactivity using vanilla JavaScript, and as few libraries/plugins as I can get away with. If I can build it all using just vanilla JS that's best.
• Hand off to backend programmer for being hooked up and added to the app in the right place

Plugin or side project

• Start writing Markdown-formatted notes about what I want to build
• Mark up my notes as HTML and this document becomes where the work takes place
• Write just enough HTML and CSS that I can start writing JavaScript to build the plugin
• Once work is complete I'll move the JavaScript to its own file, and turn my HTML page into a demo/test
• (Optional:) Upload to Codepen of Github for my future reference and to share with people

Depends on the complexity of the website.
If you're building a Single Page Application (SPA) or just a static, only a couple page, website then just get on with it.

However, if you're building something like facebook. Not social media platform, but just the multitude of components and moving parts that are there. Then it would be better to come up with a shared idea in the heads of the dev team and then work on a couple of use cases with the Minimum Viable Product (MVP) outlined, e.g. specific features etc. After that i'd throw together a couple of wireframes to confirm what it would look like then start building it - i.e. actually begin to code it.
Once you begin coding it's more of an iterative process as things will change, they always do. It doesn't mean you have to do everything all over again that I mentioned above but rather just acknowledge the new changes and their impact on complexity/time frames etc.

When you do finally start to code, try and have a rough timeline when features will be completed. Then just work off "sprints" or the "Agile" approach to development.

Hope this helped :)