I will answer this question in general without taking any framework into account.

Before continuing I would recommend to read my answer to similar question where I describe modern SDLC process. Now I am going to describe mostly a most complicated part of this process - software engineering (making web app) more specifically.

Before start there should be an architecture at least in the mind and all build tools ready. If it is first page or project just started - create all the necessary folders, sub-folders, configure framework if any used. Let say, you use a Bootstrap and SASS, then do 1st step for whole project (all pages you have) to understand the whole architecture and after that setup SASS variables and build your own Bootstrap.

Frontend:

1. Analyzing specific design page

(psd, sketch, wireframe, proto, whatever the best you have)

1. Understand the structure of the document, which global sections, sub-sections you will have. Paint layout and grid in your head.
2. think about responsiveness, what breakpoints do you have, how layout should change
3. Understand each component used on that page. Which one is already implemented (JavaScript) and can be re-used, which one you will need to implement. What is the structure of each component. What is the structure of whole document altogether. Paint your basic HTML markup and DOM in your head.
4. What assets (images, icons, fonts) are used on the page and by each component, what designer has provided you, what is missing, request if so or export yourself.
5. How page and each component will work and animate together, are there any instructions provided by a designer, if no - ask. Still remember about the web accessibility and basic UI/UX. In most cases you have power to fix a problem, fix designer mistakes or improve a product before it is shipped. Obviously, today if it is not seen in design that button on hover should change state, you should implement it, but let the design author know about that issue and let him provide a final solution later. If you are working in big/serious/German project or just have a signed contract, then you in most cases don't have rights to change anything in the design which was approved. Is it ugly? Not your problem. However, you still can tell your issue and what are you proposing to a manager/tech lead/customer. In most companies, projects and in startups acting and improving a product on your own is a big plus.
6. Finally look into colors and other styles. What CSS you already have and can re-use, what you will need to write.

Now you can actually start writing a code.

2. Semantics, accessibility, HTML, CSS

Global elements/utils (GUI kit) → page → each component

1. Start from the layout/grid and all global sections. For each component, of course, there also will be inner small grid which should be built first.
2. If you don't have create a dummy .box or other class with 0 border radius, grey background and min-height (sometimes you may add ~3px red border and make sure there is spacing between blocks/columns/rows). Before putting real components into your layout use dummy boxes so you could see how layout will look like.
3. With dummy page implement additional media queries if required and make your layout change. With dummy divs you now may see how real page will look like.
4. Now you can start replacing dummy boxes with real panels and it content. Start section by section from header till footer.
5. Use semantics, right tags for the right job and custom tags so everyone by reading only your HTML could describe how page looks like. Use divs and nesting as less as possible.
6. Use role/ARIA/tabindex tags and think about accessibility and screen readers
7. When component's (page's) HTML is ready, write CSS. (If you have experience and good memory, you may "define" CSS classes and put them when writing HTML and after HTML actually implement CSS styles, remember also how you should name your classes, usually it will be something like [prefix-]-component-element-[modificator], for example: admin-footer, article-image, app-users-photo-secondary
8. Fill the content, text (lorem ipsum or whatever you have in deign), for images you might have dummy images at the beginning. If image will came from DB, then you may left dummy image.
9. Repeat for each component and remember to build smaller parts used many times in different components and pages (GUI kit, like buttons, form inputs, etc) first. Re-use what can be re-used.
10. Final decorations (advanced CSS) are implemented at the end (pixel perfect, all the shadows, spacings)
11. Finally if there are any - animations.

3. SVG or other spite

1. Probably you will need to find some free SVG icons online yourself.
2. Probably you will need to edit SVGs provided by designer to prepare them for sprite and usage in the web in Inkscape or other progrm yourself.
3. Put all the SVGs in their folders, check names an run your built tool for sprites. Make sure all the gradient and other stuff is inside <defs>
4. Import SVG sprite at the end of HTML and test your icons by putting them in all the required places.
5. Probably you will need to add additional SVG CSS.

4. JavaScript

Your page looks amazing but by clicking on dropdown nothing happens, "Load more" nothing loads, etc. Yes, you guessed right, now you need to make page and components alive.

Page specific scripts → Components → AJAX/Data/State/Models

1. If you are using router in browser, then register routes and write basic controllers/actions/whatever you have.
2. In some rare cases you just need to write some JS for page itself (usually on index page)
3. Implement the logic of each Component, make it actually do something.
4. When UI is totally ready, check it on all platforms you have.
5. Depending on how you handle AJAX/data write Models/State objects or whatever you have. I usually have simple JS objects, wrappers around fetch/XHR. If you don't know how back-end URL will look like, you may fill the URL in fetch() later.

If you are using tests in JS, you may add some at the end or at the beginning. But it is mostly part of the "QA" step and usually performed by a test engineer.

Backend

Since question was more asked from frontend point of view, I am not going to write another TL;DR in this section. Just make sure everything works fast, is secure, cache used, logs used and same words about the tests.

1. Create new routes, API/AJAX routes, controllers and templates

1. You have new users page? Register GET /users, GET /users/{id}, etc.
2. Your frontend needs to call AJAX? Register API/AJAX routes also.
3. If HTML was received from simple HTML/CSS developer there is probably a need to make a real templates from them first.
4. Program the whole logic of each template, insert all variables, loops, etc. (You may work per component/template/route)
5. Now, when you know what data template needs, implement controller methods, if there are new Models or methods, just write them even if thy are not implemented yet. You may define empty class/method so IDE would offer you autocomplete and removed warning.

2. Create new tables, migrations, models, actions, services, update frontend

1. New data structure, new entity? Create a new migration/table/document
2. Probably the most difficult part - actually implement all the data/model logic
3. If there are any additional filters/middleware/services required, implement them
4. Do you need to write new mocks for new models? Do you need to import data from Excel files or other sources? Do you have a parser? Do all what is needed.
5. Finally you see a full picture, if there are empty URLs or something else left in frontend models, finish them.

Backend and frontend are connected now, check everything and fix issues found.