DEV Community: πn

GHOSTLIGHT: Stadium of Echoes Cover

πn — Sun, 01 Nov 2026 06:56:40 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

Football Remembers the Scores. We Remember the People.

🏟️ Live Showcase: https://ghostlight-stadium-of-echoes.onrender.com

📦 Source Code (GitHub): ghostlight-stadium-of-echoes

A football match lasts 90 minutes.

Sometimes 120.

But a memory can last a lifetime.

For some people, it's the roar of thousands of supporters. For others, it's the smell of wet grass, the glow of floodlights through the rain, an old ticket kept in a drawer, or the feeling of holding someone's hand while watching a match for the very first time.

Years pass. Stadiums are renovated or torn down. Tickets fade. Results become statistics in databases.

But the memories remain.

Football remembers the scores. GHOSTLIGHT remembers the people.

That’s the idea behind GHOSTLIGHT: Stadium of Echoes — a cinematic, interactive digital sanctuary where forgotten football memories come back to life through locally running open-weight AI.

Hero: The Forgotten Stadium under midnight floodlights.

The Idea: A Stadium Full of Memories

The theme of the Hacktoberfest 2026 Ghost in the Machine challenge inspired me to explore a different kind of digital ghost.

Not a ghost that scares people.

A ghost that preserves something worth remembering.

I wanted to build an experience that connects football heritage, personal storytelling, open-weight artificial intelligence, and digital preservation.

The result is an interactive night stadium.

At first, it is almost completely dark. Its stands are silent. Only a few distant floodlights cut through the midnight mist.

Then someone leaves a memory.

An old matchday photograph. A ticket stub. A scarf. A few sentences about a football match experienced decades ago.

The AI helps transform that fragment into a living digital exhibit.

A section of the grandstand illuminates.

And the memory finds its eternal seat.

How It Works

GHOSTLIGHT is designed around a three-step emotional loop:

Leave an artifact → Awaken a memory → Explore its echoes.

1. The Forgotten Stadium

The experience begins in an atmospheric football cathedral at night. The interface uses a midnight palette of near-black, deep navy, and warm luminous gold.

Volumetric floodlights, animated fog, drifting particles, and editorial typography create the feeling of entering a place suspended between the past and present.

The main invitation is simple:

SOME MEMORIES NEVER LEAVE.

Users can awaken a new memory or explore the existing archive.

2. Leave an Artifact

Users can awaken a memory by entering:

A story or personal recollection: A heartfelt paragraph of what they experienced.
An approximate year: e.g., 1968, 1982, or 1998.
A football club or team: The colors they cheered for.
A stadium, if known: The cathedral where it occurred.
An optional photograph or visual artifact: Uploaded via drag-and-drop.

The uploaded artifact becomes the centerpiece of the exhibit.

The system does not require users to know every historical detail. An incomplete memory is still deeply worth preserving.

3. The Ghost Awakens — Gemma Meets Ollama

This is where open-weight AI becomes the heartbeat of the experience.

GHOSTLIGHT uses Google Gemma 3 4B, running 100% locally through Ollama.

Instead of sending personal family stories to a remote commercial cloud, the client communicates with a local Express backend, which prompts the local model with strict archival guardrails.

The model transforms the submitted recollection into structured exhibit data:

Title: An uppercase poetic exhibit name.
Approximate year: Historical era anchoring.
Theme and emotional character: e.g., "Ancestral Reverence", "First Floodlight Glow".
Narrative: An evocative, respectful story capturing the sensory atmosphere.
Closing inscription: A stone-carved epitaph for the grandstand plaque.
Tags: Connecting historical motifs.
Grounded recollections: Confirmed facts stated by the user.
Unknown or missing details: Respectfully cataloged as "Lost to the stadium winds".

The Ethical AI Principle: Enrich, Never Rewrite History

The system strictly distinguishes information explicitly provided by the user from details that remain unknown.

It never invents match results, fictional player lineups, attendance figures, or synthetic deceased voices simply to make a story sound complete.

A missing scoreline is not a bug to fix. It is part of what makes a human memory authentic.

4. The Memory Reveal

Once the memory has been processed during the floodlight power-up séance, the stadium begins to awaken:

A newly allocated seat in the grandstand lights up.
The exhibit title emerges in gold typography alongside the original uploaded artifact.
Two distinct columns tell the story:
- Grounded Recollections: Details verified by the person who submitted the memory.
- Lost to the Winds: Information that remains forgotten in time.

The closing inscription might read:

“Some matches never end.”

5. A Stadium That Speaks

I wanted the experience to engage the ears as deeply as the eyes.

GHOSTLIGHT includes two narration styles:

Tannoy: An authentic stadium announcer voice, preceded by a synthesized two-tone stadium bell chime (D5 587Hz -> A4 440Hz).
Whisper: A quieter, intimate museum-style narration.

The browser's native SpeechSynthesis API provides the voice. Meanwhile, a procedural Web Audio API soundscape adds a subtle stadium night hum, while the Rain Derby weather mode introduces synthesized rainfall and a stormy visual atmosphere.

Listening to a memory feels like attending a quiet private ceremony under the lights.

6. The Vintage Matchday Ticket

Vintage Matchday Ticket: A physical-digital keepsake generated dynamically on HTML5 Canvas.

One of the most distinctive details is the Vintage Matchday Ticket generator.

Every memory can become a high-resolution (1200x520px) digital keepsake:

Authentic perforated edges with cutout notches.
Archival exhibition title.
Stand, sector, and seat coordinates.
Period-inspired ink stamps (PRESS ARCHIVE • AUTHENTICATED or ALL HALLOWS' SPECIAL).
Procedural retro turnstile barcodes and serial numbers.

Users can toggle between the Museum Exhibit Plaque and the Vintage Matchday Ticket, exporting either as a print-ready PNG image. It turns fleeting digital text into a tangible souvenir worth keeping.

7. The Living Stadium and Echo Threads

Echo Threads: Luminous Bézier arcs connecting strangers through shared history.

The stadium is more than a backdrop — it is a living entity.

Every saved memory occupies an illuminated coordinate in the stands:

North Stand: Family devotions and childhood memories.
South Stand (Kop): Passionate chanting and terrace anthems.
West Grandstand: Press boxes and tactical heritage.
East Terrace: Historic standing terraces in the rain.

The Echo Threads feature takes this further: it automatically calculates and draws glowing Bézier curves between memories that share:

The same decade (e.g., the 1970s or 1990s).
The same football club.
A common emotional resonance.

Someone who remembers a rainy cup match in 1989 is visually connected to someone else who cheered for the same club in that era. The stadium becomes an illuminated web of collective human belonging.

8. A Museum That Belongs to Its Owner

Digital preservation should never mean handing ownership of personal memories over to an ad-driven cloud platform.

GHOSTLIGHT follows an uncompromising local-first approach:

All memories and high-res artifact images are stored directly in your browser's IndexedDB.
The archive provides full-text search, decade filters, card downloads, and JSON metadata exports.
The Time Capsule: Users can export their entire stadium collection into a self-contained .ghostlight.json file, and import it onto any other computer or browser.

The museum belongs entirely to the person who created it.

Technology Behind the Experience

Component	Technology
Frontend	React 19, TypeScript, Vite 8
Styling	Tailwind CSS v4 (with zero-CLS theme variables)
Animation	Framer Motion (spatial canvas transitions)
Backend Proxy	Node.js, Express 5
AI Model	Google Gemma 3 4B (Instruct)
Local Runtime	Ollama
Persistence	IndexedDB via `idb`
Narration	Native Browser `SpeechSynthesis`
Acoustic Soundscape	Web Audio API (realtime Tannoy chime + weather synthesis)
Graphics & Artifacts	HTML5 Canvas 2D image renderer

Architectural Flow:

  USER
    │
    ▼
  REACT 19 + VITE CLIENT
    │
    ├───► INDEXEDDB (Local Private Storage)
    │
    ▼
  EXPRESS 5 API (Port 3001)
    │
    ▼
  LOCAL OLLAMA ENGINE (Port 11434)
    │
    ▼
  GOOGLE GEMMA 3 4B (Strict JSON Mode)
    │
    ▼
  STRUCTURED MEMORY EXHIBIT
    │
    ▼
  MEMORY REVEAL (Seat Coordinates + Tannoy Audio + Vintage Ticket PNG)

The core AI workflow does not require a cloud LLM subscription or an API key. Everything runs on the hardware right in front of you.

Why Open Innovation Matters

Running an open-weight model locally is not merely an engineering preference for GHOSTLIGHT. It is a core product principle.

Personal photographs, deceased relatives' tickets, and intimate family memories are sacred. They deserve far better protection than being sent to third-party cloud servers for training or surveillance.

Using Gemma 3 through Ollama gives GHOSTLIGHT five vital guarantees:

Privacy & Control: Memory text is processed on the user's machine without ever touching an external API.
Independence: The application will work twenty years from now, even if commercial AI APIs vanish or change their pricing models.
Accessibility: Anyone with consumer hardware can run the model locally.
Ownership: The archive and its .ghostlight.json Time Capsule remain strictly under the user's control.
Reproducibility: Any developer can clone the repository, pull gemma3:4b, and immediately experience the full installation.

What I Learned

One of the biggest lessons from this project is that AI applications do not always need to revolve around a conversational chatbot.

Sometimes the most profound interface for an AI system is a spatial experience.

Gemma does not need to act like a sports statistician or guess match scores. Its role is far more human: helping people structure raw emotions, giving them an archival form, and preserving the sensory essence of a moment.

The small details are what bring the soul to life:

The two-tone Tannoy chime before a story is spoken.
The perforated tear-off line on a vintage matchday ticket.
A single golden seat igniting in a darkened grandstand.
A glowing thread connecting two strangers across fifty years of football history.

These details transform GHOSTLIGHT from another AI demo into an authentic place of reverence.

What's Next?

GHOSTLIGHT began with football, but the underlying philosophy can expand into many cultural realms:

Supporter Club Heritage Archives: Preserving historic community memory before legendary stadiums are renovated.
Family Legacy Museums: Honoring passed generations and their shared passions.
Historical Places & Vanished Landmarks: Reviving theaters, concert halls, and community centers.

The long-term ambition is to give communities the tools to preserve the human stories that official archives overlook.

Running Locally:

Install Ollama and download the model:

ollama serve
ollama pull gemma3:4b

Clone and start the application:

git clone https://github.com/budulay/ghostlight-stadium-of-echoes.git
cd ghostlight-stadium-of-echoes
npm install
npm run dev

Open in your browser:

http://localhost:5173

The sample memory can also be explored instantly without live AI inference. For real-time memory analysis, ensure Ollama is running with gemma3:4b.

The Final Whistle

I started with a simple question:

What if we could preserve the feeling of a football match, not just its score?

A stadium is far more than concrete, grass, and plastic seats.

It is a place where generations meet. Where friendships begin. Where families forge traditions. Where complete strangers hug in the pouring rain when a goal crosses the line in the 93rd minute.

And perhaps somewhere, in an old drawer, there is still a faded ticket from a match that nobody else remembers.

That ticket deserves a place.

That story deserves a light.

Football remembers the scores.

GHOSTLIGHT remembers the people.

The final whistle is not the end of a memory.

🏟️ GHOSTLIGHT: Stadium of Echoes — Where memories never die.

TouchGrass FC: a Telegram bot whose only goal is to make you close Telegram

πn — Mon, 12 Oct 2026 06:05:27 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Every pickup football group has the same thread. "Saturday?" "Maybe." "What time?" "After work." "Which Saturday?" Twenty messages later, nobody has committed and nobody has played.

TouchGrass FC is a Telegram group bot that replaces that thread with one question and one poll. Someone types /play, and the bot asks everyone to reply with when they can make it, in their own words and whichever language they type in (it's built for Ukrainian, English, Spanish, German, Polish, French, Russian). A local Gemma model turns each reply into structured availability. From there it's plain code: check the 7-day forecast, drop any slot that wouldn't finish before sunset, pick the best one, find the nearest pitch on OpenStreetMap, and post exactly one poll with a map pin. Then the bot goes quiet, except for a reminder three hours before kickoff and one question afterwards: did you actually play?

That's the whole design for this week's theme. Per player, the interaction is one message and one tap on the poll. Per match, it's one /played from whoever remembers. The only metric I care about is the one /stats reports: ⚽ Matches actually played via this bot: N. (The bot's reply to /played is "Legendary. Logged. Go shower." Good advice, honestly.)

Did anyone actually touch grass?

Not yet, and I'd rather say so than invent a match. I've run the full loop in a live Telegram chat: messy replies in; weather score, pitch pin and poll out; reminder queued. But any number you see on /stats in my demo comes from me pressing the button to test it, not from a game. I'll update this post after the first real one.

Demo

The bot runs on my machine, so there's no live link. Here's a walkthrough in a real Telegram chat:

No bot token? python -m touchgrass simulate replays a scripted group chat in your terminal (more on that below).

Code

budulay / touchgrass-fc

A Telegram group bot that turns messy "when can you play?" chatter into ONE poll for a real-life pickup football match — then goes quiet so people actually go outside.

touchgrass-fc

A Telegram group bot that turns messy "when can you play?" chatter into ONE poll for a real-life pickup football match — then goes quiet so people actually go outside.

View on GitHub

MIT licensed, and a brand-new repo started during the challenge window.

How I Built It

One rule shaped everything: the model only gets the job code can't do, which is reading human messages. Everything else is boring, testable code.

Python 3.11+, aiogram 3: long polling (no server needed), privacy mode ON
Gemma 3 via Ollama: local inference, with Pydantic v2 validating every output
SQLite (aiosqlite): all state stays on the machine
Open-Meteo, Nominatim, Overpass: free and keyless; weather and map lookups are the only things that leave the machine

Reading messy messages

People don't write schemas. "можу в суботу після 18, якщо не дощ", "Sat morning I'm in" and "пятница после обеда" all have to land in the same structure. Ollama's format parameter accepts a JSON schema, so each request carries the Pydantic model's schema, at temperature 0 (abridged):

payload = {
    "model": model,
    "stream": False,
    "options": {"temperature": 0},
    "format": _SCHEMA,  # Pydantic JSON schema
    "messages": [{"role": "system", ...}, {"role": "user", "content": message}],
}

For the first message above, the output looks roughly like this (abridged):

{
  "can_play": true,
  "slots": [{"weekday": "saturday", "start": "18:00", "end": null}],
  "conditions": ["no_rain"],
  "language": "uk"
}

If validation fails, the error goes back to the model together with the original message, once. If that fails too, the bot asks the player to rephrase instead of guessing. One gotcha worth passing on: Ollama's format wants the complete JSON Schema object, not just the $defs block that Pydantic nests sub-models under.

The planner is deliberately dumb

score = player_count × weather_score. Weather score is a 60% rain penalty plus a 40% wind penalty, averaged over the slot window. Any slot ending after sunset (with a 15-minute buffer) is filtered out before scoring. No LLM involved: it's just numbers, which means it's unit-tested on recorded fixtures instead of vibes.

Does the model actually work?

The repo has 40 labelled messages in Ukrainian, Russian and English: slang, negations, conditionals, vague ranges like "можу в будь-який день після 19". The eval harness runs them against each Gemma size:

Model	Overall	can_play	language	slots	conditions	avg_lat	p95_lat
`gemma3:1b`	18%	45%	48%	55%	80%	6.6s	16.1s
`gemma3:4b`	28%	88%	50%	72%	88%	23.2s	36.1s

The Overall column is the harshest number in the table, and I'm showing it anyway. Per field, gemma3:4b is reasonable at what the planner needs most: whether someone can play (88%), under what conditions (88%), and roughly when (72%). Language detection sits around 50% for both sizes; it mostly decides which language the invite is written in, and I haven't dug into why it's so weak yet.

Speed is the other cost. On my machine [TODO: one line on your hardware, e.g. "a laptop with no GPU"], gemma3:4b takes 23 seconds per message on average (p95: 36 s). gemma3:1b is about 3.5× faster but gets can_play wrong more than half the time. So 4b is the default, and when it returns garbage the bot asks instead of guessing. For a group that coordinates once a week, I can live with 23 seconds. For anything conversational, I couldn't.

Try it without Telegram

python -m touchgrass simulate replays a scripted group conversation in your terminal, runs the real planner on synthetic weather, and prints a transcript. If Ollama is running, it uses the real model, so you'll wait as long as the numbers above suggest. If it isn't, it falls back to canned parses: you see the flow in seconds, but you're not seeing the model.

What doesn't work (yet)

The pitch search finds pitches that exist in OpenStreetMap. It has no idea whether one is free or bookable.
One location per chat, set with /setlocation.
Privacy mode stays on, so the bot only reads replies to its own message and /in. If you don't reply to the bot, as far as it knows you don't exist.

Why Does Open Innovation Matter?

I didn't benchmark a hosted model, so I won't pretend to know by how much it would beat a 4B Gemma on accuracy or speed. My guess is easily. Here's what going open bought me instead:

Nobody new reads the chat. The messages already live in Telegram. The question is whether a second company's API also gets to read who's free on Thursday evenings. Here, inference runs on the same machine as the bot, so it doesn't.
A model I can pin, swap and measure. I picked an exact model tag and ran the same 40 fixtures against two sizes; the table above is the result. Going from 1b to 4b is one environment variable (OLLAMA_MODEL), and nothing changes underneath me between runs.
Contributors don't need keys. The extraction schema is a Pydantic model in nlu.py, and the 29 tests run without network access. Anyone can change the schema, rerun the suite and open a PR without asking me, or a vendor, for credentials.

Cost, honestly, isn't an argument at this scale: a few dozen inferences are cents on any hosted API. It only becomes one when a bot like this has real users.

My Agent Session

I built this in Google's Antigravity from one written brief, split into three parallel workstreams: language understanding plus the eval fixtures; planner, weather and pitch lookup; and the Telegram layer plus the simulator. The agent wrote the code, the 29 tests and the first draft of this post. I ran the result in a live Telegram chat, then edited this write-up.

Prize Categories

Best Use of Gemma: Gemma 3 (via Ollama) is the only model in the project. It does the multilingual message understanding and writes the two-sentence invite in the group's dominant language. It runs locally, and the repo benchmarks it at two sizes (gemma3:1b and gemma3:4b) on the same 40 fixtures. The results are in the eval section above, including the parts that don't flatter it.

The bot's best feature is that it knows when to stop talking. This post is trying to learn from it.

CustomsBuddy: Your customs broker for international parcels

πn — Wed, 04 Mar 2026 20:06:54 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

Sending international packages is a pain. Especially when it comes to filling out customs declarations (CN22/CN23).

The average user doesn't know what "HS Codes" are, doesn't know how to correctly translate the names of specific items into English customs language, and often doesn't even realize that their favorite homemade cookies or cold pills are prohibited from being imported into the destination country.

To solve this problem, I created CustomsBuddy — a React application that converts a user's chaotic text description of a package into a rigorous, validated array of data.

In this article, I'll show how we abandoned unreliable text parsing and used Structured Output (JSON Schema) and dynamic System Instructions in the Gemini API.

Demo:

🛑 Why don't regular prompts work for UI?

Let's imagine a typical input: "I'm sending two used t-shirts, a new book, homemade cookies, and 50 bucks worth of medicine to Canada."

If you ask a regular LLM to "make a table out of this," it will return Markdown. Markdown looks great in chat, but as a developer, I need to draw React components: green checkmarks for allowed items, red warnings for prohibited items, and calculate the total.

I need predictable JSON.

🛠 Solution: Gemini Structured Output

Instead of begging the model to "please return only JSON," we use the responseSchema parameter in the Gemini API. This forces the model to strictly follow the structure we specify.

Step 1: Define the Ideal Structure (The Schema)

Here is the configuration object that we will pass to the API:

const responseSchema = {
  type: "OBJECT",
  properties: {
    items: {
      type: "ARRAY",
      items: {
        type: "OBJECT",
        properties: {
          original_description: { type: "STRING" },
          customs_description_en: { type: "STRING" },
          hs_code: { type: "STRING" }, // International customs code
          quantity: { type: "INTEGER" },
          weight_kg: { type: "NUMBER" },
          value_usd: { type: "NUMBER" },
          is_allowed: { type: "BOOLEAN" }, // The main trigger for UI!
          warning_reason: { type: "STRING" } // Explanation if prohibited
        },
        required: ["original_description", "customs_description_en", "hs_code", "quantity", "weight_kg", "value_usd", "is_allowed", "warning_reason"]
      }
    },
    general_warnings: {
      type: "ARRAY",
      items: { type: "STRING" }
    }
  },
  required: ["items", "general_warnings"]
};

Step 2: Dynamic System Instructions

Our app supports different destination countries (USA, Canada, Germany, etc.) and different interface languages. The US customs rules are different from Germany. That's why we make the systemInstruction dynamic!

In the React component, before calling the API, we form the instruction:

// Get the country name in English and the language for the explanation
const destCountryEn = countries.find(c => c.code === destination).name.en;
const explanationLang = lang === 'uk' ? 'українською мовою' : 'in English';

const systemInstruction = `You are a professional international customs broker.
Your task: to analyze user input to send parcels to the country: ${destCountryEn}.
1. Translate the product descriptions into strict, standardized English.
2. Determine the exact 6-digit HS Code.
3. Logically distribute the cost/weight if only the total is specified.
4. STRONG VALIDATION: Check the customs rules of the country ${destCountryEn}. If the item is prohibited (e.g., homemade food, certain medications), set is_allowed: false and explain why, ${explanationLang} is mandatory. Respond strictly in JSON format.`;

Step 3: Calling the Gemini API

Now we send all this to gemini-2.5-flash:

const response = await fetch(`https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash-preview-09-2025:generateContent?key=${apiKey}`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
  contents: [{ parts: [{ text: inputText }] }],
  systemInstruction: { parts: [{ text: systemInstruction }] },
  generationConfig: {
    responseMimeType: "application/json",
    responseSchema: responseSchema // Inserting our schema!
  }
 })
});

const data = await response.json();
const jsonText = data.candidates[0].content.parts[0].text;
const parsedDeclaration = JSON.parse(jsonText);
// That's it! No regular expressions or text truncation!

🎯 How does this look in practice?

When a user types: "I'm sending two T-shirts, a book, homemade cookies, and $50 worth of cold medicine to Canada"...

Gemini returns a perfect JSON where for the book and T-shirts is_allowed: true (and the model itself found the HS codes 4901.99 and 6309.00 for them). But for the cookies and medicine, the model returns is_allowed: false and adds an explanation that Canadian customs blocks homemade food without factory labeling and over-the-counter medicines.

In React, we simply map this array:

{results.items.map((item, idx) => ( 
 <div key={idx} className={item.is_allowed ? 'bg-slate-50' : 'bg-red-50'}> 
  {item.is_allowed ? <CheckCircle2 className="text-emerald-500" /> : <AlertOctagon className="text-red-500" />} 

  <h3>{item.customs_description_en}</h3> 
  <span>HS Code: {item.hs_code}</span> 

  {!item.is_allowed && ( 
  <div className="text-red-700"> 
   Failure reason: {item.warning_reason} 
  </div> 
  )} 
 </div>
))}

💡 Conclusion

Structured Output (JSON Schema) completely changes the approach to developing AI applications. We no longer use LLMs simply as "smart interlocutors". We use them as reliable microservices for data analysis, classification and transformation that integrate perfectly into our frontend.

Try adding responseSchema to your next Gemini project - and you will forget about the pain of text parsing forever!

Maplewood Heights (Community Connect)

πn — Mon, 02 Mar 2026 07:55:04 +0000

This is a submission for the DEV Weekend Challenge: Community

Today I’m excited to introduce Maplewood Heights, a warm and inviting hub for our local community!

🏡 It’s a place where neighbors can learn about events, share news, and discover local gems.

☁️ I'd love to hear your thoughts on the design!

The app is already deployed to Google Cloud:: https://community-connect-528833377593.us-central1.run.app

🛠️ Functionality of the first version already has a lot of useful features:
📅 View upcoming events
💬 Live feed of community updates
☕ Favorite local places
🤝 Neighbor profiles and statistics

Updates feed: Multi-level comment threads, quick reactions, and emojis.
Community: Get to know your neighbors and quickly message them.
Events: A board of upcoming activities (from farmers' markets to volunteering).
Local "gems": Recommendations for the best bakeries, parks, or coffee shops in the area.

My main goal was to combine the speed of modern frontend technologies with a stylish, warm UI.

Stack & Architecture:
⚡ React 18 + Vite (quick build via SWC)
🎨 Tailwind CSS v3 + CSS-variables (fully custom light/dark theme in honey/sage green tones)
🧱 shadcn/ui (integrated ~50 Radix UI components)
✨ Framer Motion (controls orchestrating animations when scrolling and microinteractions)
🚢 CI/CD: Multi-stage Docker build on top of Nginx -> deployment to Google Cloud Run.

What's inside?

Watercolor hero block.
Update feed with support for recursive N-level comments and reactions.
Neighborhood mutual aid module.
Own context-messaging right in the browser.
When design (DM Serif Display + warm tones) works in synergy with cool UX, users really want to come back.

Happy to connect people through technology. ✨

My Portfolio Has a Split Personality: GUI vs Terminal

πn — Mon, 02 Feb 2026 07:58:24 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

Hello, network! 👋

For the "New Year, New You" challenge, I didn't want to just update my CSS. I wanted to build something that represents the duality of a Full Stack Developer:

The Professional: Clean, modern UI using the trendy Bento Grid layout.

The Geek: A hacker-style Terminal for those who prefer CLI over GUI.

Try it out!
Check out the live demo and let me know: are you team #GUI or team #Terminal? 👇

Available at: https://devportfolio-528833377593.us-central1.run.app/ 🚀

The Concept

Usually, portfolios are static. You read, you scroll, you leave. I wanted interaction.

GUI Mode: Visualizes my projects and skills.
Terminal Mode: Lets you type commands like help, skills, or even ask to talk to AI.

The AI Magic ✨

Instead of searching for my experience in a long text, recruiters can now ask:

"Tell me about your skills?"

The AI analyzes my JSON data and generates a professional answer instantly. It lives both in a chat modal (GUI) and as a command (Terminal).

Tech Stack

Framework: React + Vite
Styling: Tailwind CSS
AI: Google Gemini API
Icons: Lucide React

The most time was spent not on the code, but on making the site feel "like me": a little mysterious, a little playful, but at the same time very professional.

This is not just a portfolio. This is my manifesto for 2026: code with passion, use the best tools (thanks Google AI) and don't be afraid to be yourself.

Thanks for stopping by.

Write in the comments what you liked/what you would change - I'd be happy to hear your feedback.
And if you also participated - drop a link, I'll take a look and like 🚀