Step 1: Treat requirements like a client brief

The first time I skipped this on a client take-home, I built the wrong thing for a full evening. The brief said "filterable list". I built filters. The client meant search. Two different features, one missed sentence.

Now I write the brief back in my own words before I open the editor. Assumptions go in a list. Vague parts get a question mark next to them. Edge cases get one line each, no more. It feels slow for ten minutes, then it saves you the evening.

Step 2: Plan before you code

I give myself fifteen minutes with a sheet of paper before I touch the keyboard. Three things land on it: the main components, one library choice I can defend out loud, and how the data moves from fetch to screen. That's the whole plan.

You don't need an architecture diagram. You need a small map so future-you, the one typing at 11pm, doesn't have to re-decide things twice.

Step 3: Code with structure

Pretend a teammate will open the PR tomorrow morning with coffee in hand. The thing I focus on most is commits. Not the code, the commits.

On my first client project I made one giant "final" commit at the end. The reviewer read it for ten minutes and asked me to split it. I learned to commit per small intent: add filter UI, wire fetch, fix empty state. Now when someone scrolls my git log they can read the story of the build without opening a single file.

Platforms like Frontend Mentor or DevProjects hand you briefs that feel like real tickets (as of May 2026, both still offer free tiers, but check before you commit a weekend to either). Practicing here is almost the same as practicing for client work.

Step 4: Keep it fun and portfolio-worthy

Don't only pick the “boring” assignments that look like exam questions. Mix in fun mini projects that excite you:

• A simple recipe app
• A “guess the movie” quiz
• A small dashboard with a public API

The point isn't to build production apps, it's to show some taste while you train. Put them on GitHub with a README that covers setup, features, and "what I'd improve if I had more time".

Now, that probably sounds like portfolio padding. It isn't. When I review junior candidates, three small finished repos with a real README beat one half-built clone of a SaaS dashboard every single time. Finished and honest wins.

Step 5: Hand it over like a human

Real assignment or practice, I wrap every one the same way: a README that explains how to run it, a short note on the assumptions I made, and a demo link if I have hosting handy.

Fifteen minutes, tops. The first time I did this on a take-home, the lead at the other end replied "this is the first submission this week with a README, you're shortlisted." I didn't write better code than the others. I just stopped at the door and shook hands.

One thing to try this week

Pick one Frontend Mentor challenge at the medium tier. Give yourself a single weekend, not a month. Ship it with a README, a commit log a stranger could read, and one paragraph at the end called "what I'd do with another day".

Drop the repo link in the next lesson's comments. I read them. If you get stuck on the brief itself, that's the most interesting part, tell me where you got stuck and I'll show you how I'd unblock it on a real client ticket.