Well, we’ve reached that time of the year again, the end of the fiscal year. As such, it means that annual review season is upon us. People pushing for promotions, last Hail-Mary efforts on closing deliverables, collecting colleague feedback, pulling deals forward and pushing some out. On top of all that, we have to write out what we accomplished, how we accomplished it, and tell the story in a way that helps leadership understand our impact during people and reward conversations.
I’ve typically approached this by giving my leadership a sort of “baseball card” or one-pager that summarizes my year. It does the job. But it’s also easy to forget. At a certain level, everyone is producing these, and when leadership is reading 20 or 30 of them in the same format, they start to blend together.
This year I tried something different. I built a single HTML file. One page, four tabs, my own hero banner, hard numbers, real quotes, all branded the way I wanted. It sits in OneDrive, shares with one click, opens in any browser, and works offline. No login, no Power BI dependency, no broken links three months from now.
I want to take a moment to acknowledge that this is the work I built off of an idea a colleague shared with me. In a mentorship 1:1 with my colleague Sarath, we were discussing EOTY conversations with senior leadership. Sarath is the first one to show me how he was using HTML files for this specific deliverable.
What follows is how I built it, what made it work, and the blueprint I plan to take forward.
Why one HTML file beat a deck
Decks at the executive level fail in three predictable ways. They are too long. They are too templated. And they fight your story rather than carry it.
The HTML approach fixes all three.
It is scannable. A senior leader opens the file, sees the hero stats and the four headline KPIs in the first second, and decides on the spot whether to go deeper. No clicking through fourteen slides to find the punchline.
It is layered. The first screen is the executive summary. The tabs below it are where the proof lives. If the reader cares, they go in. If they do not, they close the tab and they still got the answer.
It is mine. A deck template makes me look like everyone else. My dashboard looks like me. The colors are mine. The voice is mine. The way I frame impact is mine. That carries signal.
And practically, it is portable. One file. No external dependencies. The headshot is base64’d into the HTML. The whole thing is forty KBs. I attach it in an email or drop it in a chat and it works.
What’s actually in it
Four sections, top to bottom:
- A hero banner. Name, role, tagline, five headline stats of the year. This is what a senior leader sees first.
- A KPI row. Four tiles immediately under the banner. Each one a number that matters with one line of context.
- Four tabs. Overview, Colleague Feedback, Deals Won, Thought Leadership.
- A footer. Source, scope, the boring disclaimer.
The Overview tab is the closest thing to a one pager. It has a performance band at the top (budget, forecast, variance), a “Year at a glance” paragraph, three hero quotes from colleagues, a map of my work against the published charter, and a 2x2 grid of priorities with what I led against each one.
The other three tabs are the receipts. Quotes verbatim. Deals in a sortable looking table with deal context written in plain English. Speaking engagements and field enablement with attendance numbers. Anyone challenging a claim on the front page can find the evidence two clicks away. These are themes built specific to my role, but this reusable template would support you updating with your core themes, pillars, or OKRs you care about showcasing impact towards.
The blueprint I wrote first
I will say something that sounds backwards. Before I asked the AI to build the dashboard, I wrote the blueprint.
Not the data. The structure. The editorial rules. The voice. The exact things I wanted the AI to do, and the exact things I did not want it to do.
A few examples from the file I handed over:
- No dashes anywhere in the visible copy. Replace with a comma, a space, or rewrite the sentence. I did not want it reading like AI output.
- “and” not “&” in section titles. The ampersand is reserved for branded names.
- Numbers always with thousands separators. Dates always in
DD MMM YYYYformat. - Verbatim quotes only inside attributed quote cards. Names, roles, dates.
- No emojis in headings.
That blueprint was about a thousand words. It took me about 30-minutes to flesh it out. I used one of my favorite agents “Prompt Buddy” to help me get my raw thoughts better organized. This saved me hours of correcting the AI output, simply by giving it very clear initial instructions.
Lesson: the more constrained your brief, the more useful the output. Spend the 30 minutes up front. You will thank yourself in iteration three.
The stack I used
Same setup as the website itself, candidly. Nothing fancy.
VS Code as the cockpit. This is where everything happens. The HTML file is one file, and VS Code makes it trivial to scroll through, edit, preview, and ship. I run a live preview in the side panel so any change I make shows up the second I save.
GitHub Copilot inside VS Code. This is the engineer. I describe the change I want in plain English (“the KPI tile for closed deals is showing the wrong number, pull it from the second row of the deals CSV instead”), and Copilot makes the edit across the file. When something does not look right, I screenshot and paste it in, and ask why. It explains.
A second AI chat open on the side. I keep a separate AI assistant open in another window for higher level questions. Things like “is this structure too sales coded for an executive read” or “rewrite this paragraph in fewer words, keep the voice.” Sometimes you want a brain that is not currently knee deep in your file. Copilot is great at the work in front of it. The side chat is great at sanity checking the work.
That is the entire stack. One editor, one AI in the file, one AI on the side. Nothing else.
The build, in plain English
The actual creation went something like this.
Building this prompt, I told it specifically what to look for. I uploaded our kickoff PPT which contained our core themes, pillars, individual metrics. I pointed my prompt at specific SharePoint files and internal documents that held information on performance. I included relevant PowerBI reports and URLs to colleague feedback. I then provided a deep and robust initial prompt to give the context of what I was trying to do, who I was trying to do it for, and where the information lived to successfully do so. The Initial prompt was nearly 500 words by the time I was done, but it was by far the most critical part. I knew I would need to iterate and trim, but I wanted a working mold to start from.
The first version came back in about ninety seconds. It was 80% there. The hero banner looked right. The KPI tiles had the wrong numbers in two places (the AI had pulled an unrelated row from the data file). The deals table was sorted backwards. One quote attribution had a wrong date.
Fixing the four problems took five minutes each. Twenty minutes later it was clean.
Then I spent another 2 hours on polish. Color tweaks. A dark mode toggle. Aligning the tagline under the headshot pixel by pixel because the eye notices. The kind of work where AI is fast but your taste is doing the steering. You will no doubt go back and re-write or recontextualize data or talking points that the AI pulls. The AI is great at getting you going, but this is where the human aspect comes in. If you’re going to put this in front of SLT, you better ensure the data is correct, the learnings are contextualized, and the details are coherent.
End to end, half an afternoon to get it 90%. Five to six hours all in to final product.
What made it actually work
A few decisions paid for themselves.
Self contained file. Inlining the headshot as base64 was the single best call I made. No broken images six months later. No “where is that asset hosted again” problem. The dashboard is the dashboard.
Strict editorial rules. The no-dashes rule sounds silly until you read AI output without it. Once I enforced it the prose stopped sounding like AI and started sounding like me.
Map every claim to the charter. The Overview tab maps my work directly against the three pillars and four core priorities published for my role this fiscal year. That is the trick that makes the dashboard feel like accountability rather than self promotion. The claims are not “look what I did,” they are “here is the assignment, and here is the proof I did it.”
Receipts over rhetoric. No adjectives doing heavy lifting. I do not call myself a leader. I show three quotes from colleagues describing leadership, with names and dates. The reader makes the judgment.
What I would do differently
A couple of things I would change next time.
I built it once at the end of the year. That was a mistake. The right move is to keep a working version updated quarterly. The data is fresh, the quotes are recent, and you are not racing the calendar in May.
I did not save the conversation history with the AI. When I went to rebuild a section weeks later, I lost the thread of why I had structured something a certain way. Now I keep a markdown log of the prompts that worked. (This is also what the blueprint does, for the record.)
I waited too long to share a draft for feedback. I should have shown the half-built version to two or three trusted colleagues a week earlier. The polish lap is more valuable when someone else has poked at the substance first.
The blueprint is reusable
The thing I am most proud of is not the dashboard itself. It is that the blueprint outlived it.
I sanitized the file. Stripped every customer name, every dollar figure, every quote, every internal acronym. Replaced them with placeholders. Now the blueprint is the structure, the design system, the editorial rules, and the prompts, with the proprietary stuff redacted.
That blueprint lives in a public GitHub repository. Anyone in any role can clone it, drop in their own data, and produce their own dashboard. Salespeople, engineers, marketers, designers. The structure works because the structure is about how senior leaders read, not about what I do for a living.
This is the part of vibe coding that I think gets undersold. The artifacts you produce are reusable. The prompt is reusable. The blueprint is reusable. The styling decisions are reusable. You are not building once. You are building a system you keep adding to.
Closing
Preparing for annual reviews is usually one of the worst parts of the year. You scramble in June, you forget half of what you did, you produce a deck that no one remembers a week later. There is a better version of this.
You do not need to be a designer, nor do you need to write code. You need to know what you did, what a senior leader cares about, and you need an AI that will translate the first into the second under your direction.
If you have a fiscal year ending soon, this is the easiest moment in history to put together a real impact artifact. Twelve months of work in one HTML file. Half an afternoon.
The blueprint is on my GitHub. Go take it.
Views expressed are explicitly that of my own.