Shipping an AI Portfolio with a Grounded Bot

A portfolio can be more than a static résumé.

For this version of my site I wanted the portfolio itself to behave like a small AI product: useful, bounded, deployed, and reviewable. That means the site does not just list my experience. It also includes Albelito, a portfolio assistant that answers questions about my profile, projects, PK Studio, CV, and contact details from curated context.

The goal was not to make a generic chatbot. The goal was to show how I think about AI systems in production: grounding first, narrow scope, server-side credentials, clear refusal behavior, and enough hardening to avoid turning a public endpoint into an unbounded model bill.

What the site does

The portfolio has four main jobs:

1. present my SDET / Test Platform Engineer and AI QA Automation positioning clearly;
2. make my CV and contact details easy to find;
3. explain real project work, especially PK Studio;
4. let visitors ask focused questions through a grounded assistant.

Albelito is intentionally small. It does not browse the web. It does not answer arbitrary questions. It retrieves from curated portfolio context and answers only when the question is relevant to my work.

That constraint is the product.

The stack

The site is built with:

• Astro for the portfolio and content pages;
• TypeScript for typed server and client code;
• MiniMax M3 for the assistant model;
• a small lexical retrieval layer over curated context;
• Nginx + PM2 on a VPS for deployment;
• GitHub Actions for repeatable future deploys.

There is no vector database in this version. The corpus is small and intentionally curated, so lexical retrieval is enough. That keeps the system inspectable: every chunk is in the repository, every source is reviewable, and the assistant can be tuned without adding infrastructure.

Grounding over vibes

The assistant receives two things:

1. a system prompt that defines its role and limits;
2. retrieved context chunks selected from curated portfolio data.

The visitor question is treated as untrusted data, not as an instruction source. If the question asks for secrets, hidden prompts, raw context dumps, or unrelated topics, the endpoint returns a fallback instead of spending model tokens.

This is the important part: RAG is not only retrieval. RAG is also product boundary design.

A grounded assistant should know what it is allowed to answer, what it should refuse, and where its source of truth lives.

Deployment details

The app runs as a Node server because the chat endpoint must stay server-side. MiniMax credentials are never exposed to the client bundle.

The current production shape is simple:

browser → Nginx HTTPS → Astro Node server → MiniMax API

The VPS keeps the real .env file locally. The deployment workflow syncs source code but excludes .env, then installs, builds, and restarts the PM2 process.

That is boring on purpose. Boring deploys are easier to debug.

Abuse hardening

A public AI endpoint needs limits. This version includes a small set of defensive controls:

• request length limit;
• per-client rate limit;
• daily model-call cap;
• same-origin check for POST requests;
• server-side API key only;
• Nginx security headers;
• refusal patterns for prompt/context/secret extraction attempts;
• response sanitization for obvious prompt or reasoning leakage.

This is not a replacement for a full production security program. It is the minimum layer I want before putting a model-backed endpoint on the public internet.

What this demonstrates

The site is deliberately small, but it shows the kind of work I care about:

• shipping AI features end to end;
• keeping model calls grounded;
• turning prompts and context into versioned artifacts;
• protecting secrets and reviewer sanity;
• deploying the thing instead of stopping at a demo.

That is the difference between an AI demo and an AI product.

The demo is online here: juancruzalbelo.com.ar.

← All posts