The Full-Stack Year

You're about to spend a year learning to build software that works all the way down, from the thing people click on to the database underneath it. Twelve projects. One application you will put on the internet.

I've written this so you know what's coming. Read it once now, then come back to whichever phase you're in. You don't need to memorise any of it.

Four things I want to say plainly before you start.

Some of this is hard on purpose. There are four weeks near the beginning where you write HTML and aren't allowed to make it look like anything. Three weeks after that where your code runs in a terminal and nothing shows up on a screen at all. There's a week around month four where one idea takes twice as long as you expect it to. Everybody finds those weeks hard. It says nothing about whether you're any good at this.

School comes first. The hours here are a ceiling, not a target. During exams, or a heavy term, or a week where life is just a lot, we cut the schedule back or pause it. Tell me early, while there's still time to change the plan. Falling quietly behind is the only version of this that goes badly.

You won't be judged on how much code you write. You'll be judged on whether you understand it, whether you can fix it when it breaks, and whether you can explain it to somebody who wasn't there. A small program you can account for beats a big one you copied.

Getting stuck is the job. Not a sign you've gone wrong. Professional developers spend a large part of every week stuck, and the difference between them and a beginner is mostly what they do in the first ten minutes of it. You'll learn that here too.

John Ayodele
https://johnayodele.dev/

Fifty-two weeks, ten phases. Each phase ends with something you built and can demonstrate.

The first half is the browser: structure, styling, then programming. The second half is everything behind it: version control, how applications talk to each other over the internet, component-based interfaces, servers, databases, and finally all of it joined into one system that you deploy.

Roughly seven to nine hours a week, about four of them with me. That's a normal school-term load and it's meant to fit around everything else you do.

You'll finish with twelve projects, a public portfolio, a year of commit history, and one full-stack application running at a real address.

You will, at some point in the first two months, want to skip ahead. Everyone does. So here is the reasoning, and you can hold me to it.

Fundamentals before frameworks. An abstraction is easy to trust once you know what it's hiding. React takes about an afternoon to understand if you've already spent fifteen weeks keeping a page in step with a variable by hand, because you'll recognise the problem it solves. Meet React first and you learn a set of rules you can't reason about, which is why so many people can build a tutorial app and nothing else.

Four weeks of HTML with no CSS. If you learn to reach for HTML when you want something to look different, you write pages that can't be restyled and can't be read by anything except a browser. Four weeks of structure on its own is what stops that habit forming. In week 4 you'll find out who all that structure was actually for, and it isn't you.

Three weeks of JavaScript with nothing on screen. Variables, functions and data shapes are worth being fluent in before buttons and clicks start competing for your attention. Week 14 is when things start moving, and it goes fast because of the three weeks before it.

Databases last, not first. By the time you meet PostgreSQL you'll have spent six weeks losing all your data every time you restart your server. It's genuinely annoying, and that's the point. You'll arrive at databases wanting one.

None of the weeks are padding. If a week feels slow, tell me and we'll talk about it, but the order itself isn't negotiable.

Not "have heard of". Be able to do, on your own, with documentation and no tutorial.

• Write semantic, accessible HTML and explain what a browser does with it.
• Build an interface that works properly on a phone, a tablet and a laptop.
• Write JavaScript to solve a problem you've never seen before.
• Debug something that's broken without changing things at random.
• Use Git and GitHub the way a team does: branches, pull requests, honest history.
• Read the documentation for an API nobody has taught you and build something with it.
• Build an interface out of React components and say where each piece of state belongs.
• Build a REST API in Node and Express, with real validation and real login.
• Design a relational database and get answers out of it with SQL.
• Store passwords so that losing your database isn't a disaster for the people in it.
• Put an application on the internet and work out why it broke there and not on your laptop.
• Write documentation somebody else can follow without asking you a single question.
• Explain any of the above out loud to somebody who wasn't there when you built it.

Being honest about what this is: a strong beginner foundation. It doesn't make you an expert and it isn't a job qualification. What it gives you is the ability to keep going without a teacher, which is worth more than either.

Three sessions with me, and some work on your own in between.

The midweek work is about two and a half hours spread over three days, not one long sitting. Little and often beats a panic on Friday night, and you'll remember more of it.

On Tuesdays, you type. I'll point at the screen. I won't touch the keyboard. If it takes you ninety seconds to find a bracket, it takes ninety seconds. This is deliberate and it's the fastest way to learn.

We fix the exact times when you start, around your school timetable. If they need to move later, say so early rather than just missing a session.

From you

• Turn up ready. Laptop charged, last week's work where you can find it.
• Have a go before you ask. Ten minutes of genuine effort, then ask.
• Bring evidence when you're stuck, not just "it doesn't work".
• Keep your own notes. Not for me, for you in three months.
• Do the practice work honestly. Copying an answer costs you the week.
• Use Git from the week we start it, every week after.
• Read documentation, not only tutorials.
• Look after your passwords, your API keys and your personal information.
• Explain your own work at reviews. Out loud, without notes.
• Tell me when the schedule needs to change. Don't go quiet.

From me

• Teach it in an order that works, and tell you why the order is what it is.
• Keep examples small enough to hold in your head.
• Care more about your questions than your typing speed.
• Give feedback that's specific and that you can act on. No vague praise.
• Be straight with you about where you are. I won't tell you something is mastered when it isn't.
• Adjust the workload around school and around you.
• Never let AI do your thinking, including mine.

There's no exam. Assessment runs all year and it exists to find out what you actually understand, so that I know what to teach next.

Every Sunday we do a short review. Once a month there's a longer checkpoint where we look at the whole picture. Both are conversations, not tests, and you can't fail them.

What's being measured

How topics get marked

• ✅ Mastered. You can use it on your own, cold, without looking it up.
• 🟢 Good. You can use it with documentation to hand.
• 🟡 Needs practice. You get there, but it's slow or you need prompting.
• 🔴 Needs reteaching. Something underneath it is missing. We go back.

Nothing gets marked mastered because you finished a tutorial. Mastery means evidence that you can use it independently, which usually means doing it once with nobody helping.

Going back to a topic is normal and expected. A week ending on the calendar isn't a reason to move on if the foundation under it is shaky, and I'd rather spend an extra week now than have you struggling in month six.

You'll be stuck a lot. That's not a problem, it's most of the job. But there's a good way and a bad way to be stuck, and the good way is worth learning early.

Before you ask anyone

1. Read the error. All of it, out loud if it helps. Beginners skip past error messages, and they're usually the answer.
2. What did you expect, and what happened instead? Say both in words before you touch anything.
3. What's the smallest test that would tell you which of your guesses is right?
4. Check the documentation. Not a tutorial, the actual reference.
5. Ten minutes. Then stop. Being stuck for an hour on your own isn't noble, it's just slow.

When you ask

Bring three things and you'll usually get a useful answer in one message instead of five:

• The exact error message, copied, not described.
• What you expected to happen.
• What you already tried.

This works on me, on Stack Overflow, on a forum and on your future colleagues. A question with evidence attached gets answered. "It's broken" doesn't.

AI tools are good at explaining a concept a different way, decoding an error message, and suggesting what to investigate. They're also very good at handing you a finished answer that looks exactly like understanding until somebody asks you a question about it.

So the rule here is learning first, in this order:

1. Try it yourself.
2. Check the documentation.
3. Investigate the error.
4. Ask for a hint.
5. Ask for an explanation.
6. Write the fix yourself.
7. Be able to explain what you wrote.

Fine

• Explaining something in plainer language when a page hasn't landed.
• Asking for a hint with the answer withheld.
• Working out what an error message means and what usually causes it.
• Reviewing code you wrote and suggesting improvements.
• Pointing you at the right documentation or some practice problems.
• Generating revision questions.

Not fine

• Finishing work you don't understand.
• Producing whole applications you paste in without reading.
• Standing in for learning the fundamentals.
• Claiming work you didn't do.
• Pasting in passwords, API keys or anyone's personal information. Ever.

The test I'll use: if AI helped with anything beyond a trivial task, you should be able to tell me what the code does, what you changed, why it works, and how you know. Sometimes I'll ask you to rebuild a small piece of it with nothing open. If you can, the AI helped you learn. If you can't, it did the work and you're now behind without knowing it.

From week 10 you'll have a GitHub account and your code will be public. That's a good thing and it needs a few rules, which we'll set up together with a parent or guardian before the account exists.

What never goes in a repository

• Your home address, your school's name, or your timetable.
• Your phone number or any identity document.
• Photographs that show where you live or study.
• Passwords, API keys or tokens. Not once, not temporarily, not in a branch you plan to delete.

That last one matters more than it looks. Git remembers everything. Deleting a file doesn't remove it from the history, and a public repository is copied and indexed by other people within minutes. If a key ever gets committed, tell me straight away and treat it as burnt. We generate a new one. Nobody will be cross with you about it, but hiding it makes it worse.

Accounts

• Strong, unique password. Not one you use anywhere else.
• Multi-factor authentication on, the same day you make the account.
• A username you'll still be happy with at twenty-five.

Being online generally

• Be civil with people, including strangers who are wrong.
• Careful with downloads, browser extensions and code from places you don't know.
• If an online interaction feels off, tell an adult. You don't need to be sure first.
• Never meet an online contact in person without an adult involved and a plan.
• What you publish stays online for years. Publish accordingly.

Coding should be one part of a reasonable week. Nothing here is worth staying up until two in the morning for.

• Break up long sessions. Stand up, look at something far away.
• Sit comfortably, with decent light. Your back will thank you in ten years.
• Keep normal sleep. Tired debugging is worse than no debugging, and you'll undo your own work.
• Balance the screen against exercise, friends, schoolwork and rest.

A missed session can be made up. Your health, your sleep, your schoolwork and your safety come first, and I mean that as an instruction rather than a nicety.

If you're finding a week genuinely miserable rather than just hard, say so. Sometimes the fix is slowing down, sometimes it's a different explanation, and occasionally it's taking a fortnight off. All three are fine. Quietly hating it is the only bad option.

You don't need to know any of these now. This is the map, not a reading list.

Some names are missing on purpose. Docker, Kubernetes, GraphQL, Redis and the rest are real tools that solve real problems, and none of those problems are yours this year. We'll add them when your fundamentals justify them, not because they're popular.

Twelve projects. Each one reuses everything before it and adds exactly one new difficulty, which is what makes the later ones possible.

Every finished project gets a short README: what you built, what you built it with, what it still can't do, and what you learned making it. Without that last part a repository is a folder of code nobody can account for, including you.

The one in week 49 is your capstone. It gets deployed in week 51 and you present it in week 52.

"It works on my laptop" isn't finished. We build this list together as the year goes, and from the week each item appears it applies to everything you make after it.

1. It works when somebody else opens it, on a different machine.
2. The HTML validates with no errors.
3. Every image has alt text that does the image's job.
4. Every input has a real label.
5. You can reach everything with the keyboard, and see where you are.
6. The links still work after you move the folder.
7. There's a README somebody else could follow.
8. It works at phone, tablet and laptop widths.
9. Every bit of text has enough contrast against its background.
10. Loading, error, empty and success are all handled, not just success.
11. No secrets anywhere in the repository.
12. The commit history reads like a story, and it was merged through a pull request you reviewed.

Items 1 to 7 arrive in week 5, and the rest turn up as you learn what they mean. By the capstone there are sixteen, plus a separate list for the API.

Before a language, a machine you can drive. One week on the four programs you'll live in for the next year, and what each of them actually does. No HTML yet.

Four weeks of HTML with no styling at all. Your pages will be black text on white and that's correct. HTML says what something is; CSS says what it looks like. Keeping those separate in your head now saves you months later.

In week 4 you find out who all this structure was for, and it turns out not to be you.

CSS gives you a visible result for every line you write, which is motivating and also the trap. It's the easiest phase to spend five weeks on and learn nothing durable.

So the order is deliberate: week 6 is about predicting, not decorating. Week 7 replaces taste with a system. Layout only arrives once you can describe what you're building instead of nudging it into place.

Eight weeks, the longest block of the year, and the one where people most often stall. So here's the warning up front: the first fortnight is harder than anything before it. CSS gave you something to look at for every line you wrote. JavaScript gives you a blank screen and an error message. That's the shape of the phase, not a verdict on you.

Weeks 11 to 13 stay in the terminal with nothing on screen at all. From week 14 the pace picks up sharply, because by then every project is the same three ideas applied to a different thing.

A deliberately lighter four weeks after the hardest stretch of the year. You've been committing since week 5 and pushing since week 10 without anybody explaining what either does. That turns out to be an advantage: every part of the model has something to attach to.

You already used fetch in week 16, so this isn't an introduction. It's the difference between using something and understanding it. By the end you can be handed documentation for a service nobody has taught you and build something with it, which is the point of the whole phase.

React is usually taught as a set of rules to follow. Here it's taught as the answer to a problem you've personally had: five projects of keeping a screen in step with a variable by hand.

That framing matters. Knowing what React replaces is what lets you tell when it's helping and when it's getting in the way, which is the difference between using a tool and being used by one.

For twelve weeks you've been the one asking. Now you write the computer that answers, and the change of position is what makes it click: every status code you choose, you've previously received. Every validation rule you write, you've previously been rejected by.

Also: the API key problem from week 16 finally gets solved, in week 36.

You arrive here having lost your data on every server restart for six weeks, which is the best possible preparation. PostgreSQL is the answer to a problem you've personally had.

The first week is design rather than SQL, because a bad schema is far more expensive to fix than bad code. Code you can rewrite in an afternoon. A schema with six months of data in it, you can't.

Everything in this phase already exists in pieces. What's new is the joins between them, and the joins are where the problems live: origins that don't match, shapes that disagree, rules enforced in the wrong layer, and failures that show up three layers away from where they started.

The thing that makes four weeks enough is finishing one feature completely before starting the next.

The building is done. These three weeks are about the difference between something that works and something that exists in the world, and then the part most programmes skip: explaining what you built, describing your own level honestly, and working out what happens when nobody is setting your schedule.

Short on purpose. You don't need to finish every course on this list. One main path per phase, plus documentation when you have a specific question, beats a folder of half-done tutorials.

Books worth having

• Eloquent JavaScript, Marijn Haverbeke. Weeks 11 to 18. Free to read online, and the exercises are worth doing slowly.
• Pro Git, Chacon and Straub. Weeks 19 to 22. Chapter 3's diagrams are why people recommend it.
• HTML and CSS, Jon Duckett. Weeks 2 to 10. A visual introduction, read alongside the practical work.

On videos

Video helps when a concept is hard to picture, and stops helping the moment hours watched becomes how you measure progress. Whatever you watch has to turn into something you type.

The loop that works: watch, understand, close the video, rebuild it from memory, then change one requirement. If your change works, the idea landed. If it doesn't, you've found exactly what you missed.

Turning up isn't what completes this. What completes it is what you can do at the end.

• You attended the sessions, allowing for school and everything else.
• You practised steadily across the year.
• You finished the main project sequence, at the level you actually reached.
• You used Git and GitHub properly, and your projects are documented.
• You can explain the important parts of your own code and how it's put together.
• You finished the capstone, or something we agreed instead.
• At least one full-stack project is deployed and reachable.
• Your portfolio is documented and up to date.
• You gave the final demonstration and wrote the year-end reflection.

The evidence is the work itself: projects that run, a repository history, documentation, and being able to change and explain your own code.

What happens after

A year of this gives you a foundation, not a qualification. What it opens up is further study, internships, supervised freelance work, contributing to open source, and a strong start on a computing course if you want one.

Where people usually go next: TypeScript, Next.js, testing properly, deeper backend work, software architecture, Docker and cloud platforms, security, mobile with React Native, or contributing to somebody else's project. You pick, based on what you enjoyed and what you kept wanting to build.

The last thing we do in week 52 is decide what you'll build on your own, starting the following week. A year of momentum with nothing planned afterwards tends to stop, and by then you won't need me to make progress. That's the whole point.