You have built a complete system. It works, it is tested, it is measured and it costs what you said it would cost.

And now comes the part that almost nobody prepares and that decides half the outcome: telling the story.

This is not decoration or an academic formality. It is an observation repeated in every technical hiring process: of two candidates with equivalent projects, the one who can explain in three minutes why they chose Cloud Run instead of GKE, how much it costs per month and what happens when the database goes down gets the job; the one who shows a URL and says "it is built with Google Cloud" does not. The technical work is the same. The difference is that one of the two did the work of communicating it.

There is a structural reason for this. In any organisation, technical decisions are taken by people who have not built the system: a manager who decides the budget, a colleague who is going to maintain it, an interviewer who has forty minutes. If your work exists only in your head and in the repository, for all of them it does not exist. Communicating is not selling: it is making the work usable by others.

This lesson covers the seven pieces: the three audiences and how the message changes for each one, the structure of the presentation slide by slide, how to show an architecture without losing anybody, the demo with its script and its plan B, how to talk about numbers, the deliverable documentation with templates ready to copy, the honest self-assessment against the 08-01 rubric, the questions you are going to be asked with model answers, the peer review and the final clean-up.

1. Why communicating the work is part of the work
2. The three audiences
3. The structure of the presentation, slide by slide
4. How to show the architecture
5. The demo
6. Talking about numbers
7. The deliverable documentation
8. The self-assessment against the rubric
9. The questions you are going to be asked
10. The peer review
11. The final clean-up
12. The RefugioReserva presentation script

Before what to do, what to avoid. All four are extraordinarily common:

The antidote to all four is the same: decisions and numbers. "I chose Cloud Run instead of GKE because a cluster cost €100 a month from minute one and I did not need anything from Kubernetes; the system costs me €10.20 and handles 100 concurrent users with a p95 of 634 ms" is not a catalogue, it is not a tutorial, it does not apologise and it does not exaggerate. It is verifiable.

You are not demonstrating that you know how to use Google Cloud. You are demonstrating five things, and only one of them is technical:

1. That you take decisions and justify them. The most valued skill and the rarest.
2. That you know the constraints. Cost, time, complexity. An engineer without constraints is not an engineer.
3. That you finish things. One complete project, however small, is worth more than three half-finished ones.
4. That you know what you do not know. Acknowledged technical debt is a sign of maturity.
5. That you can work with others. Documentation, ADRs, runbook: all of that is for other people.

The same architecture, three different presentations. It is not make-up: the three audiences need to answer different questions.

Five sentences, zero jargon:

"The federation managed 12 refuges by telephone and with spreadsheets. They had seven overbookings a year and no data at all to decide where to invest. Now the bookings happen on their own, overbooking is impossible by design, and there is a dashboard with the occupancy of every refuge. It costs €10 a month and the whole thing can be switched off in five minutes if it stopped being of interest."

Notice what does not appear: no Cloud Run, no Terraform, no PostgreSQL. And what does: the problem in their terms, the result in their terms, the cost, and the reversibility — which matters to an executive more than it seems, because their fear is not that it will not work, it is being locked in.

Translating technical terms into business terms:

Here you do go into detail, but the axis is still why, not what. What a colleague wants to know: what trade-offs you accepted, what breaks first when something fails, where the debt is and how this is operated on a Tuesday at eight in the evening.

The section they value most, and that almost nobody prepares: "what I would do differently".

In an interview, the project is a pretext for talking about how you think. The interviewer is not going to audit your Terraform: they are going to ask you why, what you rejected, what happens if, and how much it costs.

The 90-second structure you must have memorised (they will ask for it literally: "tell me about a project of yours"):

"[Problem, 15 s] I built a booking platform for a fictional federation of mountain refuges, which managed 12 refuges by telephone and had overbookings.

[Architecture, 20 s] It is an application on Cloud Run against managed PostgreSQL with a private IP, with the photos in Cloud Storage, the events over Pub/Sub into BigQuery and a dashboard in Looker Studio. All in Terraform, deployed by CI/CD with no keys.

[The interesting decision, 30 s] The decision that made me think hardest was the database. Firestore was free and Cloud SQL cost me €8 a month out of a €12 budget. I chose Cloud SQL because the heart of the problem is capacity control, and I needed a transaction with a row lock: I wrote a concurrency test with twenty threads fighting over the last place, and with the naive implementation seven of them managed to book it. I offset the cost by shutting the database down overnight.

[The numbers, 15 s] It costs me €10.20 a month, it handles 100 concurrent users with a p95 of 634 ms, the whole thing is rebuilt from scratch in 14 minutes and I have rehearsed the rollback: 38 seconds.

[The honesty, 10 s] What I deliberately left out: there is no WAF, because the load balancer cost more than the whole project put together. It is documented as debt with its review condition."

Ninety seconds. Five blocks. Not a list of services, and yet seven of them are mentioned. Every claim is verifiable, and the last one invites a question instead of hiding.

Thirteen slides, 10-15 minutes. This is the full version (technical or mixed audience); for management you use slides 1, 2, 6, 7 and 12.

Slide 2 — The problem. It needs one concrete figure. "They managed bookings by telephone" is weak; "they managed bookings by telephone between 18:00 and 20:00, with one spreadsheet per refuge, and they had seven overbookings last year" makes the audience understand the pain in five seconds.

Slide 3 — Scope. Half the slide is what was excluded. Showing that you decided not to do payments, or a mobile app, or multiple languages demonstrates scope management, which is an engineering skill as valuable as writing code. And it defuses in advance the question "and why did you not do X?".

Slide 5 — Key decisions. Two minutes, three decisions, in table form:

This is the most memorable slide. If you could only show one, it would be this one. The "I rejected" column is the one that proves there was thinking.

Slide 11 — What did not work. Counter-intuitive and very effective. It contains your real incidents with their post-mortem and your prioritised technical debt. The reason it works: everybody knows a real system has problems. A project presented as perfect reads as a project that was barely used or barely understood. And no other slide generates as many good questions.

The title of every slide must be the conclusion, not the topic. "Cost" is a topic. "€10.20/month, 62 % less than the initial design" is a conclusion: if the audience only reads the titles, they have already taken away your whole presentation.

Never show all three at once, and never one that mixes levels. Choose according to the audience:

The most common mistake when presenting an architecture is walking through the boxes: "here we have Cloud Run, which connects to Cloud SQL, and also publishes to Pub/Sub, which in turn…". The audience can already see the boxes. They are reading while you talk, and you are competing with your own slide.

Instead of reading it, tell a journey. A user doing something:

"A hiker comes in and looks for places on 15 August. The request reaches Cloud Run, which queries PostgreSQL — that query is the one with the partial index, because it is the one that runs a thousand times. They book. At that point two things happen at once: the booking is written to the database inside a transaction with a lock, which is what prevents overbooking, and an event is published. The user already has their answer. The event goes on its way through Pub/Sub to BigQuery, and thirty seconds later the federation sees the booking in its dashboard. That separation is deliberate: the user does not wait for the analytics."

A minute and a half, zero lists, and the audience has understood the system and two design decisions.

1. What is exposed to the internet and what is not.
2. Where the data comes in and where it ends up.
3. What is synchronous (the user waits) and what is asynchronous (the user does not wait).

If your diagram does not make that clear without explanation, redo it before presenting.

Three minutes. The order matters because the impact is cumulative:

None of the three is functionality. All three are operations, which is exactly what separates a project from a demo:

1. A complete deployment, live. You change a line, do a git push, and the pipeline appears on screen: tests → build → deployment → smoke test. Four minutes on the clock, so you launch it at the start of the demo and come back to it at the end. The effect is hard to overstate: most portfolio projects are deployed by hand.

2. An alert firing. You cause errors, wait, and show the email arriving with the first steps written in it. It proves that the system tells you, which is what separates observability from pretty graphs.

3. A rollback. It is the most impressive of the three and the quickest. You deploy a deliberately broken version, the audience sees the error, you run ./scripts/revertir.sh, and in 38 seconds the system is healthy. Stopwatch on screen.

Choose one. All three do not fit, and the third is the one that says most about you in the least time.

Write it. Literally, with the timings:

The three rules of a demo that does not fail:

1. Rehearse it three times, the last one end to end without stopping. You will discover that one tab was slow to load and that the Looker Studio filter resets.
2. Everything open and preloaded before you start. Nobody wants to watch you hunt for a tab.
3. Never type a URL live. Nor write long commands. Everything ready, just press Enter.

Record the whole demo on video, with narration, and keep it open and minimised. It is not pessimism: it is that meeting-room wifi fails, a Google service has an incident, and your trial account expires on exactly that day.

And if you have to use it, say so naturally: "The wifi here will not let me; I have the demo recorded, it is exactly the same". Nobody penalises that. What does get penalised is spending three minutes fighting a loading screen.

An adjective is your opinion. A number is a verifiable fact, and it also proves three things at once: that you measured it, that you know where it comes from, and that you understand the constraint.

The last row is the one that works best, and it is counter-intuitive: admitting a fault found and fixed builds more trust than claiming there are none.

That slide demonstrates more engineering judgement than any diagram, because it shows decisions under constraint, which is what the real job consists of.

• If you did not measure it, do not say it. "I have not measured that" is a perfectly acceptable answer; inventing a figure you cannot back up is not.
• Give the context. "100 concurrent users" without saying against what configuration means nothing.
• Acknowledge what the number does not cover. "I tested 100 users; I do not know what happens with 1,000, although I can reason about it."

Five documents. None of them long, all of them useful.

The rule: two minutes of reading and whoever arrives knows what it is, whether it is useful to them and how to start it.