Forem: Enrique Uribe

AdblockNot - The Adblocker you've never wanted.

Enrique Uribe — Sat, 11 Apr 2026 22:13:14 +0000

This is a submission for the DEV April Fools Challenge

Adblock Not

Have you ever sat there watching a youtube ad and said "dang, I just wish there were more ads?" Welcome to AdblockNot!

What I Built

I built Adblock Not, the ad blocker you've never wanted.

Most ad blockers try to make the web less annoying. Adblock Not takes the opposite approach. It sees your desire for an ad-free experience and responds with the worst possible product decision: before it blocks ads, it makes you watch one.

Not a skippable one, either.

To make this bad idea feel more official, I wrapped the whole thing in a fake early-2000s cable/satellite interface. The overlay looks like a retro TV guide, the ads are presented like channels, and if you do not like the current ad, you can always change the channel to a different ad.

I also wanted it to tap into a very specific kind of commercial nostalgia: the era of weird infomercials, overdramatic voiceovers, late-night paid programming, and commercials you did not exactly love, but somehow still remember forever.

That is the entire value proposition:

it is an ad blocker built on a terrible premise
it treats ad blocking like premium content authorization
it adds friction where absolutely none was needed
it is less a utility and more a hostage negotiation with nostalgic television design

The current lineup includes multiple gloriously inconvenient commercials, including Fushigi, Education Connection, Nike Football, Sears, and Zoobooks.

So yes: I made software whose core feature is disrespecting your time in a more organized and stylish way.

Demo

Code

UribeJr / adblocknot

Adblock Not

Adblock Not is the ad blocker you've never wanted.

It is a joke Chrome MV3 extension built around a deliberately terrible idea: before it blocks ads, it makes you watch an ad. To make the experience feel more official, the whole gate is wrapped in a retro early-2000s TV interface with channel switching, a fake guide, and a lineup of bundled commercials.

This is not a serious ad blocker. It is an anti-product with excellent commitment to the bit.

What It Does

Detects when a page should show the Adblock Not gate.
Opens a fullscreen retro TV-style overlay before ad blocking is allowed.
Makes you watch one of several bundled ad videos to completion, or wait through a fallback timer if playback fails.
Lets you "change the channel" to a different ad, which is obviously not real relief.
Includes a retro guide UI so you can manually pick…

View on GitHub

How I Built It

Adblock Not is a Chrome Manifest V3 extension built with plain JavaScript, HTML, and CSS.

The basic idea was simple: if an ad blocker is supposed to remove interruptions, I wanted to build one that introduces a brand new interruption first.

The extension injects a fullscreen content-script overlay onto pages, then uses a background service worker to track whether the user has satisfied the completely unnecessary ad-watching requirement.

Main pieces:

manifest.json wires up the MV3 extension, content script, service worker, and bundled media assets.
src/content/gate-overlay.js renders the fake TV UI, loads the bundled ad videos, handles channel switching, opens the guide, and controls the unlock flow.
src/content/gate-overlay.css gives the whole experience the retro cable-box look.
src/background/service-worker.js stores unlock state and decides whether the gate should appear.

Some of my favorite details:

The entire joke works because the product logic is coherent. Every part of it is committed to making ad blocking slightly more annoying.
The guide UI is based on old cable/satellite channel guides because that era already felt one tiny step away from self-parody.
The bundled ads are part of the joke, but they are also part of the nostalgia. They come from that very specific "how is this on television again?" era of commercials that burned themselves into your brain.
The video player uses custom controls to keep the fake-TV vibe intact.
"Change the channel" is my favorite feature because it sounds like a mercy feature, but it is actually just a different route to the same suffering.

Technically, it was also a fun constraint: make something that is dumb on purpose, but polished enough that the joke lands immediately.

Prize Category

Primary category:

Community Favorite

Why:

I built this as a pure anti-product. The concept is immediate, the joke is obvious, and the whole thing is committed to the bit: an ad blocker that forces you to watch ads before it helps you avoid ads.

Alternate category I could also argue for:

Best Ode to Larry Masinter

Why:

The project is built in the spirit of lovingly useless internet/software humor. It is not practical, it is not responsible, and it is absolutely committed to the bit.

Good luck to all the winners! This was fun to dive into as a pretty 'basic' notion user. MCP really helped learn the ins and outs of what notion can provide.

Enrique Uribe — Wed, 01 Apr 2026 18:24:29 +0000

Notion MCP Challenge Submission 🧠

Enrique Uribe

Mar 27

I built an AI behavioral Brain with Notion MCP

#devchallenge #notionchallenge #mcp #ai

Comments

5 min read

[Boost]

Enrique Uribe — Mon, 30 Mar 2026 15:20:22 +0000

Notion MCP Challenge Submission 🧠

Enrique Uribe

Mar 27

I built an AI behavioral Brain with Notion MCP

#devchallenge #notionchallenge #mcp #ai

Comments

5 min read

[Boost]

Enrique Uribe — Sat, 28 Mar 2026 14:01:25 +0000

Notion MCP Challenge Submission 🧠

Enrique Uribe

Mar 27

I built an AI E-Commerce Brain with Notion MCP

#devchallenge #notionchallenge #mcp #ai

Comments

5 min read

I built an AI behavioral Brain with Notion MCP

Enrique Uribe — Fri, 27 Mar 2026 20:30:12 +0000

This is a submission for the Notion MCP Challenge

What I Built

I built an AI e-commerce brain for a Shopify storefront using Notion MCP as the behavior control layer.

On the surface, it looks like one shopping assistant. Under the hood, it behaves more like a network of specialists:

a training bag specialist
a gloves and wraps specialist
a cart review specialist
an order history specialist
an add-to-cart specialist

The architecture is split intentionally.

The app keeps ownership of:

intent classification and routing
Shopify integration
ranking and filtering
session and conversation state
validation and fallback logic
performance and caching

Notion owns the behavior layer for each intent:

tone and voice
intent instructions
recommendation strategy
questions to ask
do / do not rules
example responses
behavior notes
synced intent synonyms

That means I can change how the AI behaves per scenario without rewriting prompts throughout the codebase.

Instead of one generic chatbot, I now have a commerce system made up of specialist branches like:

search_training_bags
search_gloves_wraps
cart_review
orders_selection
order_detail

This makes the behavior visible, editable, and operational.

I also built a publish model so Notion is safe to use in production:

Edit behavior in Notion
Click Sync from Notion
Publish the behavior into the app
Run the storefront from the published config locally for fast runtime performance

I also built the reverse flow:

Sync to Notion

So the app can push its current behavior definitions back into the Notion database.

This turned Notion from a documentation layer into a real control plane for the AI.

Video Demo

In the demo, I walk through:

the Notion behavior control panel
the specialist intent rows
the sync workflow
changing behavior in Notion and seeing the storefront assistant respond differently
category-specific shopping flows like training bags and gloves/wraps

Show us the code

Parse Notion rows into behavior config

This is the layer that turns a Notion database row into a specialist behavior object the app can use at runtime.

function parseNotionBehaviorRow(page) {
  const properties = page?.properties || {};
  const intent = pickProperty(properties, ['intent', 'name', 'title']);
  const key = normalizeIntentKey(intent);
  if (!key) return null;

  const enabledRaw = pickProperty(properties, ['enabled', 'active']);
  const enabled = enabledRaw ? enabledRaw === 'true' : true;

  return {
    key,
    enabled,
    intentSynonyms: pickProperty(properties, ['intent_synonyms', 'synonyms', 'trigger_phrases']),
    toneVoice: pickProperty(properties, ['tone_voice', 'tone', 'voice']),
    intentInstructions: pickProperty(properties, ['intent_instructions', 'instructions']),
    questionsToAsk: pickProperty(properties, ['questions_to_ask', 'questions']),
    recommendationStrategy: pickProperty(properties, ['product_recommendation_strategy', 'recommendation_strategy']),
    doRules: pickProperty(properties, ['do', 'do_rules']),
    doNotRules: pickProperty(properties, ['do_not', 'do_not_rules']),
    upsellCrossSellStrategy: pickProperty(properties, ['upsell_cross_sell_strategy', 'upsell_strategy', 'cross_sell_strategy']),
    exampleResponses: pickProperty(properties, ['example_responses', 'examples']),
    behaviorNotes: pickProperty(properties, ['behavior_notes', 'notes']),
  };
}

Sync behavior from Notion into the app

This is the publish step. It pulls the latest behavior definitions from Notion and stores a published config in the app for fast local runtime use.

export async function syncChatBehaviorFromNotion(shop) {
  const config = await fetchNotionBehaviorDatabase();
  const publishedConfig = normalizePublishedBehaviorConfig({
    ...config,
    source: 'published_notion',
    publishedAt: new Date().toISOString(),
  });

  await updateSettings(shop, {
    behaviorConfigJson: JSON.stringify(publishedConfig),
    behaviorConfigSource: publishedConfig.source,
    behaviorSyncedAt: new Date(),
  });

  behaviorCache = {
    shop,
    config: publishedConfig,
    expiresAt: Date.now() + (Number(process.env.NOTION_BEHAVIOR_CACHE_MS || DEFAULT_CACHE_MS) || DEFAULT_CACHE_MS),
  };

  return publishedConfig;
}

Sync behavior back to Notion

This is the reverse direction. It pushes app-side behavior definitions back into the Notion control panel so the system stays visible and editable.

export async function syncChatBehaviorToNotion(shop) {
  const token = sanitizeText(process.env.NOTION_API_TOKEN);
  const databaseId = sanitizeText(process.env.NOTION_BEHAVIOR_DATABASE_ID);
  if (!token || !databaseId) {
    throw new Error('Missing NOTION_API_TOKEN or NOTION_BEHAVIOR_DATABASE_ID.');
  }

  const settings = shop ? await getSettings(shop) : null;
  const publishedConfig = parseBehaviorConfigJson(settings?.behaviorConfigJson) || cloneDefaultConfig();
  const effectiveConfig = normalizePublishedBehaviorConfig({
    ...publishedConfig,
    source: publishedConfig?.source || 'published',
  });

  const existingRows = await queryNotionBehaviorRows(token, databaseId);
  const rowMap = new Map();

  for (const row of existingRows) {
    const parsed = parseNotionBehaviorRow(row);
    if (!parsed?.key) continue;
    rowMap.set(parsed.key, row.id);
  }

  const intents = Object.entries(effectiveConfig.intents || {});
  for (const [intentKey, behavior] of intents) {
    const mergedBehavior = {
      ...(effectiveConfig.global || {}),
      ...(behavior || {}),
    };

    const properties = buildNotionBehaviorProperties(intentKey, mergedBehavior);
    const existingPageId = rowMap.get(intentKey);

    if (existingPageId) {
      await updateNotionBehaviorPage(token, existingPageId, properties);
    } else {
      await createNotionBehaviorPage(token, databaseId, properties);
    }
  }

  return {
    pushedAt: new Date().toISOString(),
    intentCount: intents.length,
  };
}

Runtime behavior loading in storefront chat

This is where the storefront chat loads the published behavior config for the active shop before generating a response.

const behaviorConfig = await getChatBehaviorConfig(shopDomain || session?.shop || '');

Then later, the response generator uses the active specialist behavior:

async function generateAssistantCopy({
  query,
  items,
  allowFollowups,
  policyAnswer,
  apiKey,
  chatHistory = [],
  behaviorConfig,
  behaviorIntent = 'search'
}) {
  // ... build shortlist and conversation context ...

  const recommendationInstruction =
    behaviorIntent === 'search_training_bags'
      ? trainingBagFollowupInstruction
      : standardFollowupInstruction;

  // behaviorConfig + behaviorIntent shape the final response
}

Admin actions for the two sync buttons

This is the UI-facing action layer that powers Sync From Notion and Sync To Notion.

export const action = async ({ request }) => {
  const { session } = await authenticate.admin(request);
  const formData = await request.formData();
  const actionType = formData.get("action");

  if (actionType === "sync_behavior_to_notion") {
    const result = await syncChatBehaviorToNotion(session.shop);
    return json({
      ok: true,
      behaviorPush: true,
      pushedAt: result?.pushedAt || new Date().toISOString(),
      message: `Behavior pushed to Notion for ${result?.intentCount || 0} intents.`,
    });
  }

  if (actionType === "sync_behavior_from_notion") {
    const config = await syncChatBehaviorFromNotion(session.shop);
    return json({
      ok: true,
      behaviorSync: true,
      source: config?.source || "published_notion",
      syncedAt: config?.publishedAt || config?.fetchedAt || new Date().toISOString(),
      message: "Behavior synced from Notion.",
    });
  }
};

How I Used Notion MCP

Notion MCP is what made this system possible in a meaningful way.

I used Notion MCP to create and operate a behavior database that acts like a control room for the storefront AI.

Each row in Notion represents an intent or a specialized branch, for example:

search
search_training_bags
search_gloves_wraps
cart_review
orders_selection
order_detail

Each row contains structured behavior fields like:

Tone Voice
Intent Synonyms
Intent Instructions
Questions To Ask
Product Recommendation Strategy
Do
Do Not
Example Responses
Behavior Notes

This let me turn Notion into an operator-facing behavior system instead of just a place to store notes.

For example:

the training bag specialist can focus on freestanding vs hanging bag decisions
the gloves and wraps specialist can focus on MMA gloves, boxing gloves, bag gloves, wraps, padding, and protection
the cart review specialist can behave more like a checkout assistant
the order specialists can stay concise and service-oriented

The important part is that Notion MCP did not just help me document the system. It helped me build the system that controls the AI behavior.

That unlocked a much stronger workflow:

identify a weak response
update the specialist behavior in Notion
sync it into the app
test it live in the storefront

That is why I think this is a strong Notion MCP use case.

I did not just connect Notion to an agent.
I used Notion MCP to build the behavior control plane for an AI commerce brain.

Cart Review Behavior:

Sale Search Behavior

The part I like most is that behavior is no longer buried in prompts or scattered across code. Notion became a real operating surface for the AI, and that made the storefront feel less like a chatbot and more like a system of specialists that can actually be tuned, tested, and improved over time.

🧠 My 2026 Shopify Stack — I Don’t Build Apps, I Build Business Solutions

Enrique Uribe — Tue, 24 Feb 2026 20:47:03 +0000

I don’t build Shopify apps for fun.

I build systems that:

Automate operations
Reduce manual work
Protect revenue
Increase AOV
Clean up messy workflows

Shopify is just the platform.

The real goal is solving business problems.

This is the stack I use every day to do that.

1️⃣ Shopify CLI — The Operational Backbone

Every solution starts here.

shopify app init
shopify app dev

That one workflow covers the things that usually break first:

OAuth
Local development
Environment wiring
Fast iteration loops

When you’re shipping revenue-impacting logic, fragile setup is a liability.

CLI keeps the foundation predictable.

2️⃣ Shopify MCP — Build Against Reality, Not Assumptions

Most bugs happen because developers assume store structure.

I don’t assume. I inspect.

Before building logic around products or metafields, I look at what actually exists:

query {
  products(first: 3) {
    edges {
      node {
        id
        title
        metafields(first: 10) {
          edges {
            node {
              namespace
              key
              type
            }
          }
        }
      }
    }
  }
}

Now I’m working with:

Real namespaces
Real types
Real data patterns

When business logic depends on structure, guessing gets expensive.

3️⃣ Admin GraphQL API — Precision Over Noise

Business solutions need precision.

Example: auto-tag high-value orders so the ops team can prioritize them.

const mutation = `
mutation AddOrderTag($id: ID!, $tags: [String!]!) {
  tagsAdd(id: $id, tags: $tags) {
    node { id }
    userErrors { field message }
  }
}
`;

const response = await admin.graphql(mutation, {
  variables: {
    id: orderId,
    tags: ["Priority"]
  }
});

const data = await response.json();

if (data.data.tagsAdd.userErrors.length > 0) {
  console.error(data.data.tagsAdd.userErrors);
}

Small example. Real impact.

GraphQL lets me:

Scope tightly
Avoid overfetching
Control exactly what the system does

When thousands of events are flowing through your app, precision matters.

4️⃣ Webhooks — Event-Driven Automation

I don’t poll.

I react.

Most business automation is event-based:

Orders
Product updates
Customer creation
App uninstall events

Minimal webhook skeleton:

import { authenticate } from "../shopify.server";

export const action = async ({ request }) => {
  const { topic, payload, shop } = await authenticate.webhook(request);

  if (topic === "ORDERS_CREATE") {
    console.log(`New order from ${shop}`);

    // Example: run automation logic here
    // await handleOrderAutomation(payload);
  }

  return new Response(null, { status: 200 });
};

This is where Shopify turns into a business operating system.

The store moves.

Your system responds.

5️⃣ Tunneling — Clean Install & Testing Cycles

Business solutions often depend on:

OAuth behaving correctly
Webhooks firing reliably
Installation flow being clean

shopify app dev handles tunneling seamlessly.

That means I can:

Reinstall repeatedly
Test webhook flows safely
Simulate real store conditions

Stability during development prevents chaos in production.

6️⃣ DevTools — Because Business Owners Notice Speed

If your embedded app slows down the Shopify admin, it won’t survive.

I constantly inspect:

Bundle size
Network waterfalls
Blocking scripts
Unnecessary re-renders

Merchants don’t care how elegant your architecture is.

They care if it feels fast.

Business impact > technical elegance.

The Real Difference

Anyone can build features.

Not everyone builds solutions.

The difference is:

Thinking in workflows, not endpoints
Designing event-driven systems
Validating store structure before writing logic
Treating revenue-impacting code with discipline
Building for scale from day one

Shopify is just the canvas.

The real work is understanding the business behind it.

Closing Thought

In 2026, Shopify development isn’t about who writes the cleanest code.

It’s about who designs systems that:

Survive scale
Protect revenue
Reduce operational friction
Make merchants’ lives easier

That’s the stack I build with.

If you’re building on Shopify — are you building features, or building systems?

Using banner bear’s AI image creation to automate designer workflows. Check it out!

Enrique Uribe — Sun, 15 Feb 2026 00:33:53 +0000

🚀 Automating Email Image Requests with Asana + Zapier + BannerBear

Enrique Uribe ・ Feb 12

#automation #nocode #api #productivity

🚀 Automating Email Image Requests with Asana + Zapier + BannerBear

Enrique Uribe — Thu, 12 Feb 2026 17:37:31 +0000

Some companies operate multiple sub-brands under one marketing department.

Each brand has:

Its own identity
Its own templates
Its own dedicated graphic designers

But most email campaigns follow repeatable patterns — flash sales, limited-time offers, announcements.

Instead of having designers rebuild the same promo layouts every time, this system automates the repetitive production work while preserving brand control.

Built with:

Asana → request form intake
Zapier → routing + logic
BannerBear → image rendering

🧠 The Goal

This wasn’t about replacing designers.

It was about removing repetitive promo production so designers can focus on:

Campaign concepts
Brand evolution
High-impact creative
Strategic visual storytelling

Designers build the master templates once.

Automation handles recurring production.

That shift alone makes a huge difference.

🏗 How It Works

Here’s the full workflow from request to finished asset:

1️⃣ Marketing Submits a Form

The marketing team fills out a structured form inside Asana.

That form automatically creates a task in the Email Image Requests project with:

Division
Template type
Promo details
Copy
Any needed assets

Everything starts from one intake system.

2️⃣ Designer Reviews the Request

Each brand has a dedicated designer.

The assigned designer reviews the task and ensures:

Copy is correct
Template selection makes sense
Assets are attached
Everything is ready

When it’s approved, the designer moves the task to:

“Ready to Render”

3️⃣ Moving to “Ready to Render” Triggers the Zap

That section change triggers the automation.

Zapier then:

Pulls all task data
Checks the Division
Checks the Template type
Maps the task data to the correct BannerBear template

4️⃣ BannerBear Generates the Image

Zapier sends the mapped data to BannerBear.

BannerBear renders the image based on the correct brand template.

No manual design work required.

{
  "template": "V32jY9bBM6l0DBGWrl",
  "modifications": [
    {
      "name": "BG_COLOR",
      "color": null
    },
    {
      "name": "TXT_HEADLINE",
      "text": "You can change this text",
      "color": null,
      "background": null
    },
    {
      "name": "CTA_COLOR",
      "color": null
    },
    {
      "name": "TXT_CTA",
      "text": "You can change this text",
      "color": null,
      "background": null
    },
    {
      "name": "TXT_BODY",
      "text": "You can change this text",
      "color": null,
      "background": null
    },
    {
      "name": "IMG_FEATURED",
      "image_url": "https://cdn.bannerbear.com/sample_images/welcome_bear_photo.jpg"
    },
    {
      "name": "TXT_SUBHEAD",
      "text": "You can change this text",
      "color": null,
      "background": null
    },
    {
      "name": "TXT_LEGAL",
      "text": "You can change this text",
      "color": null,
      "background": null
    }
  ],
  "webhook_url": null,
  "transparent": false,
  "metadata": null
}

5️⃣ Zapier Updates the Task

Once the image is created:

Zapier grabs the generated asset URL
Updates a custom field called “Created Asset”
The image is ready to download directly from the task

One intake system.

Multiple brand outputs.

Fully automated.

Create your own avatar! 👾 I just added a Pixel Avatar Maker to this Windows 98–style portfolio — feel free to share yours in the comments.

Enrique Uribe — Sun, 25 Jan 2026 01:28:24 +0000

New Year, New You Portfolio Challenge Submission

Enrique Uribe

Jan 19

I Built a Windows 98–Style Desktop Portfolio with AI 💾

#devchallenge #googleaichallenge #portfolio #gemini

Comments 6

4 min read

What was your first operating system?

Enrique Uribe — Tue, 20 Jan 2026 17:56:28 +0000

I Built a Windows 98–Style Desktop Portfolio with AI 💾

Enrique Uribe ・ Jan 19

#devchallenge #googleaichallenge #portfolio #gemini

What was your first operating system?

Enrique Uribe — Tue, 20 Jan 2026 17:55:03 +0000

New Year, New You Portfolio Challenge Submission

Enrique Uribe

Jan 19

I Built a Windows 98–Style Desktop Portfolio with AI 💾

#devchallenge #googleaichallenge #portfolio #gemini

Comments 6

4 min read

I Built a Windows 98–Style Desktop Portfolio with AI 💾

Enrique Uribe — Mon, 19 Jan 2026 23:30:45 +0000

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

About Me

I’m a full-stack developer and digital designer with over a decade of experience building robust, scalable solutions that solve real-world problems. I thrive on both thoughtful architecture and polished design — from concept through deployment — and I’m passionate about creating work that is both technically sound and visually engaging.

For this challenge, I took a personal and creative direction with my portfolio: a Windows 98-style experience with a MySpace-inspired profile. This project isn’t just a collection of links — it’s a window into who I am as a developer and a creator.

Growing up in the 90s, Windows 98 was my first computer and one of my earliest influences in computing. The look, sound, and playfulness of those early graphical interfaces sparked my curiosity about how software can be expressive and fun. Likewise, MySpace was the first social platform where I crafted my digital identity, experimented with layout and style, and shared music and stories that mattered to me as a teenager.

That nostalgia fuels this portfolio: blending retro aesthetics with modern cloud-native tech. I built and deployed this project to Google Cloud Run, leveraging scalable infrastructure and embedding the live site directly in my submission.

This portfolio reflects my technical skills, creative thinking, and willingness to break conventions — using nostalgia not as a gimmick, but as a thoughtful design lens. I hope it shows not only where I’ve been, but also where I’m going as a developer.

Portfolio

Take me for a spin!
View UribeJr98

The deployment is hosted on Google Cloud Run and features a custom dev-tutorial label per the submission guidelines.

🔄 Update: Pixel Avatar Maker (New Desktop App)

After publishing this portfolio, I added a new interactive desktop app: a Pixel Avatar Maker.

Inspired by late-90s and early-2000s pixel art and avatar creators, this app lets you customize a retro pixel character — tweak colors, styles, and details — and export your avatar as a PNG, all within the Windows 98–style OS.

It’s designed to be lightweight, playful, and instantly understandable. No setup, no rules — just open it, create something, and take it with you. In the spirit of the era, it’s less about perfection and more about expression.

If you make one, feel free to share your avatar in the comments — I’d love to see what people come up with.

(Examples generated using the Pixel Avatar Maker below 👇)

How I Built It

This portfolio was built as a fully interactive, OS-style web application, inspired by Windows 98 and early MySpace layouts, but implemented with modern frontend architecture and cloud-native deployment.

The app is structured around a centralized window manager that controls open state, focus, minimization, and z-index — allowing draggable, overlapping windows similar to a real desktop environment. Each “application” (About Me, Media Player, Projects, Notepad Messenger, Pong, Explorer) is implemented as a self-contained React component, keeping the system modular and extensible.

The frontend is built with React and Vite for fast development and optimized builds. I used 98.css as a stylistic base and layered custom CSS for responsive behavior, window chrome, and interaction polish. Project case studies open in a dedicated viewer that supports structured data and GitHub-style Markdown rendering, making content easy to maintain while staying on-theme.

For interactivity, I integrated:

A SoundCloud-powered media player
A Pong mini-game
A persistent Notepad Messenger
Desktop icons and a taskbar that mirror classic OS behavior

In production, the app is served by a lightweight Node.js + Express server, which handles SPA routing and static assets. The project is deployed to Google Cloud Run, demonstrating a modern, scalable deployment model with minimal operational overhead and a live, embeddable URL for the DEV submission.

The goal was to combine nostalgic design with modern engineering, showing that expressive interfaces and production-ready architecture can coexist.

What I'm Most Proud Of

I’m proud of who I am and where I come from.

This portfolio acts as a time capsule of my life, capturing the technology, music, and digital spaces that shaped my earliest experiences with computers. Windows 98 was my first operating system, and MySpace was the first place I learned how to express myself online. Those moments sparked my curiosity and influenced how I approach design and interaction today.

What makes this project meaningful to me is how it connects past and present. I took those formative experiences and rebuilt them using modern tools, thoughtful architecture, and cloud deployment — turning nostalgia into something functional and forward-looking.

This portfolio isn’t just a collection of projects. It’s a reflection of my journey, preserving where I started while showing who I’ve become as a developer.