Your project is deployed, tested, measured and monitored. And yet there is an uncomfortable fact worth stating plainly: nobody knows about it, nobody understands what decisions lie behind it, and you have not yet practiced how to tell that story. Work you cannot show or defend is worth far less than it is — and not out of unfairness, but because whoever is evaluating it has ten minutes and no way of guessing what you did well. This lesson turns what you built into something you can show, defend and improve. You will see how to write a README that makes somebody understand the project in two minutes, with a complete annotated template; how to document architectural decisions with short records (ADRs), and why documenting the why is worth far more than documenting the what; how to prepare a five-minute demo with its script, its narrative order, its prepared data and its plan B; how to talk about the project in a technical interview — including the question you are certain to be asked, "why didn't you use React?" — how to acknowledge a limitation without sounding insecure and how to tell the story of a hard bug; how to assess yourself with a complete rubric across dimensions; how to review your own code and seek external review without being crushed by criticism; how to publish the project with a tidy repository, a clean history and a license; and how to iterate after delivery, which is what separates a finished exercise from a living product.

1. Why presenting is part of the work
2. The README that is understood in two minutes
3. The complete template, annotated
4. Screenshots, GIFs and the demo
5. Documenting decisions: ADRs
6. The ADR template and five real examples
7. Why the why is worth more than the what
8. The five-minute demo
9. The script and the order of the narrative
10. Prepared sample data and plan B
11. Talking about the project in a technical interview
12. "Why didn't you use React?"
13. Acknowledging a limitation without sounding insecure
14. Telling the story of a hard bug
15. Self-assessment with a rubric across dimensions
16. Reviewing your own code
17. Seeking external review and taking criticism
18. Publishing: repository, history and license
19. The portfolio
20. Iterating after delivery
21. Common Mistakes and Tips
22. Exercises
23. Conclusion

There is a widespread and false belief: that good work speaks for itself. It does not. What actually happens is this:

None of the four is going to read 4,000 lines of code to discover that your cycle detection in the tree covers all three cases. That has to be told.

And there is an argument that goes beyond the portfolio: explaining is a first-order professional skill. In real work you will spend a considerable amount of time justifying decisions, writing documentation, explaining to somebody why something will take longer than it seems, and defending one approach over another. Someone who builds well but cannot explain it has a very concrete professional ceiling, and it is not a technical one.

The good news is that this lesson does not ask you to invent anything: everything there is to tell you have already done. It is a matter of ordering it.

The README.md is your project's front page. It is read more than anything else you have written, including the code.

The two-minute test: give it to somebody who knows nothing about the project and time them. After two minutes they should be able to answer:

1. What is this and who is it for?
2. Does it work? Can I see it?
3. What is technically interesting about it?
4. How do I run it?

If they cannot, the README fails — however well written it is.

The four mistakes that make it fail the test:

The structure that works, in strict order of decreasing interest:

The three highlighted blocks carry the most weight: the opening sentence decides whether they keep reading, the technical decisions are what set your project apart from ten identical ones, and the limitations are what demonstrate maturity.

git clone https://github.com/user/orbita.git cd orbita npm install npm run dev # http://localhost:5173

npm test # 251 unit and integration tests npm run test:cov # with a coverage report npm run e2e # 3 end-to-end journeys (Cypress) npm run verify # lint + formatting + tests + build

src/domain/ Entities and rules R1-R15. No dependencies. Tested in Node. src/data/ Persistence and network. One contract, three implementations. src/view/ DOM, events and accessibility. Does not know where data comes from. src/application/ Use cases and state. Joins the three above.

The badges at the top are not decoration: at a glance they communicate that there is CI, that there are tests and that there is a license. They are one of the few things a technical recruiter interprets in two seconds.

The performance table with its methodology is an uncommon and highly valued detail: it shows you measured methodically, not that you ran Lighthouse once and got lucky.

The image is what gets looked at most and what usually gets the least care.

The seven rules of the README GIF:

1. Show the complete main flow, not an isolated click.
2. Realistic data. No "task 1", "test", "asdf". Use your own fictional but believable data.
3. Slow, deliberate mouse movement. Fast movements are dizzying.
4. No toolbars or browser tabs: only the application.
5. Under 3 MB, or GitHub will be slow to load it and many people will see a blank space.
6. Start and end in a clean state, so the loop does not jump.
7. 10–15 seconds. Any longer and nobody finishes it.

The live demo needs prepared data. An empty application demonstrates nothing, and asking a visitor to create six tasks to understand the product is asking too much. Two options:

• An automatic seed the first time, with a "Start from scratch" button.
• Demo mode via the URL (?demo=1) loading a sample data set.

And in either case, a clear notice: "Sample data. Everything is stored only in your browser."

An ADR (Architecture Decision Record) is a short document recording one important decision, its context and its consequences. It comes from a simple observation: the code says what was done, but never why, nor which alternatives were discarded, nor what should be revisited if the context changed.

When to write one. Not for every decision: only for those meeting one of these conditions:

For a project of this size, between 5 and 10 ADRs is the right number. Fewer than 3 suggests there were no decisions — which is unlikely — and more than 20 suggests you are documenting implementation details.

Where they live: in docs/adr/, numbered, in the repository, versioned with the code. Never in an external service: they drift out of sync.

The five sections are mandatory and none is superfluous:

The five minimum ADRs for this project:

And two optional ones that look very good if your project has them: optimistic updates with rollback and an append-only immutable history with anonymization instead of deletion.

Compare these two ways of documenting exactly the same thing:

The first comment is noise: it says what you can already read. The second contains information that exists nowhere else and that stops somebody — you — deleting that line six months from now thinking it is redundant.

The general rule:

That last row deserves emphasis. Discarded alternatives are the most valuable information and the fastest to be lost. Without them, whoever comes next will propose exactly what you already evaluated and rejected, spend a week finding out, and reach your same conclusion.

You are going to have to show your project: in an interview, to a colleague, in a presentation. Five minutes is the typical length, and it has to be prepared and rehearsed.

Why five minutes are hard. Because you know the whole project and you want to tell all of it. The discipline of demoing consists of choosing what not to tell.

The most common mistake, with a name: the guided tour of the interface. "Here is the board, here is the filter button, if I click here this comes up, and here we have another button…". It is boring, it has no narrative tension, and it says nothing about you. Nobody remembers a tour of buttons.

The order that works has the structure of a story:

A literal script for Orbita, timed. Adapt it word by word to your project:

Five rules for delivering the demo:

1. Rehearse it out loud at least three times, with a stopwatch. It takes 30 % to 50 % longer than you think.
2. Do not read the script. Learn the structure, improvise the words.
3. Do not show code unless asked, and if you bring it up yourself, make it one short, prepared fragment.
4. Do not apologize for anything. "This is a bit ugly", "I did not have time to…" subtracts without adding. Limitations go in step 5, delivered with confidence.
5. End with what comes next, not with "and that's it". Leave the feeling of a living project.

The data is half the demo. With "task 1", "task 2" and "test asdf", your product looks like an exercise. With believable data, it looks like a product.

What your demo data set should contain, and why each element:

All data fictional, always. Never use real names of colleagues, clients or acquaintances in a public demo or in a repository. It is a matter of respect and, if the project is published, of data protection. Taller Nómada and its team are fictional; yours must be too.

Plan B, which has to be prepared beforehand and not improvised:

A technical precaution that has saved many demos: have a 90-second video recording of the main flow. If everything fails — network, laptop, projector — you still have something to show. It takes half an hour to record and it is cheap insurance.

In an interview, your project is the best tool you have: it is the only thing you know more about than the person interviewing you.

What is actually being assessed when you talk about it is not what most people think:

The answer structure that works for "tell me about a project of yours", in about 90 seconds:

Step 5 is what turns a monologue into a conversation: you offer a choice, and the interviewer asks about what interests them. That always goes better than continuing to talk.

The questions you are going to be asked, with the key to each:

And the answer to "how would it scale?" deserves a note, because almost everybody answers it badly by improvising optimizations. The good answer starts with measuring:

"First I would measure. My baseline is with 500 tasks: render() at 44 ms and 1,380 nodes. At 10,000, the first thing to break would be the DOM, so I would virtualize the list, which is already prepared because render and update are separated. The second would be localStorage, which falls short at that volume: I would move to IndexedDB, and that only touches one file because the repository is a boundary with a tested contract. The third would be the report, which today recalculates in full; there I would memoize the selector."

That answer demonstrates three things at once: that you measure before optimizing, that you know your own numbers, and that your architecture was designed for it.

You are going to be asked. It is the most likely question of all if your project is plain JavaScript, and it is not a trap: they want to see whether you chose or whether you simply do not know React.

The three worst answers:

The good answer has three parts: judgment, honesty and knowledge of the other side.

"It was a decision, and I have the numbers. The product is a single application with a lot of domain logic — fifteen business rules — and little interface surface: seven screens. The team is me. In that context, the infrastructure I need to build myself is about two hundred lines: a store with subscriptions, reconciliation by data-id and event delegation. That is less than the cost of learning and maintaining a framework's conventions for this particular case.

And the figure that convinced me most: in the comparison I ran, the domain rules file was identical in plain JavaScript, React, Vue and Angular. The only thing that changed was the view. Since this project's value is in the domain, the framework added little here.

That said, I know exactly when I would change my mind: with three or more people on the team, or with more than fifteen or twenty screens, those two hundred lines of my own become a problem, because nobody else knows them and there is no documentation or community behind them. There React or Vue clearly pay off. In fact I rewrote the main screen in all four approaches so I could compare: 210 lines and 18 kB in plain JavaScript, 130 lines and 63 kB in React."

Why this answer works:

1. It starts by asserting it was a decision, not a limitation.
2. It gives the concrete context that justifies it: product, team, surface area.
3. It brings a number, not an opinion.
4. It states when you would change your mind, which is the mark of judgment as opposed to dogma.
5. It shows you know the alternative with numbers of your own.

And the honest variant if you have not done that comparison: do not invent it. Say what you can defend: "It was a decision based on the context — a product with a lot of domain logic and one person — and I know React well enough to know that with a team of three or with fifteen screens the balance would tip the other way. What I cannot give you are my own numbers from the comparison; I stopped at the reasoning." That is infinitely better than pretending.

The same scheme works for any "why not X?": TypeScript, Tailwind, a particular database. Context → decision → data → when you would change your mind.

There are three ways of talking about a flaw in your project, and only one works:

The three-part formula, which always works:

Three applied examples:

A limitation by scope decision:

"There is no calendar view. I cut it from the MVP because the date-sorted list covered the main need and the calendar was twelve hours for something secondary. It is on the roadmap as v1.1, and the model already supports it: only the view is missing."

An acknowledged technical limitation:

"Above two thousand tasks the performance would degrade: my baseline is measured with five hundred. I know because I measured, not because I assume it. The solution would be to virtualize the list, and the view already separates render from update precisely so that can be done without rewriting anything."

Something you would do differently:

"I started writing the view before the domain was settled and lost two days redoing work. As soon as I reordered it — domain first, then a vertical slice — the pace changed completely. It is the first thing I would do differently."

All three examples share the same things: they are concrete, they have a number or a reason, and they end in an action. None apologizes, and none hides anything.

A note about the README limitations, because it is a common worry: declaring them does not make your project look worse to whoever is evaluating it. It does the opposite. A project with no declared limitations conveys one of two things: either you have not looked for them, or you are hiding them. Both are worse than having limitations.

It is one of the most frequent questions in technical interviews, and the best opportunity you have to demonstrate how you think instead of what you know.

The SAR format — situation, action, result — structures the answer:

The classic mistake is spending 80 % on the situation ("it was really weird, there was no way to…") and 20 % on the action. It should be exactly the other way round: the action is what they are assessing.

A complete example, with the race condition bug from 11-04:

Situation. "On a slow network, sometimes — not always — marking a task as done made it come back as pending a second later. On my machine it never happened, and there was no error in the console."

Action. "The first thing was not to touch anything until I could reproduce it at will, because an intermittent failure cannot be debugged. I throttled the network and it happened one time in three, which still was not enough, so I wrapped fetch to delay only PUT requests by three seconds. With that it happened every time.

With the sequence in front of me I saw there were two asynchronous operations: the optimistic PUT, which took three seconds, and a list refresh fired half a second later that arrived first. The refresh replaced the whole list with data the server had generated before my change.

I wrote the failing test first, with fake timers to control the exact order, and only then touched the code. I evaluated three solutions: blocking refreshes while there were in-flight sends — fragile; versioning each task and discarding stale data — the most robust but dependent on the API; and merging while respecting the pending identifiers. I chose the third."

Result. "The bug disappeared and the test stayed in the suite as a regression test. What I learned and have applied ever since is two things: that an intermittent failure is almost always a race between two asynchronous operations, and that any code that replaces a whole state is suspect, because it discards information that may be more recent. I reviewed the rest of the application looking for that pattern and found another place just like it."

The six elements that make this a good answer:

1. A concrete symptom, with the detail that it was intermittent.
2. Reproducing first, stated explicitly as a principle.
3. A concrete technique: delaying only one kind of request.
4. The test before the fix.
5. Alternatives evaluated, with the criterion for choosing.
6. A generalizable lesson, applied afterwards. This is the one that carries the most weight.

Prepare two stories before any interview: one about a hard technical bug and one about a difficult design decision. Write them, time them at two minutes, and rehearse them out loud. It is not cheating: it is not depending on memory under pressure.

Before showing the project, assess it yourself. Honestly, because the goal is not the score: it is knowing what you will say when they ask you about the worst part.

Eight dimensions, 0 to 4 points each. Maximum 32.

The balance rule, which matters more than the total: a 3 across all eight dimensions (24) is better than a 4 in four and a 0 in the other four (16… or even a badly distributed 32). A brilliant project with no tests and no accessibility conveys an unbalanced profile; a project that is solid across the board conveys somebody you can work with.

The mandatory self-assessment question, and the most useful of all:

What is your lowest dimension, and what would you say if they ask about it?

Prepare that answer with the formula from section 13. You will be asked, and having it ready is the difference between looking self-aware and looking caught out.

Before publishing, review your own code as if it were somebody else's. It is uncomfortable and it finds things.

The procedure that makes the shift in perspective possible:

1. Let time pass. A day at minimum. Your brain fills in gaps in recent code.
2. Read the project's full diff in GitHub's web interface, not in your editor. The visual context switch works surprisingly well.
3. Go file by file, from the bottom of the architecture upwards: domain, data, application, view.
4. Note, do not fix. First the complete list; then the fixes. If you fix while reading, you lose the thread and the perspective.
5. Classify what you noted into three buckets: fix now, fix later (onto the roadmap), and accept (with the reasoning noted).

The complete checklist:

Points 12 and 13 are checked always before publishing a repository, no exceptions.

Your own review has an insurmountable limit: you cannot see what you do not know exists. That takes other eyes.

Where to ask, with realistic expectations:

How to ask for a review that helps. Vague requests get vague answers:

Always add: what the project is in one sentence, what you have tried, and what specific question you have. And link to a file, not to the whole repository.

How to take criticism, which is the hard part:

And the rule that helps most: criticism of your code is not criticism of you. It is hard to feel that way at first, and it is learned with practice. The mental shortcut that works: the person pointing out a flaw in your code is giving you information you did not have. It is the reaction of gratitude, not of defensiveness, that makes people review your work again.

And not all criticism is accepted. "You should use React" without knowing your context is not actionable criticism. Listen, weigh it up, and if it does not apply, say thanks and move on. Accepting everything you are told is as bad as accepting nothing.

Before making the repository public, a final review:

Point 1 has a nuance that surprises a lot of people: deleting a secret in a later commit does not remove it from the history. It is still there, accessible with git log -p. If you ever committed one, the only correct response is to rotate it (change the key in the service); rewriting the history is optional and not sufficient on its own.

A clean history. A readable git log is a sign of professionalism that reviewers look at more than you think:

If your history is a mess, you have three honest options: leave it and learn for the next one (perfectly acceptable), clean up only the most recent part, or start a new repository with a careful history if you are at the beginning. What you must not do is rewrite the history of a shared branch.

The license, with what you need to know:

That last point surprises a lot of people: a public repository with no license is not public domain. By default, full copyright applies, and nobody can legally copy, modify or use it. If you want your project to serve as a portfolio and for somebody to be able to draw inspiration from it, add a license.

And two warnings:

• Check your dependencies' licenses. Most are MIT or similar and cause no trouble, but it is worth looking (npx license-checker --summary).
• None of this is legal advice. For a personal portfolio project, MIT is a safe and common choice. For a commercial product, get advice.

Your project has to appear where people will look for it:

On the CV, the format that works:

What makes that block good: there are concrete numbers (15 rules, 251 tests, 96 %), there are concepts that demonstrate level (layered architecture, budgets in CI, idempotency), and there are links. There are no empty adjectives: no "robust", no "scalable", no "modern".

One well-told project is worth more than three half-done ones. If you have several, pick the best, tell it fully, and mention the others in one line.

Here is the difference between an exercise and a product: an exercise is delivered and it ends; a product has a next version.

How to get real feedback, which is the most valuable thing and the least often done:

The technique of watching somebody use it deserves detail because it is brutally effective and almost nobody applies it: you give them a task ("create a task with two subtasks and find out who is most loaded this week"), you keep quiet, and you observe. The rule is never to help. Every time you feel the urge to say "you have to click there", that is a design flaw you have just found. With three people you discover 80 % of the usability problems.

How to prioritize what comes in. Not everything gets done, and deciding is the skill:

With a preliminary filter of three questions for each request:

1. How many people have asked for it? One passionate request from one person is not a trend.
2. Does it fit the product sentence (11-01)? If not, it is probably a different product.
3. What breaks if I do it? Every new feature adds surface area to maintain.

Planning the next version is repeating the 11-01 cycle in miniature: pick three or four things, write them as stories with criteria, estimate with your correction factor now calibrated by the previous project — which is now real and not an assumption — and set yourself a date.

And a note on when to stop. Not every project has to continue forever. A project can be finished in the sense that it delivers what it promised. If you decide not to continue, say so in the README:

That is far more honest than a repository whose last activity was two years ago with a roadmap full of unticked boxes.

A README that starts with installation. Whoever lands there is not interested in installing anything until they know what it is and what it is for. Name, sentence, image, demo, problem — and then the rest.

Not including any image. It is the most expensive README failure, because 90 % of the people who open it look for an image before reading a word. A twelve-second GIF is worth more than three paragraphs.

Listing technologies instead of saying what the product does. "React, Redux, Tailwind, Vite" does not say whether it is a task manager or a game. Technologies go in the decisions section, with their reasoning.

Hiding the limitations. They get discovered anyway, and then it looks like you were hiding them. Declaring them builds the most credibility, and it is what almost nobody does.

Documenting the what instead of the why. A comment repeating what the code says is noise that also goes out of date. The why, the discarded alternatives and the context are the only things the code cannot tell you.

A demo that is a tour of buttons. With no problem at the start, there is no narrative tension and nobody remembers anything. Problem, solution, one complete flow, one technical detail, limitations.

Demoing with test data. "Task 1", "asdf", "test test" make your product look like a classroom exercise. Prepare a believable, fictional data set.

Not rehearsing the demo. It takes 30–50 % longer than you think, and without rehearsal you hit minute five halfway through. Three run-throughs out loud with a stopwatch.

Answering "I don't know React" to "why didn't you use React?". It turns a decision into a limitation. Context, decision, data, and when you would change your mind.

Apologizing for your project. "It is a bit ugly", "I ran out of time". It subtracts, adds nothing, and invites people to look exactly where you do not want them to. Limitations are framed, not apologized for.

Publishing without reviewing the history. A secret committed three months ago is still accessible with git log -p. If it happened, the answer is to rotate the key, not just delete it.

Publishing with no license. A public repository with no license cannot be legally used by anybody. If it is a portfolio, MIT and be done.

Tip · Write the README as if it were for somebody in a hurry with no context. Because it is. Short sentences, tables, lists, and the important things at the top.

Tip · Keep the GIF and screenshots in the repository, in docs/images/. External image services expire and leave holes in your README two years from now.

Tip · Write ADRs the same day you make the decision. Reconstructing the reasoning a month later is impossible: you will remember the conclusion, not the alternatives or the why.

Tip · Rehearse the demo by recording yourself. It is uncomfortable to watch yourself, and it is the fastest way to spot filler words, rushing and the parts where you lose your way.

Tip · Have two stories prepared, a hard bug and a design decision, written and timed at two minutes. You will be asked for them, and you will not want to improvise.

These exercises close milestone H6 of your project: README, ADRs, demo script and a completed self-assessment.

Exercise 1 — The README and the ADRs.

1. Write the complete README.md with the template from section 3, adapted to your project: identity with badges, image, demo, problem, features, a technical decisions table with links to ADRs, how to run it, tests with real numbers, architecture, known limitations, a performance table with methodology, roadmap and license.
2. Record a 10–15 second GIF of the main flow meeting the seven rules from section 4, stored in the repository, under 3 MB.
3. Prepare the demo data with the seven elements from the table in section 10, all fictional, and add demo mode or the automatic seed.
4. Write at least five ADRs with the complete template from section 6, with their five sections — including the negative consequences and the "when to revisit" — and with at least two evaluated alternatives in each.
5. Run the two-minute test: give the README to somebody who does not know the project, time them, and ask them to answer the four questions. Note what they could not answer and fix the README.

Exercise 2 — The demo and the interview answers.

1. Write the five-minute script with the five-step structure, with the timings noted and what you will say at each step.
2. Rehearse it three times out loud with a stopwatch and adjust it until it fits in five minutes with room to spare.
3. Record yourself doing it and review it. Note three things to improve.
4. Prepare the complete plan B: the table of six situations adapted to your context, plus a 90-second recording of the main flow as a last resort.
5. Write and rehearse the answers to these six questions, each in under two minutes:
   • "Tell me about this project" (the five-step structure from section 11).
   • "Why didn't you use React?" (or whichever framework applies), with context, decision, data and when you would change your mind.
   • "What is the worst part of your project?" (the three-part formula from section 13).
   • "Tell me about a hard bug" (SAR format, with a generalizable lesson).
   • "How would it scale to 10,000 items?" (starting with measuring).
   • "What would you do differently?" (concrete and technical).

Exercise 3 — Self-assessment, review and publication.

1. Complete the rubric of eight dimensions from section 15, with a one-sentence justification for each score. No scoring from memory: open the project and check.
2. Identify your two lowest dimensions and write a concrete plan for raising them, with the estimated effort.
3. Prepare the answer to "what is your weakest point?" with the three-part formula.
4. Do the self code review with the 16 checks from section 16, after letting at least a day pass. Document the findings classified into the three buckets: fix now, fix later, and accept with the reasoning.
5. Ask for an external review with a specific question about a specific part. Document what you were told, what you accepted and what you discarded with the reason.
6. Get at least one person to use your application while you watch, without helping. Note every moment of hesitation: each one is a design flaw.
7. Run the 10 pre-publication checks from section 18, including the Git history one. Add a license, description, topics and demo link.
8. Add it to your portfolio: pinned repository, profile README, and the CV block with concrete numbers.
9. Plan the next version: three or four improvements prioritized with the impact/effort matrix, written as stories with criteria, and with a date.

Rubric for exercise 1 — README and ADRs (24 points)

Threshold: 17/24, with a mandatory ≥ 2 in "The two-minute test" and in "ADRs: quality".

Acceptance criteria for exercise 1

Acceptance criteria for exercise 2 — Demo

Rubric for exercise 3 — Review and publication (21 points)

Threshold: 14/21. With one condition that cannot be traded away: zero secrets and zero real personal data, not in the code, not in the history and not in the screenshots.

The project's final self-assessment. Before considering the milestone closed:

You have turned a project that worked into a project that can be shown, defended and improved — and that difference is worth as much as the code.

You know why presenting is part of the work: because nobody is going to read 4,000 lines to discover what you did well, because whoever is evaluating you has between 90 seconds and 15 minutes, and because explaining decisions is a first-order professional skill that anybody who builds well but cannot tell the story runs into.

You have a README that passes the two-minute test, with the decreasing-interest order that works: identity, image, demo, problem, features, technical decisions — the section that sets you apart from ten identical projects — and known limitations, the section that builds the most credibility and that almost nobody writes. With badges that communicate in two seconds, with the performance table accompanied by its methodology, and with instructions that work copied and pasted. And with a GIF that meets the seven rules, because the image is the first thing people look at and usually gets the least care.

You have ADRs for the five decisions that deserve them, with the five mandatory sections — context, evaluated alternatives, decision, consequences including the negative ones, and when to revisit — and you know why the why is worth more than the what: the code says what was done, the names and tests say how, but only an ADR says why not it was done the other way. That is the most valuable information and the fastest to be lost, and without it whoever comes next will spend a week reaching your same conclusion.

You have a five-minute demo with the structure of a story instead of a tour of buttons: problem, solution, one complete flow, one technical detail told well, and limitations with a roadmap. With the five delivery rules — rehearse three times with a stopwatch, do not read, do not show code unless asked, do not apologize for anything, and end with what comes next — with fictional, believable data containing the seven elements that make the product explain itself, and with a plan B for six situations plus a 90-second recording that is the cheapest insurance there is.

You know how to talk about the project in an interview understanding what is genuinely assessed: not how many technologies you used but why; not whether it is big but whether it is finished; not whether it is perfect but whether you know its flaws. You have the five-step structure ending in a hook — "if you like, I can show you…" — that turns a monologue into a conversation. And you have prepared the question you are certain to be asked, "why didn't you use React?", with the three worst answers identified and a good one built on context, decision, a number of your own and — what separates judgment from dogma — when you would change your mind. With the honest variant for when you do not have the number, because inventing it always turns out worse.

You know how to acknowledge a limitation without sounding insecure with the three-part formula — what is missing, why it is that way, what you would do — which turns a flaw into a demonstration of judgment. And you know how to tell the story of a hard bug in SAR format, devoting half to the action and not to how strange it was, with the six elements that make it good and, above all, with a generalizable lesson you applied afterwards.

You have assessed yourself with a rubric of eight dimensions and 32 points, knowing that balance matters more than the total — a 3 across all eight is worth more than a 4 in four and a 0 in the rest — and with the mandatory question answered: which is your lowest dimension and what you will say when asked about it.

You know how to review your own code with distance, in the web interface, from the bottom of the architecture upwards, noting before fixing and classifying into three buckets. And you know how to seek external review with specific rather than vague requests, and to take criticism with the rule that changes everything: whoever points out a flaw in your code is giving you information you did not have. With the nuance that not all criticism is accepted, and that accepting everything is as bad as accepting nothing.

You know how to publish with the ten pre-publication checks, including the surprising one — that deleting a secret does not remove it from the history, and that the only correct answer is to rotate the key — with a readable history, and with a license, because a public repository with no license cannot be legally used by anybody. And you know how to put it in your portfolio with concrete numbers and no empty adjectives.

And you know how to iterate after delivery, which is the difference between an exercise and a product: watching somebody use it without ever helping — every urge to help is a design flaw found — prioritizing with the impact/effort matrix and the three filter questions, and planning the next version by repeating the 11-01 cycle with an estimation factor that is no longer an assumption but a fact from your own project. Or honestly declaring that it is finished, which is also a valid answer and far better than an abandoned roadmap.

Milestone H6 is closed, and with it the project: planned, built, persisted, tested, deployed, documented and defensible. One lesson remains, and it is not about the project: it is the balance sheet of everything you now know, the map of what comes next — TypeScript, Node.js, a framework in depth, the web platform, your career — and how you keep learning when there is no longer a course telling you what comes next. It is Next Steps: TypeScript, Node.js and Your Career.