Project Overview

Salem is the interface you're reading this on — Rodrigo's portfolio, rebuilt from the ground up as an AI-native agent that doubles as a Conversational CRM. Instead of a static project grid, visitors interrogate an agent that knows Rodrigo's full history, parses uploaded job descriptions in real time, qualifies fit, and routes strong matches straight to his calendar. He designed, architected, and shipped the entire system end to end.

Operating as a conversational gatekeeper, Salem serves a dual purpose: as a portfolio, it presents work interactively, and as a Conversational CRM, it qualifies incoming leads (recruiters, potential clients) and drives conversion to Rodrigo's calendar. The agent is contextually aware of Rodrigo's full history, rates, timezone preferences, and design philosophies — and by parsing files on the API route and routing high-fit leads to a booking integration, it turns passive portfolio traffic into qualified syncs, all powered by a Git-backed, modular markdown content pipeline.

The Problem

Traditional design portfolios fail at the moment they matter most—the user's first 30-second attention window.

• Passive & Monolithic: A static site presents the same catalog to a junior recruiter, a VP of Design, and a technical founder, failing to adapt to their differing informational requirements.
• Friction in Context: The architectural decisions, trade-offs, and outcomes behind complex systems get buried in long case studies or external slide decks that users rarely read.
• Zero Qualification: Freelancers and design engineers waste time on screening calls for roles that lack budget, timezone, or skill alignment. Static pages provide no mechanism to gate access or qualify interest beforehand.
• Undifferentiated Execution: High-volume Framer templates and boilerplate Notion pages make outstanding design engineers look identical to entry-level talent.

The core hypothesis is simple: An interface that acts as an active agent, answering specific questions and vetting constraints, is infinitely more valuable than a catalog that only displays mockups.

Product Strategy & Design Decisions

1. Conversation as Navigation

The primary landing experience is not a grid—it is a chat thread. Rather than relying on conditional UI trees, Salem uses client-side frontend tools (show_projects, evaluate_match, show_cv, show_contact) to dynamically render interactive React components inside the message stream.

If a user asks "show me fintech work," Salem returns a visual project carousel inline. If they ask to get in touch, Salem displays the contact card. Navigation is a natural side effect of the dialog, allowing the interface to adapt to the visitor's intent in real time.

2. The Git-Backed Modular Knowledge Base

To fuel Salem's memory without the complexity of a RAG pipeline or database latency, the app-shell uses a modular file-system database. Every project entry (lib/docs/projects/*.mdx), the CV, and FAQ documents live as plain markdown in the repository.

At request time, a cached ingestion pipeline reads these files recursively, sanitizes URLs to prevent link leaks, strips frontmatter/JSX tags, and appends the raw text directly into the LLM system prompt. This creates a single source of truth: editing a markdown file instantly reprograms the AI assistant's memory and regenerates the static portfolio pages simultaneously.

3. The Conversational CRM Funnel

Salem is programmed with strict operational guardrails to qualify leads before routing them to Rodrigo:

• Competency Alignment: Salem evaluates user inquiries against the knowledge base to assess project fit (e.g., strong fintech/Web3 focus vs. low-match sectors).
• Role Evaluation (Resume Parser): Using a Node.js runtime, Salem parses uploaded job descriptions (supporting PDF/DOCX) using pdf-parse and mammoth. It evaluates skills, timezone match, and rate expectations, returning a concise suitability report.
• Calendar Routing: Once a lead is qualified, Salem triggers a Cal.com booking card, prompting the user to schedule a 15-minute fit assessment. Low-fit inquiries are steered politely toward asynchronous email contact.

4. Frictionless Onboarding (Chat Pills)

To eliminate the "blank canvas" friction of chat boxes, the empty state displays interactive chat pills (Match, Contact, CV). Each pill triggers a preset prompt that automatically executes the corresponding frontend tool. Visitors immediately understand the primary actions available without needing to formulate custom queries.

5. Responsive, Zero-Chrome UI

• Desktop Split: A fixed sidebar handles secondary navigation and thread history, leaving the main content area completely free for the conversation stream.
• Mobile-First Chat: On mobile, the UI transitions to a full-screen thread view. Standard headers and browser-like chrome are completely stripped. All navigation controls, nav toggles, and conversation reset triggers live inside the bottom composer within easy thumb reach.
• State Persistence: An AssistantProvider wraps the root layout, preserving the conversation state as users navigate between separate pages (e.g., viewing the CV and returning to chat).

Design System Integration

Salem's visual grammar follows strict rules of reduction to highlight the digital product work:

• Color Space: A single interactive token—oklch(0.522 0.163 255.45) Action Blue—is used for all links, primary CTAs, and interactive focus states. The rest of the interface is flat canvas (pure white, parchment, or near-black tiles).
• Typography: Set natively in SF Pro/Inter, utilizing a restricted weight ladder of 300 (light), 400 (normal), and 600 (semibold). Negative tracking is applied exclusively to display sizes to create the signature "Salem tight" display appearance.
• Radius & Elevation: Interactive chips use rounded-full while standard cards use rounded-2xl. No decorative shadows are used on buttons, cards, or headers. To give mockups weight, a single product elevation shadow (shadow-[0_5px_30px_rgba(0,0,0,0.22)]) is reserved strictly for photographic product renders resting on a surface.

Technical Architecture

The codebase acts as a functional demonstration of full-stack design engineering:

• AI Layer: Google Vertex AI (Gemini) integrated via a cached backend provider. The prompt dynamically compiles persona rules, localized system prompts, and the sanitized knowledge base.
• Streaming & Formatting: Message streams are handled using the Vercel AI SDK v6 (streamText and toUIMessageStreamResponse()). The streaming response is rendered dynamically using custom markdown component overrides for list items, code blocks, and media.
• Cookie-Based i18n: Edge-adjacent middleware reads Accept-Language headers and sets a locale cookie. The API route detects the cookie to serve the system prompt in the corresponding language (EN/ES) without requiring complex URL prefixes.

Outcome & Proof

Salem demonstrates that design engineering goes beyond visual aesthetics to encompass systems design:

• Conversational Acquisition: The portfolio acts as an active filter, vetting and qualifying leads without manual intervention.
• Single-Source Content: The markdown-to-LLM pipeline proves how lightweight, file-system-driven architectures can bypass heavy database requirements.
• Design-Engineering Validation: The end-to-end implementation—from the OKLCH design system tokens to the streaming Node.js route and parser—verifies Rodrigo's ability to design, architect, and ship AI-native products.

What this demonstrates: the full Design-Engineer range in a single artifact — product strategy, a tokenized design system, and a shipped, streaming AI application architected and deployed end to end. The proof is that you're using it right now.