Build and Deploy Your First Web App

Proof required

Open DevTools on any website, go to the Network tab, reload the page, and find the main HTML document request. Share a screenshot showing: the request URL, the status code, and the response headers. Write 200 words explaining what you see — what the status code means, why there are multiple requests, and what would happen if the server returned a 500 instead of a 200.

What gets checked

• Screenshot shows a real Network tab with real requests — not a diagram or a stock image
• The 200-word explanation uses the submitter's own words and correctly explains what a status code is and why multiple requests happen
• The 500 explanation shows they understand the difference between a server error and a client error — not just 'it would break'

Common mistakes

• Skipping this milestone because 'I just want to build' — developers who don't understand HTTP debug in the dark; this foundation pays off every time something breaks
• Copying the 200-word explanation from a tutorial — the Network tab exercise is meant to produce your observation of a specific site you chose

Resources

What a verifier looks for

• Check the screenshot — does it show the Network tab with real requests, or is it a code snippet? Real DevTools output has timestamp columns, size columns, and a waterfall chart.
• Ask the submitter: 'What's the difference between a GET and a POST request?' If they can't answer, they haven't understood HTTP — send them back to the depth resource.
• Check the 500 explanation — 'it would break' is not sufficient. They should explain that 500 is a server-side error meaning the server crashed or had a bug, distinct from a 404 (resource not found) or 400 (bad request from client).
• Ask: 'Why did the page make 30 requests instead of 1?' If they can explain that HTML, CSS, JS, and images are separate requests, they understand the web.

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

Proof required

Share your GitHub repository with all HTML and CSS files. Share two screenshots of the same page: one at desktop width (1280px+) and one at mobile width (375px). Write 150 words on the hardest CSS problem you hit — what were you trying to achieve, what did you try, and what eventually worked?

What gets checked

• Repository contains real HTML and CSS — no framework classes, no CDN links to Bootstrap or similar, no generated code
• Desktop and mobile screenshots show the same page visibly adapted — not just the same layout scaled down
• The CSS problem reflection names a specific property or behaviour (e.g. 'flexbox wasn't centering the way I expected') not just 'CSS is hard'

Common mistakes

• Using a CSS framework because raw CSS is frustrating — the frustration is the curriculum; every fight with CSS teaches you something a framework hides
• Building a portfolio site as the project — the topic you know well makes the content decisions easier so you can focus on the CSS

Resources

What a verifier looks for

• View the repository — is the CSS in a separate file or inline styles? Inline styles everywhere means they haven't learned CSS, they've learned HTML attributes.
• Resize the browser window on the submitted site. Does the layout adapt, or does it just shrink? A real responsive layout changes structure at a breakpoint — it doesn't just scale.
• Ask: 'What does the box model mean?' If they can explain content, padding, border, margin in order, they understand CSS. If they say 'the boxes around things,' send them to MDN.
• Check the CSS problem reflection — it should name a specific CSS property. 'The layout was wrong' is not specific. 'position: absolute was taking my element out of the flow and I didn't understand why' is specific.

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

Proof required

Share the updated GitHub repository with your JavaScript file(s). Record a 2-minute screen recording showing all three interactive features working. Write 150 words on one bug you fixed: what the bug was, what you thought was causing it, how you actually found the cause (console.log, DevTools debugger, process of elimination), and what the fix was.

What gets checked

• Three distinct interactive features are visible in the recording — not three versions of the same click handler
• JavaScript is in a separate .js file with a <script> tag — not inline onclick= attributes scattered through the HTML
• The bug reflection names the actual bug (e.g. 'my event listener was attached before the DOM loaded') not just 'it wasn't working'

Common mistakes

• Using jQuery because 'everyone uses it' — jQuery was written to smooth over browser inconsistencies that no longer exist; modern vanilla JS is cleaner and teaches you what jQuery was hiding
• Writing all JavaScript in HTML onclick= attributes — this works but trains a habit that will cause problems in every future project; separate files from day one

Resources

What a verifier looks for

• Watch the screen recording — do all three features work without page reloads? A feature that submits a form and reloads the page is not 'changing the page without reloading.'
• View the JavaScript file. Is it one giant file with everything in it, or is it organized? At this stage one file is fine, but if it's over 200 lines ask the submitter to explain the structure.
• Ask: 'How did you attach the event listener to the button?' If they used onclick= in HTML, they didn't follow the standard. If they used addEventListener in JS, they did.
• Check the bug reflection — the debugging method matters as much as the fix. 'I changed things until it worked' is not debugging. 'I added console.log to find where the value became undefined' is debugging.

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

Proof required

Share your GitHub repository with clear instructions in the README for how to run the app locally. Record a 3-minute screen recording showing: starting the server in terminal, opening the frontend in a browser, and making a visible change to the JSON data file and refreshing to show the frontend updated. Write 200 words on what a REST API is and why you built three separate endpoints instead of one.

What gets checked

• Repository README instructions work — a verifier must be able to clone and run the app with only the README in under 5 minutes
• Screen recording shows the data flow clearly: server running in terminal, frontend making a real network request (visible in DevTools Network tab), response displayed on page
• The REST explanation shows understanding: separate endpoints for separate resources, not just 'I needed three'

Common mistakes

• Not reading about CORS before running into it — every first-time frontend-backend project hits CORS errors; know what it is before you see it so you're not confused when it appears
• Putting all logic in one giant route file — even at this scale, separating routes from data logic builds the habit that makes larger apps manageable

Resources

What a verifier looks for

• Clone the repository and follow the README. If you cannot run the app in under 5 minutes using only the README, the milestone is incomplete regardless of how good the code is.
• Open DevTools Network tab while using the app. You should see fetch requests to the Express server appearing. If data appears on the page but no network requests appear, the data is hardcoded in the frontend — not fetched.
• Change one value in the JSON data file and restart the server. Does the frontend show the new value? If not, the frontend is not actually reading from the backend.
• Ask: 'What would you need to change to make this app work for 100 users at once?' If they understand that the JSON file would be a problem (concurrent writes) and a database is the answer, they understand why the next step is a database.

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

Proof required

Share the public URL of your deployed application. It must work without any setup from the visitor. Share evidence that 10 real users tried it: screenshots of feedback (messages, forms, comments — anonymised). Write 200 words on: one thing that worked differently in production than it did locally, how you diagnosed it, and what you fixed.

What gets checked

• Public URL works right now — the verifier must be able to open it and use the app without any instructions or setup
• 10 users are real people who found it without being personally asked — shared in a community, posted online, or submitted to a directory
• The production-vs-local difference is specific: names the exact error, the diagnostic steps (logs, environment variables, differences in OS or Node version), and the fix

Common mistakes

• Sharing a localhost URL or a Replit link as the 'deployed app' — the proof requires a public URL that works without the submitter running anything on their machine
• Counting 10 friends as the 10 users — friends are too polite; post in a community (Reddit, Discord, a forum related to your app's topic) to find real strangers

Resources

What a verifier looks for

• Visit the URL right now as a new user. Try every feature. Note every point of confusion. If you can't figure out what the app does in 30 seconds without reading any instructions, the onboarding needs work — report this to the submitter.
• Check the production difference reflection — 'it worked locally but not in production' with no diagnosis is not sufficient. They should name the specific error (usually an environment variable missing, a file path difference, or a case-sensitive filename) and show they found it in logs, not by guessing.
• Ask: 'What would you do if you woke up and the app was returning 500 errors for all users?' If they know to check the deployment logs first, they understand production. If they say 'redeploy it,' they don't yet.
• Verify the 10 users are real — ask where the submitter shared the link. A community post, a Reddit thread, a Discord share are verifiable. 'I sent it to some people' is not.

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