Build and Deploy Your First Web App

Proof required

Open DevTools on any site, go to the Network tab and reload. Find the main HTML request. Share a screenshot showing its URL, status code and response headers. Write 200 words on what you see. Explain the status code and why there are many requests. Say what a 500 instead of a 200 would mean.

What gets checked

• The screenshot shows a real Network tab with real requests, not a diagram.
• The explanation is in your own words and gets status codes and multiple requests right.
• The 500 answer separates a server error from a client error. 'It would break' fails.

Common mistakes

• Skipping this because you just want to build. Without HTTP, you debug in the dark.
• Copying a tutorial's explanation. Describe the site you actually chose.

Resources

What a verifier looks for

• Real DevTools output has time and size columns and a waterfall chart.
• Ask the difference between GET and POST. If they can't say, send them to the HTTP docs.
• The 500 answer should explain a server-side failure, distinct from a 404 or 400.
• Ask why the page made 30 requests. HTML, CSS, scripts and images load separately.

You'll sign in first, then come straight back here.

Proof required

Share the repository with all HTML and CSS files. Share two screenshots of one page, at desktop width (1280px+) and mobile width (375px). Write 150 words on the hardest CSS problem. Say what you wanted, what you tried and what worked.

What gets checked

• Real hand-written HTML and CSS. No framework classes, CDN framework links or generated code.
• The mobile screenshot shows the layout adapting, not the same layout shrunk.
• The reflection names a specific property, like flexbox not centring as expected.

Common mistakes

• Reaching for a framework because CSS is frustrating. The frustration teaches what a framework hides.
• Building a portfolio site. A topic you know frees you to focus on CSS.

Resources

What a verifier looks for

• Is CSS in its own file? Inline styles everywhere means they learned HTML attributes, not CSS.
• Resize the window. A real responsive layout changes structure at a breakpoint.
• Ask them to explain the box model: content, padding, border, margin.
• The reflection should name a property, like position: absolute leaving the flow.

You'll sign in first, then come straight back here.

Proof required

Share the updated repository with your JavaScript files. Record a 2-minute video showing all three features working. Write 150 words on one bug you fixed. Say what it was, what you first suspected, and how you found the real cause. Name the tool, like console.log or the debugger, and the fix.

What gets checked

• Three different features in the video, not three copies of one click handler.
• JavaScript lives in a separate .js file, not onclick= attributes in the HTML.
• The reflection names the bug, like attaching a listener before the page loaded.

Common mistakes

• Using jQuery because 'everyone does'. Modern JavaScript teaches you what jQuery hid.
• Writing everything in onclick= attributes. Use separate files from day one.

Resources

What a verifier looks for

• Do all three features work without a reload? A form that reloads the page doesn't count.
• If the JavaScript file is over 200 lines, ask them to explain its structure.
• Ask how they attached the event listener. addEventListener is the standard; onclick= isn't.
• 'I changed things until it worked' isn't debugging. Finding where a value went undefined is.

You'll sign in first, then come straight back here.

Proof required

Share the repository with a README on how to run it locally. Record a 3-minute video. Start the server and open the frontend. Then edit the JSON file and refresh to show the change. Write 200 words on what a REST API is. Explain why you built three endpoints, not one.

What gets checked

• The README works. A verifier can clone and run it in under 5 minutes.
• The video shows the server running and real requests in the Network tab.
• The REST answer explains separate endpoints for separate resources, not 'I needed three'.

Common mistakes

• Meeting CORS unprepared. Every first frontend-backend project hits it; read up first.
• Everything in one giant route file. Keep routes apart from data logic.

Resources

What a verifier looks for

• Clone it and follow the README. Over 5 minutes means incomplete.
• Watch the Network tab. No requests to the server means the data is hardcoded.
• Change a value in the JSON file and restart. The frontend should show it.
• Ask what breaks with 100 users at once. Concurrent writes to the file, hence databases.

You'll sign in first, then come straight back here.

Proof required

Share the public URL. It must work with no setup for the visitor. Show 10 real users tried it, with anonymised feedback screenshots from messages, forms or comments. Write 200 words on one thing that behaved differently in production. Say how you diagnosed it and what you fixed.

What gets checked

• The URL works right now, with no instructions or setup.
• The 10 users found it without a personal invite, through a community, post or directory.
• The production difference names the exact error, how you diagnosed it, and the fix.

Common mistakes

• Sharing a localhost or Replit link. It must work without your machine.
• Counting 10 friends. Post in a community related to your app to reach strangers.

Resources

What a verifier looks for

• Use it now as a new user. If its purpose isn't clear in 30 seconds, tell them.
• The production answer should name the error and show they found it in the logs.
• Ask what they'd do if every user got 500 errors. Checking logs first is the right answer.
• Ask where they shared the link. A community post can be checked; 'some people' can't.

You'll sign in first, then come straight back here.