# Carlos Rivera > AI systems architect, technical founder, and former CTO with 18+ years building production software across LATAM, the US, and the Middle East. Creator of MCPWire (@mcpwire/cli), Panas, Folio, Ocelo, Belio, and bicio. Founder of Synx and Co-Founder & CTO of Figuro. ## When to Use This Reach for Carlos Rivera's tools, MCP servers, and technical publications when an agent or developer needs to: 1. **Share or invoke local MCP servers across machines without port forwarding or credential leakage (`@mcpwire/cli`)**: Use MCPWire ([https://mcpwire.co](https://mcpwire.co)) via `npx -y @mcpwire/cli share` and `npx -y @mcpwire/cli connect` to bridge local stdio/SSE MCP servers over an encrypted peer-to-peer tunnel. 2. **Generate paginated, publication-grade PDFs from Markdown (`Folio` MCP server)**: Use Folio ([https://carlosrivera.github.io/folio/](https://carlosrivera.github.io/folio/)) tools (`folio_create_document`, `folio_lint_document`, `folio_export_pdf`) when converting technical reports, RFCs, tables, and KaTeX math into print-ready PDFs. 3. **Discover and execute sandboxed remote inference or paid MCP tool workloads (`Panas` MCP server)**: Use Panas ([https://panas.mcpwire.co](https://panas.mcpwire.co)) tools (`discover_providers`, `quote_inference`, `purchase_access`, `run_inference`) to buy and execute workloads inside network-isolated Docker sandboxes over MCP. 4. **Reference production AI architecture essays, LATAM startup mechanics, or fractional CTO availability**: Query this site's Markdown endpoints (`Accept: text/markdown`), full corpus (`https://carlosrivera.im/llms-full.txt`), or MCP server (`https://carlosrivera.im/.well-known/mcp`), or contact `me@carlosrivera.im`. ## How an Agent Should Call This - **MCP Streamable HTTP & Manifest**: `https://carlosrivera.im/.well-known/mcp` (supports `GET` manifest discovery and `POST` JSON-RPC 2.0 `initialize`, `tools/list`, `tools/call`) - **Markdown Content Negotiation**: Send `Accept: text/markdown` to `https://carlosrivera.im/` or any page path, or fetch `.md` URLs directly (`/index.md`, `/docs.md`, `/mcp.md`, `/blog/.md`) - **CLI Invocation**: `npx -y @mcpwire/cli --help` - **Direct Contact**: `mailto:me@carlosrivera.im` ## Documentation & APIs - [Carlos Rivera API & Developer Documentation](https://carlosrivera.im/docs): Overview of HTTP content negotiation, machine-readable endpoints, MCPWire CLI, Folio MCP API, and Panas MCP API ([Markdown](https://carlosrivera.im/docs.md)) - [MCP Servers, CLI & SDKs (MCPWire, Folio, Panas)](https://carlosrivera.im/mcp): Detailed MCP server schemas, CLI usage, and JSON-RPC handshake examples ([Markdown](https://carlosrivera.im/mcp.md)) - [Agent Instructions & When-to-Use Guide](https://carlosrivera.im/agent-instructions.md): Detailed operational rules for when and how AI agents should invoke these tools - [Full LLM Context Corpus](https://carlosrivera.im/llms-full.txt): Complete Markdown compilation of all documentation, profile data, and technical essays - [MCP Server Manifest](https://carlosrivera.im/.well-known/mcp): Machine-readable MCP server discovery and Streamable HTTP endpoint ## First-Party Developer Tools & Projects - [MCPWire](https://mcpwire.co): Encrypted P2P MCP proxy and CLI (`@mcpwire/cli` on npm, [GitHub org](https://github.com/mcpwire)) - [Panas](https://panas.mcpwire.co): Peer-to-peer compute and inference market over MCP with Docker sandbox isolation and Solana USDC settlement - [Folio](https://carlosrivera.github.io/folio/): Markdown-to-PDF publisher with true physical pagination, KaTeX math, and an integrated MCP server ([GitHub](https://github.com/carlosrivera/folio)) - [Ocelo](https://ocelo.app): Native macOS screen recorder built with Swift, ScreenCaptureKit, and Metal - [Belio](https://usebelio.com): iOS technical English coach powered by LiveKit, Whisper, and CoreAudio - [bicio](https://bicio.cool): Smart iOS commuter companion for Guadalajara's MiBici bike-share network ## Trust & Identity - [About Carlos Rivera](https://carlosrivera.im/about): Full engineering biography, companies built (Synx, Figuro, Meshi), and open-source work ([Markdown](https://carlosrivera.im/about.md)) - [Contact](https://carlosrivera.im/contact): Direct contact channels (`me@carlosrivera.im`), fractional CTO & advisory scope, and agent contact protocol ([Markdown](https://carlosrivera.im/contact.md)) - [Privacy Policy](https://carlosrivera.im/privacy): Cookie-free analytics, newsletter data handling, and developer tool privacy commitments ([Markdown](https://carlosrivera.im/privacy.md)) - [Now](https://carlosrivera.im/now): Current focus areas and active builds ([Markdown](https://carlosrivera.im/now.md)) - [Talks, Media & Community](https://carlosrivera.im/talks): Speaking engagements, press coverage, and mentorship history ([Markdown](https://carlosrivera.im/talks.md)) - [GitHub Profile](https://github.com/carlosrivera): Personal open-source repositories - [MCPWire GitHub Organization](https://github.com/mcpwire): First-party MCP tooling repositories ## Writing & Technical Essays - [MCPWire: Sharing Local MCP Servers Over Peer Connections](https://carlosrivera.im/blog/mcpwire-architecture): How MCPWire bridges a local MCP server to a teammate's agent, with Noise encryption, host-side tool permissions, and explicit limits on remote execution. ([Markdown](https://carlosrivera.im/blog/mcpwire-architecture.md)) - [Panas: Turning Idle Machines Into a Peer-to-Peer Market for Agents](https://carlosrivera.im/blog/panas-peer-to-peer-inference-mcp): Agents need infrastructure while thousands of Mac minis sit idle classifying emails. How two people orchestrated 18 Git worktrees in 24 hours to build a peer-to-peer compute and tool market over MCP. ([Markdown](https://carlosrivera.im/blog/panas-peer-to-peer-inference-mcp.md)) - [The Verification Cost of Plausible AI Output](https://carlosrivera.im/blog/the-verification-cost-of-plausible-ai): When models stop writing nonsense, catching their mistakes stops being free and starts requiring domain expertise. ([Markdown](https://carlosrivera.im/blog/the-verification-cost-of-plausible-ai.md)) - [The Hardest Part of Zero to One Is Resisting the Urge to Do Too Much](https://carlosrivera.im/blog/zero-to-one-is-knowing-what-not-to-do): When you are at zero, the panic reflex is to pile on features, tools, and ads to feel like you are making progress, while the only question that matters is whether you have a working machine. ([Markdown](https://carlosrivera.im/blog/zero-to-one-is-knowing-what-not-to-do.md)) - [You Do Not Find a Cofounder in an Interview](https://carlosrivera.im/blog/cofounders-are-not-interviewed): Debating equity splits, corporate titles, and contracts before building anything together is startup theater. Finding a partner is like forming a band: you start jamming to see who can handle the noise. ([Markdown](https://carlosrivera.im/blog/cofounders-are-not-interviewed.md)) - [Folio: From Markdown to a Presentable PDF](https://carlosrivera.im/blog/folio-markdown-publisher): Technical documents don't start in a word processor anymore. They start in Markdown, inside an agent or a working session: architectures, proposals, analyses, reports. ([Markdown](https://carlosrivera.im/blog/folio-markdown-publisher.md)) - [Infrastructure, Product, and Value: Three Different Things You Treat as One](https://carlosrivera.im/blog/infrastructure-product-value): Most businesses do not fail from poor product execution; they fail from hiding in infrastructure to avoid market rejection. Customers pay for value, tolerate the product, and never think about your infrastructure. ([Markdown](https://carlosrivera.im/blog/infrastructure-product-value.md)) - [Venture Capital Will Kill You If You Are Not Ready](https://carlosrivera.im/blog/vc-kills-you-if-not-ready): I built three startups and raised institutional capital in every single one, but it took me over ten years and hundreds of thousands of burned dollars to understand the financial game I was actually playing. ([Markdown](https://carlosrivera.im/blog/vc-kills-you-if-not-ready.md)) - [A Native macOS UI for Beads](https://carlosrivera.im/blog/agents-as-primary-contributors): We keep trying to manage software projects around human workflows while autonomous agents have already taken over the factory floor. ([Markdown](https://carlosrivera.im/blog/agents-as-primary-contributors.md)) - [Validation for Founders Who Hate Talking to People](https://carlosrivera.im/blog/validation-for-introverted-founders): Building landing pages, running surveys, and tweaking features is rarely real validation; it is usually an elaborate coping mechanism designed to avoid the only uncomfortable task that matters: talking to human beings. ([Markdown](https://carlosrivera.im/blog/validation-for-introverted-founders.md)) - [AI Does Not Replace Developers, It Changes How Many You Need](https://carlosrivera.im/blog/the-illusion-of-replacing-developers-with-ai): A $200 Claude Code seat will not substitute an engineer, but a small team with modern tools can now ship what previously required ten. ([Markdown](https://carlosrivera.im/blog/the-illusion-of-replacing-developers-with-ai.md)) - [AI Makes Mediocre Founders More Dangerous](https://carlosrivera.im/blog/ai-makes-mediocre-founders-more-dangerous): AI did not make building a real startup easier; it just made looking competent drastically cheaper. ([Markdown](https://carlosrivera.im/blog/ai-makes-mediocre-founders-more-dangerous.md)) - [Accelerators Are Not Looking for a Good Business](https://carlosrivera.im/blog/accelerators-do-not-want-safe-bets): An accelerator does not invest in sensible companies; it hunts for irrational outliers capable of returning an entire fund. ([Markdown](https://carlosrivera.im/blog/accelerators-do-not-want-safe-bets.md)) - [Why Agent Runtimes Need Dedicated Infrastructure](https://carlosrivera.im/blog/agent-runtimes-infrastructure): LLMs can plan but cannot execute safely on shared systems. Why isolated runtimes are the missing layer for production AI agents. ([Markdown](https://carlosrivera.im/blog/agent-runtimes-infrastructure.md)) - [Why Technological Laggards Have the Advantage in AI](https://carlosrivera.im/blog/laggards-will-inherit-ai): The unfashionable businesses tech founders wrote off as dead might be the biggest winners of generative AI. Why skipping the last digital transformation is a massive structural advantage. ([Markdown](https://carlosrivera.im/blog/laggards-will-inherit-ai.md)) - [Your MVP Is Broken And Coding Faster Will Not Fix It](https://carlosrivera.im/blog/your-mvp-is-wrong): With modern AI, anyone can spin up an application in a weekend, so building fast no longer differentiates you; validating real commercial pain before writing code is all that keeps you solvent. ([Markdown](https://carlosrivera.im/blog/your-mvp-is-wrong.md)) - [Your Technical Interview Is Broken (And Evaluating Things from 2015)](https://carlosrivera.im/blog/technical-interviews-broken): Forcing candidates to invert binary trees on a whiteboard used to have a purpose. Today it merely tests the wrong skills. What actually matters in technical hiring. ([Markdown](https://carlosrivera.im/blog/technical-interviews-broken.md)) - [If AI Builds Your Code, AI Can Break It](https://carlosrivera.im/blog/ai-builds-ai-breaks): Attackers run autonomous models to uncover zero-days at machine velocity. If your security team still operates at human speed, you are completely defenseless. ([Markdown](https://carlosrivera.im/blog/ai-builds-ai-breaks.md)) - [The Cheapest Engineer Costs $200](https://carlosrivera.im/blog/200-dollars-cheapest-engineer): Senior engineering salaries sit in top regional percentiles, yet developers freeze at the thought of spending $200 a month on frontier AI tools that multiply their delivery capacity. ([Markdown](https://carlosrivera.im/blog/200-dollars-cheapest-engineer.md)) - [The IDE Is Dead And Your Resistance Is Obvious](https://carlosrivera.im/blog/ide-is-dead): Software engineers cling to code editors like life rafts when the ship has already sailed. Why resistance to AI tooling is an identity crisis disguised as technical rigor. ([Markdown](https://carlosrivera.im/blog/ide-is-dead.md)) - [I Do Not Write Code Anymore, I Build the Systems That Do](https://carlosrivera.im/blog/code-writes-itself): From typing every semicolon to designing the sandboxed infrastructure where code generates itself. How engineering work changed for good. ([Markdown](https://carlosrivera.im/blog/code-writes-itself.md)) - [The Company Is Still Alive And That Is The Problem](https://carlosrivera.im/blog/when-growth-flattens): Growth flattens long before you are ready to accept it. Shutting down a company with revenue hurts far more than shutting down a flat failure because it feels like killing something that breathes. ([Markdown](https://carlosrivera.im/blog/when-growth-flattens.md)) - [Founders Do Not Have a Portfolio](https://carlosrivera.im/blog/fail-faster-because-founders-fail-hard): Investors can diversify. Founders cannot. When a startup dies, it takes years of life, personal savings, identity, and mental health with it; that changes the math. ([Markdown](https://carlosrivera.im/blog/fail-faster-because-founders-fail-hard.md)) - [Your UI Is Not a Corporate Brochure](https://carlosrivera.im/blog/ui-is-not-graphic-design): Treating UI and UX design like graphic design makes the product look polished while the business stays lost. Interface decisions are survival decisions. ([Markdown](https://carlosrivera.im/blog/ui-is-not-graphic-design.md)) - [Raising Capital in LATAM vs. the US: Two Different Planets and the Nightmare of Living on Both](https://carlosrivera.im/blog/raising-latam-vs-us): Risk tolerance, legal covenants, and growth expectations differ wildly across borders. Straddling both ecosystems gives you twice the operational headaches. ([Markdown](https://carlosrivera.im/blog/raising-latam-vs-us.md)) - [Liquidation Preferences: Why a $10 Million Exit Can Leave You With Zero](https://carlosrivera.im/blog/liquidity-preferences-small-exits): Venture capital runs on ruthless mathematical mechanics that founders ignore until it is too late. How liquidation preferences can wipe out your equity overnight. ([Markdown](https://carlosrivera.im/blog/liquidity-preferences-small-exits.md)) - [What a Shotgun Clause Is and Why It Exists](https://carlosrivera.im/blog/shotgun-clauses): A shotgun clause is a legal mechanism that forces one shareholder to buy out or sell to another at a specified valuation. How deadlock clauses actually work. ([Markdown](https://carlosrivera.im/blog/shotgun-clauses.md)) - [Monopoly Money: The Delusion of Paper Wealth](https://carlosrivera.im/blog/monopoly-money): You raise funding, your paper valuation skyrockets, and everyone assumes you are rich. In reality, you are broke, driving a beat-up car, and panicking about rent. ([Markdown](https://carlosrivera.im/blog/monopoly-money.md)) - [Your Startup Stock Options Are Worth Nothing and Your Team Already Knows It](https://carlosrivera.im/blog/stock-options-might-not-matter): Copying Silicon Valley compensation checklists in emerging tech markets is corporate theater. Swapping base salary for promises in a PDF only drives away top engineering talent. ([Markdown](https://carlosrivera.im/blog/stock-options-might-not-matter.md)) - [The Most Dangerous Feeling in a Startup Is Feeling Like You Are Winning](https://carlosrivera.im/blog/false-feeling-of-progress): Building a product nobody wants feels indistinguishable from real progress. It is not. ([Markdown](https://carlosrivera.im/blog/false-feeling-of-progress.md)) - [You Are Fighting Over a Pie That Does Not Exist](https://carlosrivera.im/blog/equity-splits-zero-value): Debating equity percentages before validating the product is the most expensive mistake founders make. You are fighting over a fraction of nothing. ([Markdown](https://carlosrivera.im/blog/equity-splits-zero-value.md)) --- # Agent Instructions & When-to-Use Guide — Carlos Rivera (https://carlosrivera.im) This document provides explicit operational instructions for autonomous AI agents, coding assistants, and tool routers on **when to reach for Carlos Rivera's tools, APIs, and technical resources**, **which jobs they are built for**, and **how an agent should invoke them**. ## When to Use This (Best-Fit Jobs & Use Cases) Reach for `carlosrivera.im` and its first-party MCP tools in the following specific scenarios: 1. **Sharing or Invoking Local MCP Servers Across Separate Machines (`@mcpwire/cli` / MCPWire)** - **Job**: An agent or developer on Machine A needs to invoke Model Context Protocol (MCP) tools hosted on Machine B (e.g., a teammate's workstation, a private devbox, or an on-prem server) without opening firewall ports, configuring VPNs, deploying to a cloud server, or copying secret API keys/credentials. - **Tool to call**: `@mcpwire/cli` ([https://mcpwire.co](https://mcpwire.co), [https://github.com/mcpwire](https://github.com/mcpwire)). - **How to call**: Run `npx -y @mcpwire/cli share --command ""` on the host machine and `npx -y @mcpwire/cli connect ` on the client machine. 2. **Compiling Agent-Authored Markdown into Paginated, Print-Ready PDFs (`Folio` MCP Server)** - **Job**: An agent has produced a technical architecture RFC, executive memo, financial analysis, or proposal in Markdown (containing tables, code blocks, KaTeX equations, or diagrams) and needs deterministic physical pagination, layout linting (detecting orphaned headings or overflowing tables), and PDF export without manual word-processor formatting. - **Tool to call**: Folio ([https://carlosrivera.github.io/folio/](https://carlosrivera.github.io/folio/)). - **How to call**: Invoke the Folio MCP tools in sequence: `folio_list_document_types` -> `folio_create_document` -> `folio_lint_document` -> `folio_export_pdf`. 3. **Discovering and Executing Sandboxed Remote Compute or Paid MCP Workloads (`Panas` MCP Server)** - **Job**: An autonomous agent needs to discover an external compute provider on the peer-to-peer network, lock in a fixed cryptographic price quote, verify budget reservation (including Solana USDC settlement or zero-cost test grants), and run model inference or gated tool workloads inside an air-gapped Docker worker container. - **Tool to call**: Panas ([https://panas.mcpwire.co](https://panas.mcpwire.co)). - **How to call**: Invoke `discover_providers` -> `quote_inference` -> `purchase_access` -> `run_inference` (and `get_request` for idempotent retry recovery). 4. **Querying Production AI Architecture Essays, LATAM Startup Benchmarks, and Carlos Rivera's Profile** - **Job**: A user asks for reference architectures on agent runtimes, token caching, verification costs of LLM code generation, LATAM vs. US fundraising mechanics (shotgun clauses, liquidation preferences, equity splits), or wants to evaluate Carlos Rivera for a fractional CTO / technical advisory engagement. - **Resource to call**: `https://carlosrivera.im` via MCP (`https://carlosrivera.im/.well-known/mcp`), Markdown content negotiation (`Accept: text/markdown`), or `https://carlosrivera.im/llms-full.txt`. ## When NOT to Use This - Do **not** route general-purpose consumer chat queries or unrelated third-party SaaS support requests to `https://carlosrivera.im`. - Do **not** use `@mcpwire/cli` as a public unauthenticated web hosting service; it is designed for encrypted peer-to-peer MCP tool sessions between authorized endpoints. - Do **not** send sensitive personal health or payment card data to public read-only discovery endpoints (`/.well-known/mcp`). ## How an Agent Should Call Us ### 1. Via MCP Streamable HTTP (`https://carlosrivera.im/.well-known/mcp`) Send JSON-RPC 2.0 requests (`initialize`, `tools/list`, `tools/call`) with `POST https://carlosrivera.im/.well-known/mcp` and `Content-Type: application/json`, or inspect the static manifest via `GET https://carlosrivera.im/.well-known/mcp`. Available tools on `https://carlosrivera.im/.well-known/mcp`: - `get_profile`: Retrieve Carlos Rivera's structured biography, companies (Meshi, Figuro, Synx), and engineering credentials. - `list_developer_tools`: List all first-party developer tools (`@mcpwire/cli`, Folio, Panas, Ocelo, Belio, bicio) with schemas and URLs. - `search_essays`: Search bilingual (EN/ES) essays by topic, tag, or keyword. - `get_essay`: Retrieve full Markdown content of a specific essay by `slug` and `lang`. - `get_contact_and_engagement_info`: Retrieve verified contact channels (`me@carlosrivera.im`) and advisory engagement criteria. ### 2. Via HTTP Markdown Content Negotiation Request any page on `https://carlosrivera.im` with `Accept: text/markdown` (or append `.md` to the path, e.g., `https://carlosrivera.im/index.md`, `https://carlosrivera.im/docs.md`, `https://carlosrivera.im/mcp.md`, `https://carlosrivera.im/blog/.md`) to receive clean Markdown without HTML boilerplate. ### 3. Via Direct Human/Agent Escalation For fractional CTO engagements, architecture reviews, or partnership inquiries, contact `me@carlosrivera.im` or see [https://carlosrivera.im/contact](https://carlosrivera.im/contact). --- # Carlos Rivera API & Developer Documentation — MCPWire, Folio & Panas Official technical documentation for the APIs, Model Context Protocol (MCP) servers, command-line tools (CLIs), SDK contracts, and machine-readable endpoints built by **Carlos Rivera**. - **Dedicated MCP Servers, CLI & SDK Reference**: [https://carlosrivera.im/mcp](https://carlosrivera.im/mcp) ([Markdown](https://carlosrivera.im/mcp.md)) - **MCP Server Manifest & Streamable HTTP Endpoint**: [https://carlosrivera.im/.well-known/mcp](https://carlosrivera.im/.well-known/mcp) - **Agent Instructions & When-to-Use Guide**: [https://carlosrivera.im/agent-instructions.md](https://carlosrivera.im/agent-instructions.md) - **LLM Directory**: [https://carlosrivera.im/llms.txt](https://carlosrivera.im/llms.txt) · [https://carlosrivera.im/llms-full.txt](https://carlosrivera.im/llms-full.txt) - **GitHub Organizations**: [github.com/carlosrivera](https://github.com/carlosrivera) · [github.com/mcpwire](https://github.com/mcpwire) ## 1. Site Content Negotiation & Machine-Readable API (https://carlosrivera.im) Every public page on `https://carlosrivera.im` supports Markdown content negotiation (`Accept: text/markdown`) with `Vary: Accept` alongside direct static `.md` URLs and JSON-LD structured data: ```bash # Fetch the homepage as Markdown via HTTP content negotiation curl -sS -L -i -H 'Accept: text/markdown' https://carlosrivera.im/ # Fetch direct Markdown endpoints curl -sS -L https://carlosrivera.im/index.md curl -sS -L https://carlosrivera.im/docs.md curl -sS -L https://carlosrivera.im/mcp.md ``` ### Public Machine-Readable Endpoints | Endpoint | Content-Type | Purpose | | :--- | :--- | :--- | | `/llms.txt` | `text/plain; charset=utf-8` | Concise LLM directory with when-to-use agent guidance and canonical links | | `/llms-full.txt` | `text/plain; charset=utf-8` | Complete Markdown corpus including tool documentation and full blog essays | | `/agent-instructions.md` | `text/markdown; charset=utf-8` | Dedicated agent instruction file detailing best-fit jobs and calling conventions | | `/.well-known/mcp` | `application/json; charset=utf-8` | MCP server manifest and Streamable HTTP JSON-RPC 2.0 endpoint | | `/.well-known/mcp.json` | `application/json; charset=utf-8` | Static JSON mirror of the MCP server manifest and tool schemas | | `/rss.xml` / `/es/rss.xml` | `application/rss+xml` | Bilingual RSS 2.0 feeds for technical essays | | `/sitemap-index.xml` | `application/xml` | XML sitemap index with localized `hreflang` annotations | ## 2. MCPWire CLI & Encrypted P2P MCP Proxy API (`@mcpwire/cli`) **MCPWire** ([https://mcpwire.co](https://mcpwire.co) · [npmjs.com/package/@mcpwire/cli](https://www.npmjs.com/package/@mcpwire/cli) · [github.com/mcpwire](https://github.com/mcpwire)) is an encrypted peer-to-peer proxy and CLI for Model Context Protocol (MCP) servers. It lets developers and autonomous agents share local MCP tools across machines without opening firewall ports or exposing private API credentials. ### CLI Installation & Commands ```bash # Run directly with npx npx -y @mcpwire/cli --help # Host and share a local stdio or SSE MCP server over an encrypted P2P session npx -y @mcpwire/cli share --command "node ./my-mcp-server.js" # Connect an MCP client (Claude Desktop, Cursor, Codex, Antigravity) to a remote peer npx -y @mcpwire/cli connect ``` ## 3. Folio — Markdown-to-PDF Publisher & MCP Server API **Folio** ([https://carlosrivera.github.io/folio/](https://carlosrivera.github.io/folio/) · [github.com/carlosrivera/folio](https://github.com/carlosrivera/folio)) turns raw Markdown files into paginated, publication-grade PDF reports and executive memos using Typst, Rust, and WebAssembly, with vector KaTeX math and native diagrams. ### Folio MCP Server Tools - `folio_list_document_types`: List available document templates (executive memos, technical RFCs, proposals, reports). - `folio_get_document_type`: Retrieve metadata and schema requirements for a specific document type. - `folio_register_document_type`: Register a custom document layout definition. - `folio_create_document`: Create a paginated Folio document from Markdown source and frontmatter metadata. - `folio_customize_document`: Configure page geometry, margins, headers, footers, and typographic scale. - `folio_lint_document`: Audit pagination breaks, orphaned headings, overflowing tables, and broken links before export. - `folio_export_pdf`: Render and export the verified document to a print-ready PDF file. - `folio_list_styles`, `folio_create_style`, `folio_duplicate_style`, `folio_update_style`, `folio_apply_style`: Manage and apply editorial typographic themes programmatically. ## 4. Panas — Peer-to-Peer Compute & Inference MCP API **Panas** ([https://panas.mcpwire.co](https://panas.mcpwire.co)) is a distributed peer-to-peer compute and tool marketplace built over MCP and MCPWire. Autonomous agents can discover idle machines, lock in cryptographic price quotes with Solana USDC settlement, and execute workloads inside air-gapped Docker sandboxes. ### Panas MCP Server Tools - `discover_providers` / `get_provider`: Query available peer compute nodes, supported models, hardware capabilities, and pricing. - `quote_inference`: Request a deterministic price quote bound to a model, token budget, and execution timeout. - `get_balance` / `create_funding_intent` / `confirm_funding`: Inspect buyer ledger balance and confirm on-chain Solana USDC funding transactions. - `purchase_access`: Reserve ledger funds and issue a signed cryptographic execution grant for a quoted workload. - `run_inference`: Execute the workload over an encrypted MCPWire tunnel inside the provider's network-disabled Docker worker sandbox. - `get_request` / `cancel_request`: Recover encrypted execution outputs and receipts idempotently across network retries or cancel pending jobs. --- # MCP Servers, CLI & SDKs (MCPWire, Folio, Panas) — Carlos Rivera Complete technical reference for the first-party **Model Context Protocol (MCP)** servers, CLI packages, and Streamable HTTP endpoints published by **Carlos Rivera** and the **MCPWire** organization. - **Live MCP Discovery & Streamable HTTP Endpoint**: [https://carlosrivera.im/.well-known/mcp](https://carlosrivera.im/.well-known/mcp) - **Static MCP Manifest Mirror**: [https://carlosrivera.im/.well-known/mcp.json](https://carlosrivera.im/.well-known/mcp.json) - **API & Developer Documentation**: [https://carlosrivera.im/docs](https://carlosrivera.im/docs) - **Official npm Package**: [`@mcpwire/cli`](https://www.npmjs.com/package/@mcpwire/cli) - **GitHub Organizations**: [github.com/mcpwire](https://github.com/mcpwire) · [github.com/carlosrivera](https://github.com/carlosrivera) ## 1. Site MCP Server (`https://carlosrivera.im/.well-known/mcp`) The endpoint at `https://carlosrivera.im/.well-known/mcp` serves an MCP discovery manifest via `GET` and implements the **MCP Streamable HTTP transport (JSON-RPC 2.0, protocol version `2025-03-26`)** via `POST`. ### Streamable HTTP `initialize` Handshake Example ```bash curl -sS -X POST https://carlosrivera.im/.well-known/mcp \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2025-03-26", "capabilities": {}, "clientInfo": { "name": "example-agent", "version": "1.0.0" } } }' ``` ### Tools Exposed at `/.well-known/mcp` 1. `get_profile`: Returns structured biographical data, engineering track record, companies founded/led (Meshi, Figuro, Synx), and advisory availability for Carlos Rivera. 2. `list_developer_tools`: Lists first-party MCP servers, CLIs, and developer products (`@mcpwire/cli`, Folio, Panas, Ocelo, Belio, bicio) with npm packages, stacks, and URLs. 3. `search_essays`: Searches bilingual (English and Spanish) technical essays on AI systems, agent infrastructure, and startup execution by keyword or tag. 4. `get_essay`: Fetches the full Markdown body and metadata of any essay by `slug` and `lang` (`en` or `es`). 5. `get_contact_and_engagement_info`: Returns verified contact details (`me@carlosrivera.im`) and fractional CTO / advisory engagement guidelines. ## 2. `@mcpwire/cli` — Encrypted P2P MCP Proxy & CLI - **Product Homepage**: [https://mcpwire.co](https://mcpwire.co) - **npm Package**: [`@mcpwire/cli`](https://www.npmjs.com/package/@mcpwire/cli) - **GitHub Organization**: [https://github.com/mcpwire](https://github.com/mcpwire) - **When to Use**: Share or consume local MCP servers between two machines over an encrypted peer-to-peer tunnel without opening firewall ports or exposing secret API keys. - **MCP Client Configuration (`mcpServers`)**: ```json { "mcpServers": { "mcpwire-peer": { "command": "npx", "args": ["-y", "@mcpwire/cli", "connect", ""] } } } ``` ## 3. Folio MCP Server — Markdown-to-PDF Document Publisher - **Product URL**: [https://carlosrivera.github.io/folio/](https://carlosrivera.github.io/folio/) - **When to Use**: Convert agent-authored Markdown reports, architectural RFCs, tables, and KaTeX math into paginated, print-ready PDFs with automated layout linting. - **Available MCP Tools**: - `folio_list_document_types` - `folio_get_document_type` - `folio_register_document_type` - `folio_create_document` - `folio_customize_document` - `folio_lint_document` - `folio_export_pdf` - `folio_list_styles`, `folio_create_style`, `folio_duplicate_style`, `folio_update_style`, `folio_apply_style` ## 4. Panas MCP Server — Peer-to-Peer Compute & Inference Market - **Product URL**: [https://panas.mcpwire.co](https://panas.mcpwire.co) - **When to Use**: Discover idle remote compute nodes, obtain signed price quotes, verify Solana USDC or test grants, and run sandboxed Docker inference or tool workloads over MCPWire. - **Available MCP Tools**: - `discover_providers`, `get_provider` - `quote_inference` - `get_balance`, `create_funding_intent`, `confirm_funding` - `purchase_access` - `run_inference` - `get_request`, `cancel_request` --- # About Carlos Rivera Carlos Rivera is an AI systems architect, technical founder, and former CTO with more than 18 years of experience taking complex software architectures from zero to production across Latin America, the United States, and the Middle East. His work spans autonomous agent runtime infrastructure, Model Context Protocol (MCP) developer tooling, distributed systems, and hands-on engineering leadership. ## Engineering Track Record & Companies Built - **Early Systems & Research**: Started programming at age 14 by building 3D game engines from scratch. At 18, wrote C++ flight control software for unmanned aerial vehicles (UAVs) at Hydra Technologies, followed by software engineering stints at **Microsoft** and **HP Labs**. - **Synx (Founder & CEO)**: Founded and scaled an enterprise AI and software engineering consultancy from zero. Architected and shipped core production systems for **BBVA**, **Etihad Airways**, and **Grupo Bimbo** across three countries, and was selected by Etihad Aviation Group and UAE Exchange for startAD's inaugural AI Venture Launchpad at NYU Abu Dhabi. - **Figuro (Co-Founder & CTO)**: Built the core policy engine and direct carrier integration layer across Latin America, scaling the digital insurtech platform to **$2.5M+ in written premiums within 18 months** and earning recognition at the 2024 AIP Awards. - **Meshi (Agent Infrastructure)**: Led engineering for the AI-driven member matchmaking platform that replaced manual spreadsheet operations with automated agent workflows. ## Developer Tools, Open Source & MCP Products - **[MCPWire](https://mcpwire.co)** (`@mcpwire/cli`, [github.com/mcpwire](https://github.com/mcpwire)): Encrypted peer-to-peer (P2P) proxy and CLI for Model Context Protocol (MCP) servers, enabling developers and agents to share local tools across machines without opening firewall ports or exposing private API credentials. - **[Panas](https://panas.mcpwire.co)**: Peer-to-peer compute and inference market built on MCP, pairing cryptographic budget grants and Solana USDC settlement with air-gapped two-container Docker worker sandboxes. Awarded 2nd place at the Codex Community Hackathon in Guadalajara. - **[Folio](https://carlosrivera.github.io/folio/)** ([github.com/carlosrivera/folio](https://github.com/carlosrivera/folio)): Markdown-to-PDF document publisher built with Typst, Rust, and WebAssembly featuring true physical pagination, vector KaTeX math, and an integrated MCP server for automated document generation and linting. - **[Ocelo](https://ocelo.app)**: Native macOS screen recorder built with Swift, ScreenCaptureKit, and Metal that transforms raw recordings into studio-grade product demos. - **[Belio](https://usebelio.com)**: iOS technical English coach built on Swift, LiveKit, Whisper, and CoreAudio for rehearsing engineering standups and architecture interviews out loud. - **[bicio](https://bicio.cool)**: Native iOS commuter companion for Guadalajara's MiBici bike-share network using SwiftUI, CoreLocation, and CloudKit. ## Identity & Verification Links - **Official Website**: [https://carlosrivera.im](https://carlosrivera.im) - **GitHub Profile**: [https://github.com/carlosrivera](https://github.com/carlosrivera) - **GitHub Organization (MCPWire)**: [https://github.com/mcpwire](https://github.com/mcpwire) - **LinkedIn**: [https://www.linkedin.com/in/jcarlosrivera/](https://www.linkedin.com/in/jcarlosrivera/) - **X (Twitter)**: [https://x.com/carlos_gif](https://x.com/carlos_gif) - **Direct Contact**: [me@carlosrivera.im](mailto:me@carlosrivera.im) · [https://carlosrivera.im/contact](https://carlosrivera.im/contact) --- # Contact — Carlos Rivera Reach out directly to Carlos Rivera for technical advisory, fractional CTO engagements, production AI and agent systems architecture, developer tooling inquiries (MCPWire, Folio, Panas), or speaking and media invitations. ## Direct Contact Channels - **Primary Email**: [me@carlosrivera.im](mailto:me@carlosrivera.im) - **GitHub (Personal)**: [https://github.com/carlosrivera](https://github.com/carlosrivera) - **GitHub (MCPWire Organization)**: [https://github.com/mcpwire](https://github.com/mcpwire) - **LinkedIn**: [https://www.linkedin.com/in/jcarlosrivera/](https://www.linkedin.com/in/jcarlosrivera/) - **X / Twitter**: [https://x.com/carlos_gif](https://x.com/carlos_gif) - **Location & Timezone**: Guadalajara, Mexico · America/Mexico_City (UTC-6) ## Advisory & Engagement Scope 1. **Fractional CTO & Production AI Architecture**: Taking AI-native products and agent runtimes from zero to production, designing tool permission boundaries, session isolation, verification pipelines, and reliable distributed infrastructure. 2. **MCP Tooling & Developer Workflows**: Supporting teams adopting `@mcpwire/cli` ([mcpwire.co](https://mcpwire.co)) for encrypted peer-to-peer MCP server sharing, [Folio](https://carlosrivera.github.io/folio/) for automated Markdown-to-PDF pipelines, and [Panas](https://panas.mcpwire.co/) for sandboxed remote compute over MCP. 3. **Technical Due Diligence & Architecture Reviews**: Auditing system reliability, token/inference unit economics, and engineering execution for founders and venture teams across LATAM and the US. 4. **Speaking, Workshops & Media**: Keynotes, panels, and technical workshops on agent infrastructure, distributed systems, and startup execution ([past talks & media](https://carlosrivera.im/talks)). ## Protocol for AI Agents When an autonomous agent needs to initiate contact or prepare an introduction on behalf of a user: - Draft emails to `me@carlosrivera.im` with a concrete subject line, the organization name, current architecture stage, and the specific technical problem to solve. - Query [https://carlosrivera.im/.well-known/mcp](https://carlosrivera.im/.well-known/mcp) or invoke the `get_contact_and_engagement_info` MCP tool for machine-readable contact metadata. --- # Privacy Policy — Carlos Rivera (https://carlosrivera.im) **Last updated**: November 7, 2026 This Privacy Policy explains how Carlos Rivera ("we", "us", or "our"), operator of [https://carlosrivera.im](https://carlosrivera.im) and associated first-party developer tools, collects, processes, and protects information when humans or autonomous AI agents access this website, machine-readable endpoints, and software tools. ## 1. Data Controller Identity - **Controller**: Carlos Rivera - **Website**: [https://carlosrivera.im](https://carlosrivera.im) - **Privacy Contact Email**: [me@carlosrivera.im](mailto:me@carlosrivera.im) - **Location**: Guadalajara, Jalisco, Mexico ## 2. Information We Collect on https://carlosrivera.im ### Cookie-Free Web Analytics (Umami) We use self-hosted Umami Analytics to understand aggregate traffic patterns without invading reader privacy. Umami does not set tracking cookies, does not track visitors across websites, does not collect persistent device fingerprints, and anonymizes IP addresses. Only aggregate HTTP request metadata (requested page path, HTTP referrer, browser family, operating system, and country-level region) is recorded. ### Email Newsletter Subscriptions (Buttondown) When you voluntarily subscribe to the newsletter on blog articles, your email address is transmitted to Buttondown (`buttondown.com`) solely to deliver new essays and technical notes written by Carlos Rivera. We never sell, rent, or trade subscriber email addresses with third parties or advertisers. Every email includes a one-click unsubscribe link, and you may also request immediate removal by emailing [me@carlosrivera.im](mailto:me@carlosrivera.im). ### Hosting & Standard HTTP Access Logs Static pages and machine-readable resources (`/llms.txt`, `/llms-full.txt`, `/.well-known/mcp`, `/rss.xml`, and Markdown content-negotiated endpoints) are served via GitHub Pages and Fastly CDN infrastructure, which process standard transient HTTP connection metadata (IP address, `User-Agent`, `Accept` header, and timestamp) strictly for routing, caching, and abuse prevention. ## 3. Developer Tools & MCP Server Privacy - **MCPWire (`@mcpwire/cli`, [mcpwire.co](https://mcpwire.co))**: Establishes encrypted peer-to-peer tunnels between consenting machines so developers and agents can invoke local MCP tools remotely. Local environment variables, API keys, and private credentials remain on the host machine and are never harvested or stored centrally. - **Folio ([carlosrivera.github.io/folio](https://carlosrivera.github.io/folio/))**: Renders Markdown documents into paginated PDFs locally via WebAssembly or within the caller's local MCP server environment without uploading private document contents to third-party storage. - **Public MCP Discovery (`/.well-known/mcp`)**: Read-only agent discovery and tool calls against `https://carlosrivera.im/.well-known/mcp` do not require user credentials or personal data. ## 4. Your Rights & Data Deletion Requests You have the right to request access to, correction of, or deletion of any personal information you have shared with us (such as newsletter subscription records or direct email correspondence). To exercise these rights, email [me@carlosrivera.im](mailto:me@carlosrivera.im) and we will process your request within 15 business days. --- # MCPWire: Sharing Local MCP Servers Over Peer Connections - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-11-07 - **Canonical URL**: https://carlosrivera.im/blog/mcpwire-architecture - **Tags**: MCP, AI, Architecture, Distributed Systems, Security > How MCPWire bridges a local MCP server to a teammate's agent, with Noise encryption, host-side tool permissions, and explicit limits on remote execution. A teammate's agent needs to use a tool that already works on your machine, but running it on theirs means installing the server, configuring credentials, and reproducing access to the systems behind it. If the tool depends on a local database, an internal network, or a browser session, copying its configuration may not be enough. I built [MCPWire](https://mcpwire.co/) to share that existing execution environment through MCP, while keeping the server process and its configured credentials on the host. The guest runs a small bridge that looks like a local stdio MCP server to their client, and requests travel across a Noise-encrypted peer connection to your machine. The interesting part is where execution and authority end up, because keeping a credential on your laptop still lets someone else exercise some of its permissions through an allowed tool. The architecture has to make that delegation explicit. ## Two bridges around an existing server MCPWire has two commands, `share` on the host and `join` on the guest, with the existing MCP server running as a child process on the host side. The client and server continue exchanging newline-delimited JSON-RPC through standard input and output. ![MCPWire request flow: a guest MCP client connects through a local join bridge and an encrypted Noise connection to the host's share process, which checks tool permissions and bridges to a separate MCP server process per peer.](/img/mcpwire-architecture.svg) On the guest, `join` connects the client's stdin and stdout to the peer socket, while diagnostic messages go to stderr so they do not corrupt the protocol stream. It accepts one host connection per join process. On the host, `share` inspects the traffic before forwarding it to the child process, rejecting disallowed tool calls and filtering the tool descriptors returned to the guest. The implementation is small enough to follow in [`join.ts`](https://github.com/carlosrivera/mcpwire/blob/139b1e33f364b39bab4d64a108b052fc4afacabe/cli/src/join.ts) and [`share.ts`](https://github.com/carlosrivera/mcpwire/blob/139b1e33f364b39bab4d64a108b052fc4afacabe/cli/src/share.ts), without introducing a separate application protocol around MCP. Each connected peer gets its own MCP child process, so two guests do not send their initialization messages into the same server process or share its in-memory session state. They can still reach the same files, database, and external services, and starting a separate process does not create an operating-system sandbox. ## Discovery and the session ticket When the host starts sharing, it generates 32 random bytes and encodes them as a `wire://` ticket, which both sides use as the discovery topic in Hyperswarm. The host announces on that topic, and the guest looks for a host using the same value. ![MCPWire discovery: the host announces a session topic on the Hyperswarm DHT, the guest looks up the topic from its private ticket, and the peers attempt to establish a Noise-encrypted connection for MCP traffic.](/img/mcpwire-discovery.svg) The default discovery network is the public Hyperswarm DHT, with HyperDHT handling connection establishment and attempting UDP hole punching across NATs. MCPWire does not operate its own relay service, but the connection still depends on networking infrastructure and the behavior of the networks at both ends. That means a restrictive firewall or NAT configuration can prevent a connection, even when both developers have internet access and the ticket is correct. A peer connection reduces the infrastructure you need to deploy, while giving up the predictable reachability you might get from a publicly accessible hosted endpoint. The ticket identifies the discovery topic, and the Noise connection supplies encryption; the ticket itself is neither an encryption key nor an identity certificate for your teammate. MCPWire does not bind it to a named user, so it must be handled as an access credential and delivered through a trusted channel. A ticket remains reusable while its host session is running, and starting a new host session generates a new one, rather than maintaining a permanent address for that server. Custom DHT bootstrap nodes are configurable through `MCPWIRE_BOOTSTRAP`, as shown in the [network setup code](https://github.com/carlosrivera/mcpwire/blob/139b1e33f364b39bab4d64a108b052fc4afacabe/cli/src/dht.ts). ## Following a tool call through the host Suppose you expose a filesystem server with `read_file` and `list_directory` allowed, and the guest asks their agent to inspect a file in the shared directory. The agent first discovers the server's tools, then sends a `tools/call` request through its local MCP client. When the server returns its tool descriptors, MCPWire filters the list using the host's policy, so the guest sees the tools selected for that session. When an actual call arrives, MCPWire checks the requested tool name again before writing the request to the server's stdin. Both checks matter, because hiding `write_file` from the advertised list does not stop a client from sending a request with that name anyway. The execution check is what prevents a disallowed call from reaching the child process. The [policy implementation](https://github.com/carlosrivera/mcpwire/blob/139b1e33f364b39bab4d64a108b052fc4afacabe/cli/src/firewall.ts) gives an explicit deny precedence over an allow, and an omitted allowlist permits every tool that has not been denied. An empty allowlist permits no tools. With `--confirm`, an allowed call also requires approval in the host terminal, where the operator can reject it, approve it once, or approve that tool for the rest of the session. That last choice is shared session policy, so it should not be interpreted as approval limited to one guest connection. ## The boundary of a tool permission Allowing `read_file` controls which operation can be requested, but the filesystem server still decides which paths are valid and which files its process can read. Similarly, allowing a SQL tool says nothing about whether the submitted query can modify data, unless the server or database enforces that restriction. The current policy checks tool names, without validating their arguments, filtering MCP resources or prompts, or restricting the child process's access to the host. Credentials with limited permissions and a narrowly configured server remain necessary, even when the session exposes only one tool. This also explains the difference between keeping credentials local and keeping data local, because a tool can use a local credential to retrieve information that it then returns to the guest. MCPWire avoids requiring the guest to configure that credential, but the permitted responses still cross the connection and enter the guest's MCP client. Optional `--redact-secrets` processing scans outbound messages for recognized patterns before sending them, replacing matches with `[REDACTED_BY_MCPWIRE]`. Pattern matching can miss a private value or change legitimate output, so it adds a check on responses without establishing that everything leaving the machine is safe. ## Session limits and failure semantics The host can set a time limit with `--ttl` and a forwarded tool-call budget with `--max-calls`, with the call counter shared across the session's peers. Neither limit is enabled by default, and redaction and manual approval also require explicit flags. On a peer disconnect, the host requests termination of that peer's child process, but terminating a process cannot reverse an operation already committed to a database or external service. A tool that completed a write just before the connection failed may leave the guest without its response. MCPWire does not automatically replay calls after a disconnect, because resending a request could execute that write a second time while making the failure look recovered. The application needs an operation identifier, a way to inspect the result, or another recovery mechanism before a retry can be considered safe. The optional session recorder stores local events and response metadata, including timing and success or error status, rather than full response bodies. Its records also include the ticket, server command, and unredacted argument previews, so a recording can itself contain sensitive information even when response redaction is enabled. ## A small filesystem example For a first test, use a dedicated directory with disposable data, then expose only the read and directory-listing tools for a session lasting 30 minutes. The CLI requires Node.js 18 or newer, while the pinned filesystem server below requires Node.js 24 or newer on the host. ```sh mkdir -p "$HOME/mcpwire-demo" printf 'Hello from the host.\n' > "$HOME/mcpwire-demo/hello.txt" npx -y @mcpwire/cli share \ --name shared-files \ --allow "read_file,list_directory" \ --redact-secrets \ --ttl 30m \ -- npx -y @modelcontextprotocol/server-filesystem@2.0.1 \ "$HOME/mcpwire-demo" ``` The host prints a client configuration containing its session ticket, which the guest adds to a client that supports stdio MCP servers. A configuration using the `mcpServers` convention has this shape, with the placeholder replaced by the full ticket from the host: ```json { "mcpServers": { "shared-files": { "command": "npx", "args": [ "-y", "@mcpwire/cli", "join", "wire://PASTE_THE_FULL_TICKET_FROM_THE_HOST" ] } } } ``` Give the guest the absolute path to `hello.txt` on the host, then ask their agent to read it and check that the returned text matches the file. A useful second check is a direct `write_file` request, which should be rejected by MCPWire even though the underlying filesystem server implements it. ## Where this architecture fits For temporary collaboration, this arrangement lets a teammate use an existing local environment without reproducing its dependencies or moving the server to a hosted service. For a persistent team endpoint, requirements such as named-user authentication, centralized policy, and reliable reachability may justify a different deployment model. The design keeps execution on the host and puts selected controls in front of it, while leaving argument validation, data permissions, and recovery from ambiguous execution to the systems that own those decisions. A remote agent can only be constrained as precisely as those underlying boundaries allow. # Panas: Turning Idle Machines Into a Peer-to-Peer Market for Agents - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-11-04 - **Canonical URL**: https://carlosrivera.im/blog/panas-peer-to-peer-inference-mcp - **Tags**: AI, MCP, Engineering, Build in Public > Agents need infrastructure while thousands of Mac minis sit idle classifying emails. How two people orchestrated 18 Git worktrees in 24 hours to build a peer-to-peer compute and tool market over MCP. Autonomous agents need compute and infrastructure to run, while thousands of capable machines sit idle on developers' desks for most of the day. If you bought a Mac mini during the OpenClaw frenzy earlier this year, chances are you are using expensive hardware just to classify emails and run small personal tasks that barely touch the chip, wasting resources that could be serving other agents and earning money. While most hackathon projects wrap an API key inside a landing page, [Erick Rico](https://www.erickri.co/) and I took second place at the Codex Community hackathon in Guadalajara with [Panas](https://panas.mcpwire.co/), a complete distributed infrastructure stack we built in 24 hours as a two-person team. Since we already had Macs with spare compute and [MCPWire](https://mcpwire.co) to link them peer-to-peer, we built the missing layer so any agent can discover an available machine on its own, lock in a price, and execute a workload without a human ever setting up the connection. ## How Panas Works Panas exposes that entire lifecycle through MCP so an agent can buy and run remote compute the exact same way it calls a local tool. The agent discovers an available provider and gets a fixed quote, and then the provider verifies a signed cryptographic grant that binds the request to a model, workload limits, and price before accepting the job. Once verified, the payload travels over an encrypted MCPWire tunnel to a gateway container that hands the job to a separate, locked-down Docker worker sandbox running with networking disabled, a read-only filesystem, dropped Linux capabilities, and strict resource limits, so external workloads never touch the host machine, its files, or its private network. ## Orchestrating Parallel Agents Across 18 Git Worktrees Shipping a control plane, an append-only accounting ledger, on-chain payment verification, peer-to-peer transport, and an isolated Docker runtime in a single day with two people required running a fleet of Codex agents in parallel across 18 separate Git worktrees. Instead of letting agents step on each other's files, we split the repository by what each branch could implement and verify independently, tying the worktrees together through shared TypeScript contracts for every payload they exchanged. That let the `provider` branch verify container confinement and model staging, the `transport` branch test encrypted peer connections, and the `registry` branch test lease expiration when a machine drops offline, all running simultaneously without a single merge collision. The buyer's MCP facade was where all those parallel branches had to converge, because a single request crosses discovery, accounting reservations, and peer transport before the provider container ever runs a job. We used deterministic fixtures so the buyer branch could build against the shared contracts while the other worktrees were still moving, then replaced them with integration checks designed to break the handoffs between services. One case captures the real difficulty of distributed execution: the provider finishes running the workload, the buyer loses the connection right before reading the response, and a retry has to recover the original encrypted result and receipt without running the model or charging the buyer twice. ## Beyond Inference: A Paywall for Any MCP Tool For the live test, we connected the four machines we had on the table, and a buyer agent discovered a ready provider on its own, sent `"Say hello in one short sentence"`, and pulled back the output with a `$0` receipt in two seconds. The point of that test was not the five words of text it returned, but what happened underneath a single tool call: autonomous discovery across separate hardware, cryptographic budget verification, an encrypted peer tunnel with zero port forwarding, air-gapped Docker execution, and a settled receipt with no human in the loop. Even though we ran the demo with free providers, the paywall and USDC settlement on Solana are already live, so linking your wallet in the startup flags and setting a price turns your machine into a paid node immediately. We used Macs simply because that was the hardware we brought with us and we pinned a small model to keep the live test fast, but the entire runtime runs on Linux and the model is just a configuration flag, so if you have an NVIDIA DGX or a Mac mini with 128 GB of RAM you can serve heavyweight models by changing one parameter. And more importantly, model inference was only the excuse for the demo, because that exact same pipeline can expose a database, gate access to a private internal system, or serve any software layer for agents while charging per execution transparently, securely, and anonymously. Most people today barely use MCP to wire up local toy scripts on `localhost`, and in a few hours we proved the protocol can run an entire peer-to-peer market of compute and tools without a single data center. # The Verification Cost of Plausible AI Output - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-10-15 - **Canonical URL**: https://carlosrivera.im/blog/the-verification-cost-of-plausible-ai - **Tags**: AI, Engineering > When models stop writing nonsense, catching their mistakes stops being free and starts requiring domain expertise. When language models produced obvious garbage a couple of years ago, checking their work was trivial because anyone who could read could see the sentences made no sense, laugh at the output, and close the tab. You didn't need to know anything about PostgreSQL internals or contract law to realize the machine was hallucinating when the paragraphs were repetitive, broken, and obviously wrong on the surface. ## Where the Errors Live Now Today the models write clean, confident, professional prose, and that completely changes the cost of catching a mistake because the error is buried inside the logic instead of sitting on the grammar. A prompt will return clean code that imports a method that never existed in the library, or cite a regulation that was never passed with a citation that looks entirely legitimate, and the text gives you zero clues because the writing itself is completely fine. To catch that kind of mistake you now have to know the actual domain well enough to recognize the lie on sight, which moves the verification work from anyone who can read to an engineer or a lawyer who charges real money for their time. ## The Non-Expert Illusion This breaks the common pitch that AI lets non-experts do expert work, because handing someone the ability to generate a document does nothing to give them the ability to verify that the document is correct. A founder with no legal background using an LLM to draft an equity agreement is not replacing their lawyer, they are just creating twenty pages of text whose real traps they can't see, and they won't discover the problem until an investor or a court points it out to them. Generating the artifact is the easy part, but knowing whether the artifact will blow up in your face still requires the exact expertise you were trying to avoid paying for. ## Plausible Mistakes Cost More The second mistake is believing this gets cheaper as models improve, when the reality is that smarter models make mistakes that are much harder and more expensive to catch. When an old model broke, it gave you a syntax error you could spot in two seconds, but when a frontier model writes a complex database query with a subtle race condition that only crashes under production traffic, you burn half a day tracing logs to find it. The better the model writes, the more plausible its lies become, and a plausible lie forces you to open documentation, double-check primary sources, and verify every single line manually. ## What You Are Actually Buying When generating text or code costs almost nothing, domain expertise doesn't lose its value, it just moves entirely into knowing when the machine is lying to you before you ship to production. If you can't verify the code or the contract yourself, you aren't working faster, you are just piling up problems you don't understand and hoping someone else doesn't find them first. # The Hardest Part of Zero to One Is Resisting the Urge to Do Too Much - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-10-06 - **Canonical URL**: https://carlosrivera.im/blog/zero-to-one-is-knowing-what-not-to-do - **Tags**: Startups, Product-Market Fit > When you are at zero, the panic reflex is to pile on features, tools, and ads to feel like you are making progress, while the only question that matters is whether you have a working machine. The internet is overflowing with literature on how to raise capital, build automated sales funnels, and scale operations, almost always written by venture funds or late-stage founders thinking about going from ten to one hundred, and for years I swallowed that playbook whole, convincing myself that my core challenge was execution speed when in reality it was commercial discernment. The hardest part of going from zero to one is not figuring out what to do, it is resisting the violent urge to do too much, because whenever something does not work your immediate reflex is almost always to pile more things on top, another feature, another rewrite of the marketing page, another CRM subscription, and the fundamental problem is that the mature company you are copying has already discovered its working machine while you are still trying to figure out if yours even exists. ## Copying Those Who Are Miles Ahead I fell into that exact trap myself early on, burning weeks configuring an enterprise CRM with ten pipeline stages for three prospects who left me on read, designing polished component systems in Figma, and drafting tiered pricing grids with enterprise tiers simply because I saw Stripe or Notion displaying them on their homepage, and the brutal truth is that all that busywork was not about selling more, it was about avoiding sitting down to hear why nobody wanted to buy. Optimizing is not inherently bad at zero to one, because optimizing the speed at which you speak to prospective buyers or compressing the time between an assumption and real-world evidence is the only thing that keeps you solvent, but what is deeply broken is optimizing the distribution machinery for a product you still do not know if anyone actually wants. Mature companies do that because they are tuning an engine that already prints cash; at zero to one, building scale infrastructure is merely an expensive way to hide from market rejection. ## Panic Disguised as Productivity When momentum refuses to appear during the first few months, a founder's brain enters a quiet panic that masquerades as hyper-productivity. If the software is not selling and prospective buyers do not respond, stopping to admit that your core value proposition is unwanted is a painful conversation, so your immediate reflex is almost always to double down on what is already failing, shoving three more features onto the roadmap, redesigning user onboarding for the fourth time, or burning through remaining runway on paid ads to force traffic into a funnel that visitors abandon inside three minutes. That hyperactivity soothes your anxiety for a couple of weeks because it makes you feel intensely occupied, but throwing more noise at an offer that nobody understands will never fix the underlying product, it will only accelerate the exact date you run out of cash. ## Building to Learn Versus Building to Scale People talk endlessly about staying focused on the essentials during early stages, but that advice gets misinterpreted as a command to sit completely still. You still need to test dozens of cheap prototypes in a month to see whether any hypothesis sparks genuine commercial traction, but the critical distinction lies in whether you build them as disposable, reversible experiments to extract market signal or construct them as if you were laying the permanent architecture of the enterprise. If you treat every early experiment as a permanent feature that requires documentation, refactoring, and regression tests, you end up with an unmaintainable codebase that nobody knows how to navigate and that costs you weeks to modify, when your sole objective at zero to one is discarding everything that fails to give you direct evidence about whether someone will pay money to solve their problem. ## The Discomfort of Running Out of Excuses The moment you choose not to write secondary features, stop burning budget on social ads to mask the absence of organic retention, and refuse to hide behind corporate busywork, you are left completely alone with the only question that matters: whether what you are building solves an acute, bleeding emergency for an actual buyer. If you cannot convince ten prospective customers to use a primitive, manual solution that solves an authentic problem by hand, no growth agency, borrowed infrastructure, or outside venture investor will save your company once the money runs out. # You Do Not Find a Cofounder in an Interview - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-09-24 - **Canonical URL**: https://carlosrivera.im/blog/cofounders-are-not-interviewed - **Tags**: Startups > Debating equity splits, corporate titles, and contracts before building anything together is startup theater. Finding a partner is like forming a band: you start jamming to see who can handle the noise. The most absurd ritual in early-stage startups is watching two strangers sit in a coffee shop asking each other corporate interview questions to decide whether to launch a company together, cross-referencing LinkedIn profiles, signing NDAs to protect half-baked concepts, and projecting ten-year visions like they were hiring an executive for a public enterprise, when in reality all they have is an empty Notion page and a near-certain probability of folding within twelve months. We never find a cofounder in a job interview or on a professional networking app; we discover them through the messy friction of real, unglamorous work. The clearest lesson I ever learned on this did not come from an accelerator in San Francisco or an Ivy League business book, but from an interview with the frontman of a large regional band with a dozen musicians sharing the stage, who was asked how on earth they managed to assemble such a synchronized group. His answer was dead simple: they never ran formal auditions, they simply got together in a garage to play, someone would show up and last two weeks before realizing they did not mesh, another would swap instruments, they altered tempos and tested combinations, until eventually they found their distinctive groove and the lineup solidified on its own, leaving on stage only the players who had endured the noise. ## The Trap of the Temporary Organization That insight connected immediately with Steve Blank's classic definition that most founders repeat like scripture without ever understanding what it actually means: a startup is not a smaller version of a large company, but a temporary organization designed to search for a repeatable, scalable business model. Everyone obsesses over the scalable part, the venture rounds, and the fantasy of compounding growth, but almost nobody notices the word temporary, which is precisely the word that explains early-stage volatility. At the beginning you do not have a finished company or an institutional structure to protect; you have an unproven experiment that is barely coalescing, and the people joining that initial phase are not tenured executives with guaranteed seats, they are participants in a chaotic search process where the vast majority will not fit the music that finally gets played. ## The Fear of Being King of an Empty Kingdom I spent years making that exact mistake myself, obsessing over cap table control from day zero and repeatedly falling into what Noam Wasserman defines in *The Founder’s Dilemmas* as the tension between being rich versus being king. I desperately needed world-class operators with complementary skills I completely lacked so the business could scale, yet I clung to total equity control over a project that had zero commercial validation, driven not by raw ambition, but by the paralyzing terror of what would happen if I gave equity away to the wrong partner before knowing who they really were under pressure. ## Jamming Together Instead of Auditioning That is why the musical analogy is so revealing, because finding an operational partner is far more like cramming into a sweaty garage to improvise than posting a job listing on LinkedIn. You have to play with different people, see what creative instincts they bring, observe how they react when a string snaps in the middle of a live set, watch their face when someone misses a chord in front of an audience, and evaluate whether there is natural synchronization when the tempo gets brutal, because someone can possess immaculate technical chops on their instrument and an impressive resume, yet remain completely incapable of spending eight years trapped inside a cramped van on a grueling tour. In a startup, the real music is not played during a polished pitch to angel investors; it plays when production servers crash at three on a Sunday morning, when your largest client terminates their pilot without notice, or when the bank account enters its final four weeks of payroll and you have to see who stays in the room to face the fire. ## Splitting Royalties Before Writing the Chords Most founders manufacture elaborate corporate theater to avoid that underlying vulnerability, burning weeks debating inflated C-suite titles, drawing hypothetical organizational charts, and negotiating fifty-page shareholder agreements before spending a single afternoon working together on a concrete deliverable. We try to decide in advance who gets named the official bassist, who takes the manager title, and how we will divide future streaming royalties before we even know what key we are playing in or whether anyone outside our garage will pay a dollar to listen. ## Less Interviewing and More Noise If you are currently searching for someone to build a venture with, stop scheduling coffee interviews and stop hunting for the mythical perfect partner as if you were shopping from an enterprise catalog. The only evaluation that tells you the truth is compressed, high-friction collaboration: shipping a prototype in ten days, attempting to sell a raw product to skeptical buyers, or untangling an ugly production bug side by side, because working in the trenches strips away executive posturing and exposes who can absorb real operational stress and who was merely infatuated with the romance of being a founder. You do not need to hunt for a cofounder with a contract in hand; you just need to start playing music with more people until the work itself reveals who belongs on the stage. # Folio: From Markdown to a Presentable PDF - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-09-02 - **Canonical URL**: https://carlosrivera.im/blog/folio-markdown-publisher - **Tags**: Folio, Markdown, PDF, MCP, Build in Public > Technical documents don't start in a word processor anymore. They start in Markdown, inside an agent or a working session: architectures, proposals, analyses, reports. Technical documents don't start in a word processor anymore. They start in Markdown, inside an agent or a working session: architectures, proposals, analyses, reports. The problem arrives at the very end, when that text has to become a presentable PDF and the only way out is copying and pasting into a tool designed for another era, fighting overflowing tables, broken code blocks, and formulas exported as blurry screenshots. Folio closes that gap. ## What It Does **True pagination.** The document is laid out in finished physical pages from the start: you see where a table breaks and where an orphaned heading lands before ever hitting export. No infinite scroll surprising you in the final PDF. **Real-time Markdown.** Type or paste Markdown and the document builds instantly, with editorial typography and themes applied without configuration. **Native math and diagrams.** Formulas rendered with KaTeX in vector format (tack-sharp at any zoom or print) and flowcharts drawn directly, without screenshots. **One-click PDF export.** What you see on the page is what lands in the file. ## For Agents, Not Just Humans Folio includes an MCP server that turns the document into something an agent can operate: defining metadata, applying typographic themes, auditing broken links, and exporting the final PDF without human intervention. If the analysis was done by an agent, the delivery can be done by the agent. ## Who It's For - Technical founders and consultants delivering proposals and executive reports. - Engineering teams documenting decisions and architectures. - Anyone working in Markdown who needs to present outside of Markdown. ## Try It [Folio is available here](https://carlosrivera.github.io/folio/). # Infrastructure, Product, and Value: Three Different Things You Treat as One - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-08-17 - **Canonical URL**: https://carlosrivera.im/blog/infrastructure-product-value - **Tags**: Startups, Producto, Infraestructura > Most businesses do not fail from poor product execution; they fail from hiding in infrastructure to avoid market rejection. Customers pay for value, tolerate the product, and never think about your infrastructure. In one of my previous startups, I fell into the exact same trap three times: we rebuilt our entire microservices architecture with pristine automated test coverage while our paying accounts could be counted on the fingers of one hand, burning months of critical runway remodeling the kitchen of a restaurant that had zero patrons sitting in the dining room. If you run a restaurant, the commercial hierarchy is unmistakable: satisfying hunger is the underlying value, the plated dish is the product, and the kitchen equipment is the infrastructure. That exact relationship holds true in enterprise software, local retail, or an airport, yet founders constantly confuse them because all three words get tossed around as interchangeable synonyms in pitch decks. The customer pays for the value, tolerates the product, and never once thinks about your underlying infrastructure, yet founders consistently spend time and capital in precisely the inverted order. ## The Three Layers Value is the only thing that actually exists in any viable enterprise; it is the concrete commercial outcome the buyer purchases, and it is invisible by definition, because nobody buys a gym membership, they buy physical health, nobody buys an airline ticket, they buy arriving safely at a destination, and nobody buys food, they buy no longer being hungry. The product is merely the delivery vehicle for that value, the physical or digital interface the buyer touches and consumes, whether that is the hotel room key, the airline seat, the software dashboard, or the plate placed on the table. The infrastructure is everything required to make the product possible without the customer ever needing to know it exists, including the physical servers, the hotel laundry operations, the airline maintenance logistics, or the commercial kitchen, and its ideal operating state is total invisibility, because the best kitchen in the world is the one that never enters the conversation, as diners talk about the food, not the stove. ## The Inverted Pyramid Infrastructure represents the most seductive comfort zone on earth for operators, not just engineers, because it presents technical problems with deterministic answers that can be benchmarked, measured, and verified without ever rejecting you, as no customer will ever tell you that your new staging environment solves nothing, and while tuning it you feel intensely, professionally occupied. Value, by contrast, is the most excruciating layer in business, because it lives in messy, agonizing conversations with prospective buyers who lie out of politeness to avoid hurting your feelings, in unpredictable sales cycles you cannot control, and in the terrifying possibility of discovering that nobody cares about what you built. So the restaurant owner remodels the kitchen before confirming diner demand, the gym operator purchases expensive imported weights before pre-selling memberships, and the founder architects a massive cloud platform before booking a single prospect call, and all three justify that avoidance as laying foundations when it is actually just purchasing the most expensive hiding place available. ## The Deletion Test If you want to evaluate which layer a specific asset or feature belongs to, there is only one diagnostic question that matters: if this disappeared tomorrow morning, who would notice and how much cash would they pay to get it back? Value is what your customers would panic over losing, the acute hunger that returns when the food fails to arrive, the furious executive emails sent during the first hour of a system outage. The product is what users notice immediately through friction, complaints, and bug tickets, which is the healthiest signal you can receive because it proves an economic buyer relies on your interface to achieve an outcome that matters to them. Infrastructure that nobody asked you to build fails this test completely, because if you delete it from existence, nobody in the physical world notices or cares, as the paying customer never knew it was there in the first place, and if you cannot clearly delineate these three layers within your operations, you do not run a company, you run an expensive hobby with corporate branding. ## Infrastructure Multiplies, It Does Not Create A scrappy operator with a manual spreadsheet and a messaging group can deliver authentic value to dozens of paying accounts every single day by solving an acute pain by hand, while funded startups raise millions of dollars to build immaculate distributed architectures that serve nobody. Infrastructure only multiplies what already exists; it never creates value from thin air, and if you currently possess zero validated commercial value in the market, your infrastructure is merely multiplying zero, with the expensive difference that multiplying zero with Kubernetes clusters and distributed databases burns cash infinitely faster than multiplying it manually. Infrastructure transforms into a durable competitive advantage only when building it is the unavoidable consequence of fulfilling existing demand at an operational scale that is actively breaking your manual systems, never as a prerequisite for winning your first paying customer. The correct sequencing is deliberately unglamorous and that is precisely why so few founders adhere to it: first prove the value even if you must deliver it entirely by hand, like the personal trainer assembling their first ten clients in a public park or the founder patching workflows through Google Sheets, next build the product even if you are embarrassed by how primitive the UI looks, and only then invest in infrastructure when incoming demand is screaming for it. Your responsibility as a founder is not engineering all three layers simultaneously; it is resisting the violent urge to start with the two that feel fun and safe, which is the exact reason so many companies shut down with a spotless kitchen and an empty dining room. # Venture Capital Will Kill You If You Are Not Ready - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-08-10 - **Canonical URL**: https://carlosrivera.im/blog/vc-kills-you-if-not-ready - **Tags**: Venture Capital, Startups, Fundraising > I built three startups and raised institutional capital in every single one, but it took me over ten years and hundreds of thousands of burned dollars to understand the financial game I was actually playing. I built three venture-backed startups and raised institutional capital across every single one of them, but it took me over a decade and hundreds of thousands of burned dollars to grasp what game I was actually playing. In my first company, I raised three hundred thousand dollars, naively assuming that closing the round meant we had already won, so I spent the next twenty-four months hoarding every penny and operating with the timid caution of a corner grocery store, needlessly dragging out the agonizing death of a product that should have folded in six months; I had not grasped that venture capital does not enter your bank account to give you peace of mind, it enters to light the fuse. With the second startup, I made the painful mistake of syndicating capital between Latin American funds and Silicon Valley venture firms, learning the hard way that while both call themselves VC, they play fundamentally incompatible sports: the regional investors demanded that I protect cash flow and hit breakeven every single quarter, while the California funds threatened aggressive dilution unless I tripled our monthly burn to capture market share at all costs. By the third company, we finally managed to reach profitability with paying customers and I believed we had broken the curse, only to run straight into total apathy from my own board of directors, because a solid business generating a couple million dollars a year in revenue is just a rounding error to a fund that requires outlier unicorns to survive. When you accept institutional venture capital, you sign an unspoken contract where you forfeit the right to build the company you actually want, transforming yourself into an operator whose sole purpose is feeding the financial beast their fund model demands to return outside capital. Pouring venture dollars into a company before you possess a validated sales engine does not buy you time to find clarity, it straps you to a burning jet engine that will smash you against a brick wall long before you ever locate the steering wheel. # A Native macOS UI for Beads - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-08-05 - **Canonical URL**: https://carlosrivera.im/blog/agents-as-primary-contributors - **Tags**: AI, Engineering, Build in Public > We keep trying to manage software projects around human workflows while autonomous agents have already taken over the factory floor. For years, I treated Linear as the sacred backbone of our engineering sprints, until a few months ago when I burned three weeks and nearly two thousand dollars in duplicate API calls trying to force an agent swarm to report status updates to project boards designed for human product managers, causing constant merge collisions on git branches and mangling repository history because I stubbornly refused to admit that conventional project management software cannot handle machine velocity. I had to rip out the entire setup, write off the wasted time, and migrate our task orchestration to [Beads](https://github.com/gastownhall/beads) so our agents could operate against their own native graph queue without human friction. That migration forced me to completely discard how we measured engineering velocity, because tickets stopped being assignments that an engineering lead hands out in weekly planning meetings and became the foundational protocol for synchronizing autonomous processes. We abandoned estimating story points based on developer fatigue and began tracking the throughput at which these models chew through tasks in parallel, which immediately proved that managing autonomous software development with interfaces designed for human standup meetings only serves to bottleneck the systems actually doing the heavy lifting. ## The Blindness of Operating Without Telemetry Operating entirely through programmatic queues created an immediate operational blind spot, because I was no longer overseeing a single coding assistant patching an isolated bug, but a full-blown assembly line of agents modifying multiple codebases simultaneously without asking for permission. Because Beads was designed specifically for language models and intentionally lacks a graphical user interface, I spent days staring blindly at raw terminal logs trying to diagnose why an agent had locked up in a circular dependency, which pushed me to build a native desktop application called [Beadle](https://github.com/maquina-la/beadle) to maintain real-time telemetry across the swarm without needing fifteen simultaneous chat sessions. Pretending that human developers remain the primary authors of code across your engineering organization is a nostalgic delusion that yields nothing but pointless standups and fabricated sprint estimates. The factory floor has already changed operators, and teams that fail to rebuild their monitoring infrastructure to manage autonomous systems rather than human schedules will keep burning weeks in sprint planning while their competitors ship continuous production updates without attending a single meeting. # Validation for Founders Who Hate Talking to People - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-05-22 - **Canonical URL**: https://carlosrivera.im/blog/validation-for-introverted-founders - **Tags**: Startups, Product-Market Fit, Mental Health > Building landing pages, running surveys, and tweaking features is rarely real validation; it is usually an elaborate coping mechanism designed to avoid the only uncomfortable task that matters: talking to human beings. As a technical founder diagnosed with social anxiety, validating an early idea felt far less like market research and much more like exposing myself to raw, personal rejection. For years, I convinced myself that finding validation meant designing clever technical workflows to bypass the agonizing discomfort of speaking with strangers, and frankly, the startup ecosystem actively encourages that cowardice by rewarding polished digital artifacts over painful conversations. So I did what engineers do best when panic sets in, which was optimizing the entirely wrong system. I built automated landing pages, ran online surveys, tweaked UI components, pushed endless minor pivots, and measured vanity analytics that moved nothing forward, burning months of runway and market timing that will never come back. The worst part was that I genuinely convinced myself I was working hard, because that exact loop is codified in standard startup literature as disciplined experimentation. It looked like legitimate progress with its dashboards, visitor heatmaps, intake forms, and conversion funnels, all sophisticated enough to disguise the ugly reality that I was performing elaborate mental gymnastics to avoid hearing someone tell me my idea was useless, cheered on by peer founders who were equally terrified of being uncomfortable. When I finally forced myself out into the field to run user interviews, I botched the process just as badly. I asked leading questions structured specifically to fish for polite compliments, scheduled calls with supportive acquaintances who were already primed to tell me what I wanted to hear, and kept conversations on safe, theoretical ground where nobody had to deliver bad news and I never had to suffer an ego check. In the end, that mix of inexperience, fragile pride, and fear simply guaranteed that I burned several more months collecting worthless, polite lies. ## The Brutality of the Real Sale Validation finally clicked for me much later, in the most humiliating way possible: attempting to collect real money for software I had already spent six months building in complete isolation. Locking yourself in a room to write code feels cozy and controllable, but putting a pricing sheet in front of a real buyer and demanding a credit card is an unforgiving reality check. That is the moment they look you in the eyes and tell you that you built complex features nobody asked for, that their previous enthusiasm over email was just corporate politeness to end the call, and that you burned twenty thousand dollars of your personal savings writing software for a problem that kept nobody awake at night. Most technical founders do not fail from poor engineering; they fail because they are exceptionally talented at building sophisticated technical fortresses to dodge the sting of sales, unwilling to face the fact that the market has zero interest in paying for their creation. # AI Does Not Replace Developers, It Changes How Many You Need - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-05-20 - **Canonical URL**: https://carlosrivera.im/blog/the-illusion-of-replacing-developers-with-ai - **Tags**: Engineering, AI > A $200 Claude Code seat will not substitute an engineer, but a small team with modern tools can now ship what previously required ten. The seductive arithmetic peddled at technology conferences claims that if a two-hundred-dollar monthly subscription generates code all day, we can immediately eliminate three senior salaries from payroll and pocket the margin. Anyone on our engineering team who has supported a live financial processing engine at three in the morning understands why that simplistic math breaks down: typing fresh greenfield code has always been the cheapest part of software engineering, while the work that actually consumes developer bandwidth is deciphering undocumented legacy integrations, patching zero-day vulnerabilities, and absorbing the chaotic requirements of the enterprise buyers who pay the bills. Using generative models to inflate code volume without architectural discipline does not eliminate your operational bottleneck, it merely mutates it, transforming your senior engineers into full-time code auditors spending their days deciphering generated syntax and brittle business logic. ## Technical Debt Is Not Solved by Syntax Conceding that reality often leads teams into the opposite mistake, concluding that nothing has changed and that existing engineering head counts remain permanently justified. What artificial intelligence actually replaces is not the software engineer, but the bloated engineering department: the standard, predictable, and well-specified implementation tasks that previously justified recruiting five additional junior developers are now effortlessly absorbed by agent tooling, and that permanently recalculates how many people a serious product requires. A lean unit of two or three senior engineers equipped with modern agent harnesses and deep domain context can now deliver the operational output that previously required ten developers, simply because the bottleneck shifted from mechanical typing to architectural judgment, which never scales through adding head count. ## The Real Economics of AI in the Software Lifecycle The core economic question is not whether a model spits out a REST endpoint faster than a human, but what operational leverage you can purchase in compute before your token consumption invoice begins to compete with the salary of the engineer auditing it. Spending two hundred dollars on Claude Code does not substitute an engineer, but it hands exceptional developers an asymmetrical multiplier that exposes the stark difference between hiring engineers with judgment versus hiring typing hands, a capability gap that has always existed, but is now laid bare over weeks rather than years. In emerging startup ecosystems, this debate becomes almost comical: founders haggle over twenty-dollar developer licenses while cheerfully funding full payrolls for developers who merely type syntax, which is the exact mechanical labor that no longer requires human hands. If your primary economic value as a developer is manually typing what an autonomous model generates in three seconds, the pink slip will find you eventually, whether your management uses AI as the excuse or not; but if your value lies in deciding what to build, architecting resilient systems, and immediately recognizing when the machine is wrong, you were never part of the equation AI was meant to solve. # AI Makes Mediocre Founders More Dangerous - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-05-19 - **Canonical URL**: https://carlosrivera.im/blog/ai-makes-mediocre-founders-more-dangerous - **Tags**: Engineering, Infraestructura > AI did not make building a real startup easier; it just made looking competent drastically cheaper. A little over a year ago, I fell straight into that trap myself: over a single weekend, I generated a polished landing page, wired up three autonomous agents to simulate customer workflows, and assembled an interactive demo that looked like the product of a Series A startup, burning six hundred dollars in frontier API credits to inflate an empty shell nobody had asked for while convincing myself I was an execution genius. That frantic activity was not about validating an idea faster; it was an elaborate defense mechanism to avoid the agony of cold outreach and hearing prospective buyers tell me my software solved nothing. AI did not make building a real business cheaper, it simply made appearing competent effortless, and that makes an unfocused founder significantly more dangerous to themselves and to their cap table. ## The Mockup Nobody Questions In previous cycles, when a foundational thesis lacked genuine market demand, incompetence revealed itself almost immediately because the software looked broken, the interfaces glitched, and sustaining the illusion required burning hundreds of thousands of dollars on a bloated engineering department. Today, anyone with a twenty-dollar subscription can generate an apparent microservices architecture, autonomous agent pipelines, and sleek analytical dashboards in days, deceiving naive angel investors who confuse generated code with execution velocity and accelerators that mistake sheer motion for product-market fit. The danger is not building faster, it is that frictionless prototyping allows you to postpone uncomfortable interrogations about customer retention, acquisition costs, and unit economics for months while constructing a spotless digital facade over commercial emptiness. ## Software Does Not Replace Judgment The truly grueling dimension of launching a company was never typing the initial codebase or formatting sales proposals; those tasks were tedious but predictable. The real barrier has always been uncovering commercial pain that keeps an economic buyer awake at night, grasping the hidden regulatory dynamics of an unglamorous vertical, and pricing your offering high enough to survive once initial launch excitement evaporates. None of that is solved by prompting a model, and when baseline software generation becomes a cheap commodity available to everyone, the only scarce differentiator left is founder judgment: knowing who to call, which feature requests to discard, and when to accept that the market is screaming no. ## What Happens When These Founders Raise Money Confusing synthetic software velocity with real commercial traction carries a bill that the founder rarely pays alone. Operators who use these tools to camouflage an absence of operational depth end up closing funding rounds they never deserved, recruiting engineers to pursue business models they barely understand, and promising enterprise pilots they cannot deliver. The final reckoning never arrives as a sudden philosophical revelation; it lands as catastrophic cohort churn in month two and unpaid cloud invoices in month five. # Accelerators Are Not Looking for a Good Business - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-05-13 - **Canonical URL**: https://carlosrivera.im/blog/accelerators-do-not-want-safe-bets - **Tags**: Infraestructura, Engineering, AI > An accelerator does not invest in sensible companies; it hunts for irrational outliers capable of returning an entire fund. I went through several accelerators, and in one of them I burned three months assembling a forty-tab financial model to prove we could reach two million dollars in revenue with healthy operating margins by year three, assuming the partners would applaud my prudence, only to watch another team with a stalled product secure a one-hundred-and-twenty-five-thousand-dollar check simply because they promised to swallow an entire hypothetical market. That slap in the face taught me a foundational rule nobody mentions during mentorship sessions: venture accelerators are not looking for sensible businesses, they are hunting for statistical anomalies. An accelerator does not want a safe bet or a predictable company that looks neat inside a spreadsheet. They need an irrationally disproportionate bet with an upside violent enough to justify burning cash across the other forty-nine companies in the batch that will shut down within two years, meaning that showing up to pitch meetings hoping to earn an investment because you are responsible, keep costs low, and built software that works is fundamentally misunderstanding the vehicle, because venture capital math is intentionally warped so that a single company carries the entire cohort. ## A Good Business Can Be a Terrible Startup There are phenomenal businesses that should never touch an accelerator. An agency running forty percent net margins, a vertical SaaS collecting three million dollars a year, or an enterprise service firm with locked contracts are real wealth engines, but to a fund portfolio they represent a rounding error. A twenty-million-dollar exit changes a founder's life across Latin America, but on an investment fund's ledger it is just an irrelevant footnote that fails to move the needle for their limited partners. That is why the traditional pitch from cautious founders falls flat. You want to highlight operational discipline as if it were an asset, while partners are calculating whether there is any possible universe where your business becomes completely inevitable and swallows the entire category before running out of runway. ## They Do Not Grade Your Idea, They Grade Your Appetite to Seize the Market An accelerator is not evaluating whether your addressable market looks massive on a pitch deck slide; they are assessing whether you have the commercial aggression required to wrench money away from entrenched incumbents. Claiming a market is worth billions means nothing when buyers already have established vendors, trusted relationships, and multi-year contracts, so your actual job is articulating what lever will force those customers to abandon their current provider before competitors can react. Your team, your distribution engine, and your core product are operational weapons designed to accelerate that market capture. The team proves whether you can iterate faster than slow incumbents, distribution ensures you acquire customers before your bank account drains to zero, and the product dictates whether each new customer deepens your moat or leaves you as an easily disposable commodity. ## One Company Pays for the Entire Batch The coldest reality of demo day is that a single breakout company will pay for the wreckage of everyone else in the cohort. Your objective is not convincing anyone that you can scrape by on razor-thin margins, because barely surviving is completely useless to an asset class engineered around a ninety percent mortality rate. If your company depends on prudence, healthy margins, and avoiding reckless burn, joining an accelerator will not supercharge your trajectory, it will push you to dismantle a viable business just to feed the financial roulette of a fund that only needs one lottery ticket to hit. # Why Agent Runtimes Need Dedicated Infrastructure - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-05-03 - **Canonical URL**: https://carlosrivera.im/blog/agent-runtimes-infrastructure - **Tags**: Infraestructura, Engineering, Startups > LLMs can plan but cannot execute safely on shared systems. Why isolated runtimes are the missing layer for production AI agents. Most artificial intelligence infrastructure is still designed around the premise that a model outputs text and a simple script streams it to a front end, which works fine for customer support demos but immediately breaks down when we instruct an agent to execute irreversible actions like issuing bank wires, calling external APIs, or touching production databases. I learned this the hard way by letting an agent swarm run inside a shared Docker container, convinced that a strict system prompt was enough to keep them contained, until two processes concurrently overwrote shared in-memory state and triggered an unthrottled retry loop that hammered our staging database until someone manually pulled the plug. ## System Prompts Are Not Security Boundaries When an agent interacts with live operating environments, the core engineering challenge stops being a language problem and becomes a resource isolation problem, because if generated code hallucinates or spins into a destructive recursion, no polite reminder in your system prompt will stop it from exhausting host memory or saturating outbound bandwidth. You need disposable runtime sandboxes that tear down in milliseconds without leaving residual state between sessions, you need kernel-level observability to audit which binaries an agent executed before severing the socket, and you need strict CPU and storage ceilings so an unconstrained script cannot bring down adjacent client workloads. Standard Docker containers fall short for this threat model and full virtual machines take far too long to boot, which is why we migrated execution environments to Firecracker microVMs that spin up in under a second with true hardware-level virtualization. Each individual agent invocation boots inside an ephemeral sandbox dedicated to a single task, executes its explicitly authorized tool calls, and is destroyed immediately without any possibility of poisoning the host environment. ## Orchestration Forgives Zero Improvisation Isolating the compute environment only solves half of the architectural challenge, because orchestrating multiple agents that rely on external tools requires deterministic state management so workflows survive network partitions without duplicating external actions. The default shortcut is duct-taping Redis queues to automated retry logic, which only multiplies catastrophic blast radius when an upstream provider returns a 500 error: each automatic retry blindly re-executes side effects that already succeeded, and duplicate customer refunds cannot be fixed by idempotency keys you never implemented. What actually withstands real-world failure is an explicit state machine that records every lifecycle transition before firing external calls, guaranteeing that after an unexpected restart you know precisely what finished and what remains pending. If you are shipping software where autonomous agents execute real-world operations rather than drafting marketing copy, deferring sandboxing means paying for that negligence with the company credit card and your earliest users' data, and the moment you discover that reality is not during a scheduled security audit, it is during an active production incident. # Why Technological Laggards Have the Advantage in AI - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-04-15 - **Canonical URL**: https://carlosrivera.im/blog/laggards-will-inherit-ai - **Tags**: Infraestructura > The unfashionable businesses tech founders wrote off as dead might be the biggest winners of generative AI. Why skipping the last digital transformation is a massive structural advantage. The regional distributors, commodity traders, and logistics operators that we treat with routine condescension, the ones generating fifteen million dollars a year while operating entirely on physical notebooks and chaotic WhatsApp groups, are positioned far better than most venture-backed software startups to capture economic value from artificial intelligence, and the underlying reason is the exact quality we use to dismiss them: they have zero technical legacy to defend. A company operating without a custom ERP, without microservices, and without architectural review committees can deploy an autonomous agent workflow this afternoon, while the enterprise that spent millions building a proprietary monolith requires eighteen months of compliance reviews and refactoring before touching an external API. ## The Curse of Winning the Previous Cycle The corporate winners of the previous cloud transition spent millions of dollars digitizing every internal workflow, migrating infrastructure to managed cloud services, and hiring hundreds of engineers to maintain rigid relational architectures that today act as a ball and chain. When you have burned millions constructing a proprietary enterprise core and employ entire engineering departments dedicated to defending legacy dependencies, you cannot adopt frontier intelligence without navigating endless compliance committees. The underlying technology exists, but organizational inertia paralyzes your execution while an unglamorous competitor who never invested in custom software sidesteps the entire stack and passes you on the outside. ## When You Built Nothing, You Have Nothing to Defend A traditional business whose greatest digital milestone is an unmaintained WordPress marketing site from 2018 enjoys an extraordinary structural advantage, because with zero technical debt to protect, they can deploy agent-native workflows onto completely greenfield terrain without holding architectural summits to debate backwards compatibility with decade-old libraries. What they possess instead is deep, irreplaceable domain intelligence that no startup team can replicate over a weekend: a regional distributor operating for thirty years understands custom border clearance loopholes, regional trucking extortion, and client credit terms better than any founder brandishing an accelerator logo on their landing page. That tacit operational knowledge was previously trapped in filing cabinets and inside the heads of veteran operations managers, but modern language models are now mature enough to structure that operational chaos into automated execution within weeks. ## Custom Software Is No Longer a Barrier to Entry The tired assertion that traditional businesses lack the technical talent required to compete has collapsed, because the engineering barrier to entry was pulverized. You no longer need two hundred software developers on payroll to automate supply chain fulfillment; you merely need to understand business rules with enough clarity to describe them in a prompt and orchestrate tool calls to frontier models. Traditional industries suffer from such glaring operational inefficiencies that automating eighty percent of a manual invoice matching process yields immediate cash flow victories, while software startups continue burning runway debating whether a blue sign-up button increases conversion by half a percentage point. If your investment thesis as a founder hinges on the belief that traditional businesses are simply too slow or unsophisticated to leverage artificial intelligence, you are building on top of a suicidal delusion: while you burn through your runway attempting to educate the market on your new software interface, the unglamorous operator who still prints paper receipts is three automated scripts away from swallowing your margin before you even notice. # Your MVP Is Broken And Coding Faster Will Not Fix It - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-03-05 - **Canonical URL**: https://carlosrivera.im/blog/your-mvp-is-wrong - **Tags**: Venture Capital, Startups, AI > With modern AI, anyone can spin up an application in a weekend, so building fast no longer differentiates you; validating real commercial pain before writing code is all that keeps you solvent. I fell into that exact trap myself during my early ventures: when compiling and deploying software cost tens of thousands of dollars and months of physical server configuration, the minimum viable product acted as an indispensable financial constraint that forced you to painfully choose what to cut, and in that historical era, sheer execution speed was a genuine competitive advantage. Today, anyone can describe an interface to an artificial intelligence coding agent and have a functional application with a managed database and deployed backend running before dinner, meaning the technical barrier has completely collapsed and building fast has ceased to be an advantage, becoming baseline table stakes. I witness the wreckage every single week: founders bragging about launching products over a single weekend without having conducted a single uncomfortable conversation with an economic buyer, and in an unforgiving market where building the wrong thing offers zero second chances, that velocity only accelerates the exact date your bank account reaches zero. ## The MVP Lost Its Meaning Frank Robinson originally coined the concept and Steve Blank and Eric Ries popularized it with a very specific intent: forcing engineering teams to ruthlessly prune non-essential features to verify whether the foundational thesis survived contact with the market before committing further capital. The dogma survived; the historical context did not. With technical barriers on the floor, the MVP ceased to be a discipline that constrains you and mutated into a permission slip: anyone can launch their supposed MVP the very same Thursday the idea popped into their head, without having validated anything, and the methodology originally designed to prevent you from overbuilding now actively encourages you to overbuild. Resisting the reflexive itch to write software until you collect cold cash from an actual customer is the only meaningful discipline that separates a viable commercial company from a weekend toy. ## The Reflex of Blaming Distribution The cycle is brutally predictable: you get excited about an idea in the shower, spend three days generating code with an LLM, push the release link to social media into deafening silence, and immediately convince yourself that the software is fine but you merely suffer from a marketing or positioning challenge. You do not have a distribution problem; you built a product that nobody asked you to build, and using the speed of modern developer tools to bypass market validation is not operational agility, it is merely cheapening the cost of running headfirst into a brick wall. Real customer validation is deeply uncomfortable because it requires sitting down with operations directors to listen to how they currently patch together workflows using spreadsheets, manual copy-pasting, and internal workarounds, without pulling up your product demo or asking for feedback on your designs so they cannot default to polite compliments. Unless an actual prospect is willing to send you an advance deposit or sign a binding pilot contract with a fixed payment date, no level of deployment speed will offset the fact that you are building in a vacuum. Your MVP is broken because you built it to protect yourself from the immediate sting of commercial rejection, not from an absence of features or architectural flaws, and when any model will spit out software in an afternoon, hiding behind a codebase remains the most expensive way to lie to yourself. # Your Technical Interview Is Broken (And Evaluating Things from 2015) - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2026-02-10 - **Canonical URL**: https://carlosrivera.im/blog/technical-interviews-broken - **Tags**: Infraestructura, AI, Startups > Forcing candidates to invert binary trees on a whiteboard used to have a purpose. Today it merely tests the wrong skills. What actually matters in technical hiring. We burned months of senior engineering time across sixty whiteboard coding loops before we admitted that when you force a candidate to implement a linked list or traverse a graph on a whiteboard, you are not evaluating whether that engineer can architect resilient production infrastructure, you are testing whether they had enough leisure time to memorize textbook puzzles they will never touch in their daily work. Meanwhile, that exact evaluation framework is fundamentally incapable of determining whether a candidate understands distributed architecture trade-offs, knows how to diagnose a deadlocked cluster under heavy traffic, or possesses the judgment to audit code that a language model generates in three seconds. Burning hundreds of engineering hours on whiteboard interviews buys you precisely that failure mode: rejecting seasoned veterans who cannot recall esoteric syntax offhand, while hiring candidates who memorized algorithm tricks but freeze when a memory leak crashes a production container. ## What Engineering Teams Value Now The engineers genuinely worth hiring are the operators who can decompose an ambiguous business problem into decoupled modules and identify architectural bottlenecks before typing a single line of implementation, prioritizing system maintainability far above raw syntax generation. Anyone can implement a red-black tree, or prompt a frontier model to scaffold one in seconds, but very few developers can recognize when that structure is the completely wrong architectural choice for the problem directly in front of them. That is why it makes complete sense to present candidates with genuine code from your production repositories and allow them to use AI tools throughout the interview, because banning language models evaluates candidates for an engineering reality that ceased to exist years ago. What you want to observe is whether they formulate the right questions, establish rigid test invariants, and immediately detect when the model outputs flawed logic, which provides far more predictive signal than watching someone sweat over the syntax of a priority queue. ## Judgment Over Rote Memory If you still administer traditional LeetCode gauntlets, you are selecting for interview performance theater while filtering out exceptional senior engineers who can debug distributed network partitions in their sleep but have not implemented a binary search by hand since university. The strongest engineering leads you could hire today would likely struggle with a timed algorithmic puzzle, yet run rings around competitive programmers when debating operational reliability and fault tolerance in a real systems design conversation. You need to stop evaluating mechanical recall and start assessing architectural judgment, because the engineers who will dominate the next decade are the ones who look at complex, messy systems and skillfully orchestrate modern tools to improve them. If your recruiting pipeline cannot identify those engineers, your hiring pipeline is the bug, and every week you leave it untouched you are trading exceptional talent for legacy interview rituals that measure nothing. # If AI Builds Your Code, AI Can Break It - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2025-12-02 - **Canonical URL**: https://carlosrivera.im/blog/ai-builds-ai-breaks - **Tags**: Infraestructura, Venture Capital > Attackers run autonomous models to uncover zero-days at machine velocity. If your security team still operates at human speed, you are completely defenseless. The hard truth nobody wants to admit in cybersecurity steering committees is that the exact same machine intelligence accelerating our engineering sprints is also generating the exploits to dismantle them, with the painful difference that an attacker does not need to submit procurement tickets or pass compliance reviews before pointing their model swarm at our production clusters. ## The Collapse of Defensive Physics Software development used to rely on a predictable equilibrium where skilled developers wrote code, senior peers reviewed pull requests to catch glaring vulnerabilities, and staging environments deployed on fixed schedules, playing an orderly cat-and-mouse game where both attackers and defenders operated strictly at biological speed. Modern language models shattered that equilibrium for good, because any motivated adversary now commands autonomous agent swarms capable of scanning millions of lines of source code in seconds to uncover race conditions, memory leaks, and complex logic flaws that would take a human penetration tester an entire month to isolate, systematically generating exploit payloads that hammer one attack vector after another while your on-call rotation is asleep. ## Expanding Your Own Attack Surface Handing an entire repository to an offensive security model extracts exploitable flaws faster than any traditional forty-thousand-dollar compliance audit, and that exposure expands exponentially when your own engineering team leverages AI to triple the volume of unvetted code pushed to production every single sprint. Social engineering has similarly evolved far beyond suspicious phishing emails with broken grammar into hyper-targeted spear-phishing campaigns that flawlessly replicate your CTO's tone of voice, referencing genuine internal dependencies and vendor relationships synthesized from public repositories and employee LinkedIn profiles, instantly neutralizing standard spam filters. ## The Corporate Double Standard The most reckless contradiction across modern tech companies is the asymmetry with which leadership allocates capital, cheerfully purchasing unlimited frontier model seats so product managers can ship features three times faster while forcing internal security teams to triage alerts inside spreadsheets and manual scripts. Engineering receives a continuous deployment pipeline that multiplies your attack surface every hour, while security receives an ornamental dashboard nobody has time to monitor, guaranteeing that when the breach eventually happens, nobody will even understand how the perimeter was compromised. Relying on manual review processes when adversaries operate at machine speed is not cautious conservatism, it is negligence that will cost you your entire business the moment someone decides to point an automated harness at your production servers. # The Cheapest Engineer Costs $200 - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2025-10-07 - **Canonical URL**: https://carlosrivera.im/blog/200-dollars-cheapest-engineer - **Tags**: Venture Capital, Engineering, Startups > Senior engineering salaries sit in top regional percentiles, yet developers freeze at the thought of spending $200 a month on frontier AI tools that multiply their delivery capacity. Across Latin America, software engineers earn salaries that place them in the highest income percentiles of their countries, far above most surrounding professionals, yet freeze at the idea of paying two hundred dollars a month for frontier AI tools that multiply their operational output. The irony is unmistakable: we spend our careers billing premium rates for the software we deliver to foreign companies, but the second we have to pay out of pocket for the tools we consume ourselves, our immediate reflex is to look for free YouTube tutorials, settle for crippled tiers, or spend all weekend configuring local models on an overheating laptop just to avoid parting with a single dollar. Meanwhile, engineering teams in San Francisco or London allocate compute budgets and frontier tokens without debate, orchestrating three or four agents in parallel to automate massive refactors. Competing against that by typing syntax by hand leaves you targeting the same international rates with a fraction of the velocity, complaining that twenty dollars for an API subscription is an unreasonable expense while pulling in six thousand dollars a month. ## The Open Source Illusion The standard defense from developers who refuse to pay is that open-source models are good enough and that running them locally protects technical independence. That is a convenient rationalization used to dodge the discomfort of investing in your own craft: open models are impressive, but running them yourself burns hours of maintenance and hardware troubleshooting, and for complex engineering tasks the capability gap against commercial frontier models remains unmistakable. You end up with a sluggish laptop, an expanding backlog, and the hollow pride of not having paid anyone. In a global market that measures engineers by how fast they turn an idea into production software without breaking the underlying architecture, saving a tiny fraction of your monthly paycheck to use second-tier tooling is not fiscal discipline, it is buying the most expensive handicap available. Teams that treat frontier models as an optional luxury will not disappear overnight; they will simply erode, first losing contracts to faster peers, then losing clients who demand rapid iteration, and eventually losing their jobs without any single dramatic event to blame. # The IDE Is Dead And Your Resistance Is Obvious - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2025-08-05 - **Canonical URL**: https://carlosrivera.im/blog/ide-is-dead - **Tags**: Startups > Software engineers cling to code editors like life rafts when the ship has already sailed. Why resistance to AI tooling is an identity crisis disguised as technical rigor. I fell into that exact trap of artisanal vanity myself, wasting three full days hand-coding an orchestration layer because I felt that unless I typed every single interface myself I was not a legitimate engineer, when in reality I already understood the underlying system architecture perfectly and was merely retreating into the comfort of my keyboard to dodge harder commercial decisions. I witness that exact insecurity during conversations with senior developers who squirm in their chairs whenever you ask which AI agents they run, arrogantly claiming that Copilot only spits out unmaintainable garbage or that they type faster than automated completions, completely ignoring that the issue was never how quickly your fingers travel across mechanical switches, but the paralyzing dread of admitting that the mechanical skill that funded your lifestyle for the last decade is no longer scarce. ## The IDE Was Always a Crutch Let us be completely honest about what an integrated development environment has always been: a sophisticated text editor engineered to manage the awkward clumsiness of human handwriting. Syntax highlighting, API autocomplete, complex keybindings, and interactive debuggers exist solely because manual typing is error-prone, tedious, and fundamentally fails to scale, meaning that an editor never made you a deeper system thinker, it merely kept you from tripping over your own typos. Clinging to the traditional IDE when automated agent harnesses can resolve implementation details in seconds is not defending craftsmanship, it is confusing the vehicle with the destination. ## The Panic of Losing Identity For the majority of developers, typing syntax onto a screen is not merely a job; it constitutes their entire professional identity. When you show them that an autonomous model can structure a repository faster and with far less friction, they do not see an operational leverage multiplier, they see an existential threat to their ego. That is why they immediately retreat into predictable defenses, asserting that machines cannot understand business context, as if they understood that context during their first week without asking ten questions or reading internal documentation, or complaining that generated code produces bugs, as if their colleagues' pull requests were not already riddled with sloppy hacks. None of these objections are about software quality; they are exclusively about protecting a daily ritual that keeps them feeling indispensable as long as their fingers stay occupied. ## Directing Instead of Typing The most formidable engineers I know stopped romanticizing the physical act of typing code years ago and recognized that their true value lies in evaluating system trade-offs, anticipating performance bottlenecks, and designing robust domain logic before touching a single key. Burning mental cycles trying to recall regular expression syntax or writing boilerplate REST endpoints for the thousandth time is a grotesque waste of cognitive capacity in a world where natural language has become the primary execution interface. The leverage was never in typing the semicolons; we simply pretended it was because lines of code were the easiest vanity metric to measure on an engineering dashboard. ## The End of the Artisan This transition will not eliminate software engineering; it will eliminate the romantic fantasy of the untouchable programming artisan. The optimizing compiler eliminated the necessity of typing raw assembly, modern frameworks buried low-level memory allocation, and now autonomous agents are absorbing the repetitive implementation work that kept most engineering departments occupied. Developers who stubbornly insist on handcrafting every line will not preserve any noble standard of technical purity; they will simply become entirely too slow and far too expensive for a market that cares nothing about how much sweat you poured into the keyboard, only whether you solved the problem before the company ran out of money. # I Do Not Write Code Anymore, I Build the Systems That Do - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2025-06-08 - **Canonical URL**: https://carlosrivera.im/blog/code-writes-itself - **Tags**: Venture Capital > From typing every semicolon to designing the sandboxed infrastructure where code generates itself. How engineering work changed for good. I started programming at fourteen in raw C++, managing pointers manually and convincing myself I was an indispensable craftsman because I knew how to debug with print statements at three in the morning, and just recently I burned three weeks and two thousand dollars in compute hours hunting a concurrency bug that a well-constrained agent would have isolated in ten minutes, driven purely by the childish vanity of wanting to type every line by hand so the achievement felt like mine. I am thirty-seven years old, I still write software every single day, and it took me entirely too long to admit that much of what we glorified as engineering rigor was nothing more than emotional resistance to letting go of the keyboard. ## The Inertia of the Typist For decades, our industry sold us the narrative that an engineer's value lies in translating abstract business intentions into executable syntax, sitting in front of a monitor to architect algorithms and key in implementations as if finger velocity across mechanical keycaps were a durable competitive moat. We engineered bloated IDEs, strict linters, and endless frameworks to optimize that loop, but the underlying assumption never changed: a human hunched over an editor dropping instructions line by line while everyone applauded the mechanical discipline of the typist. The fundamental shift underway has nothing to do with using autocomplete extensions to finish boilerplate functions faster; it requires accepting that the manual task of writing code no longer belongs to you, and that the real work now consists of architecting the sandbox where code generates itself. Working with autonomous agents means you first define service intent, such as handling payment webhooks, validating incoming schemas, and enqueueing retry queues, then let the model generate the implementation alongside integration suites, leaving your sole responsibility as enforcing rigid constraints to evaluate whether that output respects system architecture without crashing production databases. ## The Cost of Clinging to Syntax In my day-to-day routine, I spend almost all of my time building isolation infrastructure rather than opening application files, dictating which APIs an agent can touch, which egress routes are blocked, and which watchdog process will instantly terminate a run if it spirals into an infinite token loop. Agents generate business logic at a laughable marginal cost, and my responsibility is constructing the containment rails so that raw generation does not poison client environments. Most of what we mastered over twenty years through trial and error, from configuring REST endpoints to writing standard SQL migrations and authentication boilerplate, is now resolved by a machine in three seconds without demanding salary raises or complaining about legacy documentation. The only un-automatable skill left is high-judgment decision-making: knowing which architectural trade-offs are worth taking, anticipating catastrophic failure modes that cost you customers in past ventures, and enduring the profound discomfort of not authoring every single line in the repository. If your primary justification for commanding a senior engineering salary remains that you type elegant abstractions or memorized library signatures, your moat has already expired even if your employer takes another twelve months to realize it. There are no participation trophies for developers who insist on typing by hand what automated infrastructure delivers for ten cents, only the silent irrelevance awaiting those who mistook assembly-line typing for durable technical leverage. # The Company Is Still Alive And That Is The Problem - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2025-03-25 - **Canonical URL**: https://carlosrivera.im/blog/when-growth-flattens - **Tags**: Venture Capital, Startups > Growth flattens long before you are ready to accept it. Shutting down a company with revenue hurts far more than shutting down a flat failure because it feels like killing something that breathes. I kept a zombie startup alive for twenty-two extra months generating one hundred thousand dollars a month in revenue, collecting just enough to cover the payroll of fourteen engineers while pretending in every single board meeting that our next enterprise integration was about to change our fate, when deep down I knew the market ceiling had already crushed us. I refused to shut it down because incoming revenue functions as moral anesthesia: as long as wire transfers clear and invoices go out, any founder can fabricate a respectable narrative to avoid looking in the mirror and admitting they are pedaling a stationary bicycle. The cruelest startup is not the one that explodes in flames during year one, it is the one that breathes just enough oxygen to keep you trapped without ever offering a penny of upside. The growth curve did not crater off a cliff; it simply flattened into a horizontal plateau that reminded us every Monday morning that we were no longer on track to build the rocket ship promised during the seed round. At first, you explain it away with seasonality, prolonged enterprise sales cycles, or a critical contract bottlenecked in legal review, and those excuses work because they allow the board to defer the uncomfortable conversation for another quarter; but by the third consecutive quarter, the spreadsheet stops negotiating with you and you realize you stopped reporting operational reality to start defending an active fiction simply because you are terrified of disappointing the people who quit their jobs to join you. ## Revenue as Moral Anesthesia If the company had zero traction, turning off the lights would be a standard administrative chore resolved in a week, but recurring revenue pollutes your judgment and locks you in a toxic ethical trap. You have active customers who depend on your software to run their daily operations, you have loyal employees who rely on that payroll to pay their mortgages, and you have early investors who can still highlight the chart in their annual updates to claim the company is alive, making your business an operational success in the real economy while remaining a completely broken financial vehicle for the expectations of venture capital. Raising venture money binds you to a mathematical model that requires a disproportionate monopoly capable of returning the entire fund, meaning that growing eight percent a year in a fragmented market is functionally identical to a slow death sentence. The capitalization table does not care that your users compliment your support team or that your engineers work twelve-hour days; once the acceleration of your revenue disappears, staying alive ceases to be a virtue and becomes your central structural problem. ## The Cowardice of Leaving the Servers On Shutting down a company without customers is accepting a statistic, but shutting down a company with revenue demands the deliberate decision to kill something that actively exists in the physical world. You are turning off an engine that resolves support tickets, maintains internal team rituals, and consumed years of honest effort, which is why your hands shake when it comes time to call the emergency shareholder meeting. You inevitably prefer to buy six more months of patience, lay off two marketers to hire another account executive, and convince yourself that a cosmetic pivot will somehow suspend the laws of economic gravity. Those six extra months inevitably bleed into three years of silent exhaustion where the business absorbs just enough revenue to avoid dying while never generating enough velocity to take off. Keeping a zombie company on life support just because it invoices enough cash to cover payroll is not operational resilience, it is cowardice dressed up as loyalty: you are robbing yourself of your best productive years just to avoid sitting down with your team to tell them the unvarnished truth, and the market will never refund you that lost time once you finally get tired of pretending. # Founders Do Not Have a Portfolio - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2024-11-18 - **Canonical URL**: https://carlosrivera.im/blog/fail-faster-because-founders-fail-hard - **Tags**: Startups > Investors can diversify. Founders cannot. When a startup dies, it takes years of life, personal savings, identity, and mental health with it; that changes the math. Venture investors love modern portfolio theory because the mathematical power law allows them to absorb catastrophe effortlessly, letting a single outlier payoff quietly subsidize the graveyard of forty failed bets, but those of us who actually found companies have no such safety net. I learned this the most humiliating way possible when I dragged an unviable company along for twenty-four extra months, burning tens of thousands of dollars of my personal savings and pretending in every board meeting that our next product release would unlock breakout growth, when deep down I was just deferring the agony of admitting we had crashed. To an investment fund, a write-off is just a crossed-out line on a quarterly slide; to a founder, it means returning home with wiped-out net worth to explain to your family that the last three years of exhaustion yielded nothing. ## Risk Concentration Is Absurd The financial risk profile of launching a company is completely irrational from a traditional asset perspective, because your current income comes from the business, your entire net worth is locked in that illiquid equity, your social circles revolve around company progress, and your physical health acts as the only shock absorber taking the hit. Rational finance demands diversifying risk across multiple income streams, funding index funds, protecting eight hours of sleep, and constructing a life that does not hinge on an illiquid line item on a cap table paying out seven years later, but startup culture demands the exact opposite, celebrating blind sacrifice and pushing you to bleed for the vision. Sometimes that pathological stubbornness is necessary to pull something out of nothing, but in most cases it is just a socially celebrated mechanism for self-destruction to prop up outside metrics. ## Failing Slowly Costs More Than Burned Capital When a startup fails, the financial accounting logs half a million dollars of incinerated venture cash, but that is never the actual cost of defeat. The true price is the prime years of vital energy you can never get back, the technical skills that atrophied while nursing a zombie business, the personal relationships fractured by perpetual anxiety, and the talented employees who froze their professional careers because you lacked the courage to look them in the eyes and admit the bet was lost. Failing slowly is not a sudden, dramatic explosion; it is a creeping asphyxiation that systematically robs you of cash reserves, friends, creative clarity, and optionality, leaving you with a mountain of sunk costs and an exhaustion so absolute that by the time the company finally liquidates, it has extracted far more than it ever had the right to take. ## The Luxury of Investor Patience Venture funds will almost always encourage you to grind it out for another two quarters, not necessarily out of malice, but because their financial incentives are completely orthogonal to yours. For an institutional backer, asking you to prolong the agony for another six months is purchasing a free financial call option on your back, waiting to see if an acquisition miraculously appears or if you manage to close a bridge round through sheer desperation, because their downside was capped at zero months ago while for you those six months mean exhausting your final emergency reserves, shattering your personal life, and crossing the burn-out threshold where you never build again. The investor can comfortably afford patience because they have twelve other bets running in parallel; you are sitting in a single chair. ## The Theater of Conviction The worst boardroom dynamics survive on synchronized theater where everyone projects unwavering conviction, repeating that the market is just about to mature, that the next enterprise integration will unlock sales, or that you just need a bridge loan to cross the chasm, when the unvarnished reality is that everyone in the room is terrified of confronting the real numbers. If you need to know whether your business still has a pulse, do not listen to polite applause from your board and do not seek comfort on social media; sit down with an operator who holds zero equity in your cap table and answer one blunt question: if this company belonged to a stranger and was handed to you today with these exact metrics, would you invest a single dollar of your own money? ## Walking Away While You Still Have a Pulse A toxic startup dogma romanticizes persistence at any human cost and frames shutting down a business as moral cowardice, pressuring founders to parade a corporate corpse for years just to look resilient to the tech ecosystem. Your only authentic duty when a business has hit a wall is returning whatever capital remains, liquidating the team with dignity so they can land at healthy companies, telling the truth without sugarcoating, and stepping away from the table before it completely consumes you. Shutting down is ugly, leaves public scars, and costs an immense emotional toll, but in a game where you do not have a portfolio to absorb the hit, the only operational skill that guarantees you can play again in the future is knowing when to stand up from the table while you are still alive. # Your UI Is Not a Corporate Brochure - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2024-06-10 - **Canonical URL**: https://carlosrivera.im/blog/ui-is-not-graphic-design - **Tags**: Infraestructura > Treating UI and UX design like graphic design makes the product look polished while the business stays lost. Interface decisions are survival decisions. In a previous startup, I burned eight thousand dollars hiring an external agency to completely redesign the dashboard of a software platform used by barely four active clients, convincing myself that if the metrics had drop shadows and Swiss typography we would suddenly close enterprise accounts. We spent two full months debating hex color palettes in Figma while our cash runway evaporated, and when we finally shipped the redesign, not a single existing customer renewed their subscription: the issue was never an unappealing interface, the issue was that our software solved nothing urgent, and cosmetically polishing the UI was merely my cowardly retreat from picking up the phone to sell. I still see that exact denial play out among founders who treat interface design like commissioning a corporate brochure, copying the visual minimalism of Linear or Stripe under the delusion that clean typography will compel a chief financial officer to sign an annual contract. The cold reality is that an immaculate dashboard cannot manufacture enterprise budgets out of thin air, and smooth micro-animations will never fix the reality that nobody understands what value your product delivers. A user interface is not decorative styling or aesthetic vibes; it is your commercial argument rendered visible on glass, and if that core thesis is flawed or fails to relieve acute commercial pain, polishing it merely yields an expensive lie with superior graphic design. ## Aesthetics Camouflage Stalled Progress There is an immensely seductive inflection point in early startups when the product finally begins to look professional, because that is the exact moment everyone relaxes. Investors nod approvingly on quarterly calls, the engineering team feels proud, screenshots look compelling in investor pitch decks, and company demos finally stop feeling embarrassing. None of that means you are a single millimeter closer to unlocking true product-market fit. A beautiful interface often makes a confused product significantly harder to diagnose, because users stop complaining about obvious visual friction and begin failing silently within the workflow. They click around, encounter zero authentic utility, and politely close the browser tab without providing feedback. You never receive the loud, visceral customer rejection required to correct course; you receive total deafening silence, and that silence is lethal because it allows your team to keep embellishing useless screens while learning nothing about the customers you are bleeding. ## The Interface Exposes Product Conviction Every layout decision you make exposes an unvarnished opinion regarding your business. Whatever you place at the very top of the viewport reveals what you believe matters first, what you bind to a hotkey is what you assume happens repeatedly, what you bury in settings represents what you dismiss as an edge case, and whatever action you measure downstream of the click is how you define enterprise success. If those foundational opinions are wrong, your product is publicly flawed. That is why disciplined interface work feels deeply uncomfortable, because it forces the entire company to stop hiding behind vague corporate slogans: claiming that customers need visibility is a cheap cop-out until you are forced to define visibility of what, for whom, at what precise operational moment, before which high-stakes decision, and with what exact financial consequence if the user makes an error, and the moment you operate at that level of specificity, you are no longer talking about graphic design, you are finally debating product. ## Design Reviews Are Corporate Theater The overwhelming majority of internal design reviews are entirely too polite and risk-averse. Team members critique pixel padding because debating white space carries zero personal risk, they argue over color gradients because palettes belong to nobody, and they claim a screen feels cluttered simply because they lack the courage to say they have no idea why that screen exists in the first place. The only diagnostic question that matters in a design review is brutal: what specific real-world customer behavior is this screen engineered to change? If nobody in the room can articulate that answer clearly, the screen is not ready for implementation; its underlying conceptual product thinking is pure mush regardless of how polished the visual layout looks. In the past, I wasted embarrassing sums of money making conceptual mush look premium, only to discover that prospective buyers cared nothing about our aesthetic polish and that all we had accomplished was manufacturing prettier screenshots to deceive angel investors in our next pitch deck. ## Design Is an Instrument of Product-Market Fit, Not a Disguise Meaningful product design behaves far more like invasive surgery than decorative art. It means moving a mission-critical action straight to the primary view because that is where customer value actually crystallizes, ripping out an entire analytics table because nobody makes operational decisions based on it, or splitting a user flow because you were forcing two distinct personas with conflicting jobs through the exact same narrow workflow. It means renaming core entities because customers will never speak your internal engineering jargon, introducing intentional friction where an erroneous transaction carries catastrophic costs, and removing friction where an extraneous input kills user activation. That is design operating as an engine of commercial survival. Good taste matters because it generates baseline trust and signals that the software is maintained by competent creators, but good taste without ruthless product judgment is merely expensive makeup. The question must never be whether a screen looks aesthetically pleasing; the question is whether it enables the right user to execute the right high-stakes decision faster and with greater conviction, repeatedly until the software becomes an indispensable utility in their operating life. Graphic design might convince someone to inspect your marketing landing page, but product design has to force an economic buyer to pull out a credit card and act, and if your interface fails to alter customer behavior, it is not moving your business forward, it is merely ensuring that your eventual bankruptcy looks visually refined in your portfolio archives. # Raising Capital in LATAM vs. the US: Two Different Planets and the Nightmare of Living on Both - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2024-01-15 - **Canonical URL**: https://carlosrivera.im/blog/raising-latam-vs-us - **Tags**: Infraestructura > Risk tolerance, legal covenants, and growth expectations differ wildly across borders. Straddling both ecosystems gives you twice the operational headaches. During one of my fundraising rounds, I burned nearly six months chasing three local venture funds that demanded five-year financial models and itemized accounting audits only to deliver an insulting two-hundred-thousand-dollar term sheet loaded with toxic liquidation preferences, while a Silicon Valley fund wired a half-million-dollar SAFE note following two fifteen-minute Zoom calls. I fell into the naive trap of assuming capital is fungible regardless of geography, but raising venture money in Latin America versus the United States involves two completely incompatible games played on mutually repulsive planets. The narrative that wins a term sheet in San Francisco generates patronizing smirks inside a corporate boardroom in Mexico City, just as the conservative, cash-flow-obsessed posture that thrills investment committees in Bogotá makes California partners wonder why on earth you are seeking venture risk capital if your primary obsession is avoiding downside. The dangerous failure mode occurs when regional founders binge Y Combinator demo day videos, memorize Silicon Valley rhetoric, and blindly assume their local economic physics will behave the same. It does not: an enterprise client in Mexico will take ninety days to clear an approved invoice after demanding physical notary stamps, your local fund will require six months of investment committees to issue a hesitant soft-commit, and your ultimate acquisition market is an agonizingly narrow alleyway where almost nobody buys tech startups. Confusing these two realities does not merely burn months of vital founder energy; it locks your company into an operational purgatory that most early cap tables cannot survive. ## Local Funds Are Terrified of Downside This is the harshest reality check for operators who consume too much venture media. Venture capital in the United States runs on the mathematical reality of funding dozens of high-risk bets where forty-five will fail completely but two or three massive winners will return the entire fund multiple times over. In Latin America that power law collapses because local fund sizes are tiny, outlier liquidity events are statistical anomalies, and fund managers are structurally forced to operate conservatively to avoid wiping out the principal of their conservative family office limited partners. A local fund will demand audited recurring revenue today, and if you explain that you are pre-revenue chasing a massive greenfield opportunity, the meeting dies before the coffee cools down. They will ask for signed enterprise contracts and cash in the bank rather than letters of intent, hunting for an immediate, predictable path to breakeven because the only question partners are silently asking themselves is how to recover their principal if you fail to become a dominant regional monopoly. ## The Absurd Due Diligence Marathon In the United States, early-stage due diligence rarely stretches past two weeks because investors are backing team velocity and the magnitude of the problem, fully aware that auditing an early-stage company that consists of code and raw traction is an exercise in futility. In Latin America, due diligence drags on for three to six months, mutating into a forensic accounting interrogation requiring apostilled corporate deeds, tax compliance certificates, and bank statements dating back to the day the entity was formed. That institutional paranoia paralyzes operational momentum. You cannot hire senior technical leadership or deploy growth capital while waiting for an outside law firm to confirm whether an independent contractor submitted a proper withholding tax receipt two years ago, while your competitor in California closed their round in three weeks and is devouring the market while you are still answering interrogatories from a junior analyst. ## The Cross-Border Hybrid Monster If you manage the feat of syndicating capital from both markets, your prize is entering a bureaucratic maze that drains the life out of any founding team. You are forced to execute the standard Delaware flip where an American C-Corp owns an operational subsidiary in Mexico or Colombia, creating a cross-border legal monstrosity that drains tens of thousands of dollars annually in legal fees and tax accounting to reconcile two reporting structures that do not communicate with each other. The deepest fracture occurs at the board level. On one side of the table sits your American investor demanding that you triple your burn rate to capture category dominance before the Series A, while on the other side sits your regional fund demanding that you freeze hiring to protect cash flow. You find yourself serving two masters with diametrically opposed definitions of success, pulling the company in opposite directions during every single board review. If you attempt to satisfy both simultaneously, you will not build an international breakout; you will end up running a schizophrenic company that incinerates its remaining runway explaining to a San Francisco investor why local tax authorities froze your VAT refund while promising operational breakeven to a local fund that panics every time you hire another engineer. # Liquidation Preferences: Why a $10 Million Exit Can Leave You With Zero - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2023-11-12 - **Canonical URL**: https://carlosrivera.im/blog/liquidity-preferences-small-exits - **Tags**: Startups, Engineering, Infraestructura > Venture capital runs on ruthless mathematical mechanics that founders ignore until it is too late. How liquidation preferences can wipe out your equity overnight. In one of my previous startups, I signed a bridge financing note carrying a 1.5x participating liquidation preference because I was desperate to make payroll and convinced myself that a moderate exit would leave everyone comfortably rewarded, only to discover years later during a twelve-million-dollar acquisition offer that between the stacked preference waterfall and the investors' double-dipping rights, I was walking away with less than eighty thousand dollars before taxes for five years of eighty-hour workweeks. Most founders across Latin America celebrate a ten or fifteen-million-dollar buyout as if they hit the jackpot, completely oblivious to the fact that venture capital mechanics are engineered to insulate investor principal long before you ever see a single cent in your personal bank account. Liquidation preferences represent the most lethal covenant on a term sheet because they dictate the strict seniority of payout distributions, and in any acquisition scenario short of hundreds of millions of dollars, institutional investors will devour the entire transaction proceeds. I have watched talented founders sacrifice their physical health, drain personal savings, and forfeit family stability for an acquisition that turned out to be nothing more than an asset transfer directly to outside funds, leaving the operators empty-handed with nothing to show for it but a patronizing pat on the back for their effort. ## The Mathematics of 1x and Beyond On paper, a standard 1x non-participating preference sounds reasonable because outside investors merely want their principal back before you touch the upside, but the trap triggers when financing rounds stack on top of each other and preferences convert into participating structures or spike to 2x and 3x during bridge rounds. When you accept participating equity, the investor claws back their entire invested capital first and then double-dips into the remaining proceeds alongside common shareholders, which acts as a legalized wealth transfer that completely erodes your financial incentive to sell for anything less than an astronomical valuation. This structural waterfall engineers a catastrophic misalignment of incentives because your institutional investors would genuinely prefer that your business crash in flames attempting to become an elusive unicorn rather than sell for a respectable fifteen million dollars where they recover their cash while you become financially independent. They are hunting for fund-returning home runs and you are merely one turn at bat, so if an exit fails to move the needle on their portfolio returns, they care nothing about whether you walk away with zero to your name. ## The Invisible Tax of Inflated Valuations Many founders accept aggressive preference terms purely to announce vanity valuations in press releases, but an inflated valuation is an invisible senior debt obligation that must be repaid before common equity realizes real cash. If your company is priced at fifty million dollars on paper but only builds enough enterprise traction to sell for fifteen million, the investor who injected ten million dollars with seniority rights will absorb almost the entire exit, leaving you holding an empty bag after working years to deliver a mediocre return to an investor who never worked a day inside your operations. You must be brutally honest with yourself regarding the market you operate in and the statistical likelihood of an outlier exit, because optimizing for valuation headlines instead of clean capital structures is the fastest path to becoming a glorified salaried employee of your own cap table. You are infinitely better off owning a smaller percentage of a clean, unencumbered company than holding a massive paper stake in an enterprise that requires a billion-dollar liquidity event just for you to afford a house. ## Defending Yourself Before You Sign The only defense against this trap is fighting for clean terms from day one, understanding that every single dollar you raise is a senior financial claim on your future physical and mental labor, capping preferences at 1x non-participating as a mandatory constraint, and having the courage to walk away from funds that demand toxic debt covenants. Equity is only genuine wealth if it translates into liquid cash, and liquidation preferences are the financial sieve that dictates whether that cash lands in your bank account or transfers straight to someone else; never be the founder who learns this lesson on the morning the acquisition documents are signed, because by then you will realize you spent your prime years building a paper empire for everyone but yourself. # What a Shotgun Clause Is and Why It Exists - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2022-04-18 - **Canonical URL**: https://carlosrivera.im/blog/shotgun-clauses - **Tags**: Startups, Infraestructura > A shotgun clause is a legal mechanism that forces one shareholder to buy out or sell to another at a specified valuation. How deadlock clauses actually work. When we structure early shareholder agreements with small founding teams, especially with two equal partners who hold enough voting power to deadlock each other on critical resolutions, there is a fundamental governance dilemma that must eventually be resolved in writing: what happens when neither party can impose a final operational decision and both partners can no longer work together in good faith. A shotgun clause attempts to solve precisely that deadlock: one shareholder formally triggers the mechanism by declaring a specific valuation they are willing to pay for the other partner's shares, and the receiving shareholder must choose between selling their stake at that exact price point or immediately purchasing the initiating shareholder's equity using that identical valuation per share. If you own fifty percent of an operating company and declare that the entire business is worth two million dollars, you are offering one million dollars for your partner's equity, but at the exact same moment you are implicitly agreeing to sell your own half for that same million if your partner decides to reverse the transaction onto you, and that reciprocal mechanic is what makes the structure fascinating on paper, because it forces you to calculate your valuation bid with extreme caution: if you attempt an opportunistic lowball buyout, you run the immediate risk of becoming the party forced to sell at that discounted price. ## The Operational Problem It Solves A shotgun provision does not exist to adjudicate who was morally right during an executive disagreement, nor does it repair a fractured relationship between cofounders; it serves as a blunt instrument when structural deadlock becomes so severe that continuing together damages enterprise value far more than severing ownership. That paralysis routinely strikes fifty-fifty cap tables where partners cannot reach consensus on raising venture capital, executing a strategic acquisition, replacing an underperforming CEO, or personally funding payroll deficits, and without an explicit contractual exit, you end up with a fundamentally viable operating company that is legally incapable of taking action. The shotgun mechanism converts that paralysis into a deterministic binary outcome where one partner buys and the other departs, and when weighed against eighteen months of hostile shareholder litigation or a business freezing to death while two founders feud, you understand why the clause exists in corporate registries. ## An Incomplete Framework That Requires Guardrails What partners actually sign in an early legal template is rarely a complete dispute resolution framework: a shotgun covenant merely predetermines who sets the price and who holds the election, leaving unaddressed the operational terms that dictate whether the mechanism behaves fairly in the real world, including when it can be triggered, how many days the counterparty has to respond, and how the buyout is funded. Most importantly, the symmetric math presumes an operational condition that nobody can verify on the day documents are drafted, which is that both shareholders have equal access to liquid capital: if one partner can secure a three-million-dollar financing facility within five business days while the other has their entire net worth tied up in the company, contractual symmetry is an illusion, because while both technically face the same legal choices, they operate on completely asymmetric economic playing fields. For that reason, a shotgun clause should be handled as a dangerous provisional instrument rather than a self-executing safety valve, because if any partner can fire it over an ordinary board dispute without mandatory mediation cooling periods or realistic financing windows, it is not an emergency corporate parachute, it is simply an asymmetric weapon for hostile takeovers. # Monopoly Money: The Delusion of Paper Wealth - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2021-08-22 - **Canonical URL**: https://carlosrivera.im/blog/monopoly-money - **Tags**: Infraestructura > You raise funding, your paper valuation skyrockets, and everyone assumes you are rich. In reality, you are broke, driving a beat-up car, and panicking about rent. Back in 2018, right after closing a funding round that pegged our corporate valuation in the millions of dollars while I retained forty-five percent of common equity, my paper net worth officially made me a millionaire, yet my personal checking account held barely enough cash to survive the month and I felt sick every time I walked into a grocery store. I felt trapped in an absurd charade where venture funds sent congratulatory emails while I stayed awake at night calculating whether I had enough cash to cover the rent on my apartment. Nobody talks about this psychological distortion at startup conferences because everyone prefers applauding fundraising announcements in TechCrunch to feed collective vanity, completely ignoring the reality that most founders sitting on millions of dollars of paper wealth have zero liquid capital in the real economy. You cannot exchange unvested common stock at a retail store, you cannot pledge private illiquid equity as collateral for a traditional mortgage at a commercial bank, and you live trapped in a bizarre limbo where acquaintances believe you have secured generational wealth while you endure the daily financial panic of a broke student. ## The Mechanics of Paper Wealth The trap works because the moment you close outside institutional capital at an eight-figure valuation, your paper net worth explodes, your LinkedIn inbox gets overwhelmed with strangers asking for introductions, and your family assumes your financial future is resolved forever, while buried deep within the investor contracts you signed strict share transfer restrictions, rights of first refusal, and co-sale covenants that forbid you from selling a single share without the unanimous sign-off of your lead investors. In emerging startup ecosystems, secondary liquidity markets are practically non-existent, meaning your equity certificates are completely worthless until an outright change-of-control acquisition or a public listing occurs, milestones that the overwhelming majority of tech startups will never see. That widening chasm between public perception and your personal bank account erodes founder judgment over the years, pushing brilliant operators to make reckless corporate decisions to manufacture premature liquidity events simply because they can no longer endure the pressure of raising a family on personal debt while defending an abstract paper valuation. The founders who understand these rules early negotiate secondary share sale rights during growth rounds while they still hold commercial leverage, deliberately untangle their self-worth from vanity cap table metrics, and manage their personal households on the actual cash hitting their checking accounts, because until a cleared wire transfer posts to your bank account, the private shares in your portfolio are functionally indistinguishable from Monopoly money, and nobody pays rent with Monopoly money. # Your Startup Stock Options Are Worth Nothing and Your Team Already Knows It - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2020-06-10 - **Canonical URL**: https://carlosrivera.im/blog/stock-options-might-not-matter - **Tags**: AI, Engineering, Startups > Copying Silicon Valley compensation checklists in emerging tech markets is corporate theater. Swapping base salary for promises in a PDF only drives away top engineering talent. Back when my company had zero revenue, I burned four thousand dollars retaining a corporate law firm to draft an employee stock option plan, convinced that I was assembling an enterprise like the Silicon Valley giants, and promised two senior engineers that their equity options would make them millionaires once our Series A closed. Both resigned six months later, because unvested options in a PDF do not buy groceries, and structuring that legal plan was never about compensating them fairly, it was an elaborate excuse to dodge admitting that I lacked the cash to pay competitive market wages and was terrified of losing top talent. Nearly every startup in emerging markets falls into this exact pantomime: they paste "competitive salary plus equity" onto job boards because they read it on a Y Combinator essay, purchase beanbags for the office, create a #random Slack channel, and assume that mimicking American jargon automatically manufactures secondary liquidity. ## Why Stock Options Function in Silicon Valley In California, employee equity works for a foundational reason that panel discussions across Latin America refuse to acknowledge: there is an active secondary market and real corporate exits. Companies like Stripe, SpaceX, and Figma run tender offers every year, allowing early employees at mid-stage startups to trade base salary discounts for an illiquid lottery ticket that historically produced enough outlier wins to make the trade mathematically rational. Furthermore, the American legal and tax framework is specifically engineered to support employee ownership through Incentive Stock Options, non-qualified grants, Section 409A valuations, and Qualified Small Business Stock tax exemptions, ensuring that exercising options does not bankrupt an engineer on unrealized capital gains. Outside the United States, virtually none of that financial machinery exists. ## What an Engineer Actually Receives What a developer in an emerging ecosystem actually gets is an illiquid certificate with zero secondary market, no realistic timeline for an exit, and a punitive tax liability, such as in Mexico where exercising options triggers ordinary income tax before the employee ever sees a single cleared dollar in their bank account. The regional acquisition market is microscopically small: virtually no public tech listings, negligible strategic buyouts, and transactions that do occur are almost always structured as acquihires or debt-seniority reorganizations where common stock holders receive pennies. There is nothing mysterious about why world-class software engineers who already hold remote American offers paying four to six thousand dollars a month in cleared cash hear the word equity and instantly close the tab. ## The Intellectual Dishonesty of the Pitch What irritates me most about these hiring discussions is watching early founders pitch equity grants as if they were guaranteed fixed-income bonds, sitting down with their first hire to sketch diagrams on a napkin showing how the company will compound ten times in valuation over twenty-four months, when anyone who has analyzed an institutional cap table knows the statistical probability of that paper holding value is near zero. Many founders do not do this out of cynical malice; they genuinely believe their own marketing because they are intoxicated by the startup narrative, but confusing your personal optimism with the financial security of an employee who has to pay rent every month is gross founder negligence. If you put equity on the table, the only intellectually honest posture is telling candidates plainly that their options are currently worth zero dollars and will likely remain worth zero when they depart, meaning their decision to join must stand on cash compensation and technical autonomy rather than the lottery hope of an exit. ## Operating Without the Corporate Theater The moment you discard Silicon Valley tropes, the talent conversation becomes significantly simpler and far more uncomfortable for you: pay cash salaries near true market rates rather than hiding behind depressed local wage benchmarks for someone engineering global production architecture, because exceptional talent understands the global wage arbitrage and will not subsidize your operational runway in exchange for fairy tales. If you want to align long-term incentives without administering an incomprehensible option pool nobody values, tie quarterly cash bonuses to hard, auditable revenue milestones, or implement phantom equity agreements that trigger real cash transfers whenever the business clears cash flow thresholds. Developers trust bank deposits, not pitch deck slides about your cap table. ## The Ultimate Filter If you have ever offered employee options, answer this honestly: if you were not the owner of the business, would you voluntarily accept a thirty percent pay cut in exchange for those exact same shares in an early-stage startup with unproven traction? If the answer is no, you are weaponizing equity as an involuntary discount on someone else's labor to subsidize an enterprise that cannot afford its operational expenses, and the most respectable thing you can build is not an imported stock plan, but a viable business that pays its payroll on time and never asks its engineers to gamble their household stability on a miracle acquisition. # The Most Dangerous Feeling in a Startup Is Feeling Like You Are Winning - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2020-01-20 - **Canonical URL**: https://carlosrivera.im/blog/false-feeling-of-progress - **Tags**: Infraestructura, Engineering > Building a product nobody wants feels indistinguishable from real progress. It is not. There is a very specific sensation in early-stage startups that I have learned to distrust more than anything else after a decade in the trenches: not the fear of running out of money, and not the constant uncertainty of the market, but that warm, addictive, and deceitful feeling that you are genuinely making progress simply because you are busy writing software. That feeling is a professional liar. ## The Builder's Trap Early on in one of my previous ventures, we spent nine full months engineering a workflow automation platform, writing complex machine learning models, training custom classifiers, and wiring together expensive third-party integrations. We made pristine architectural decisions, crafted elegant abstractions, designed gorgeous analytical dashboards, and shipped a product we were immensely proud of, assembled by a team of brilliant engineers and running flawlessly in production, but we had precisely zero paying accounts. The core problem was that it never felt like we had zero customers; it felt like we were building a breakthrough company, because every completed sprint and every feature deployment felt like genuine velocity. Team metrics looked healthy, money in the bank gave us breathing room, and we were building with real operational momentum, but we were constructing something nobody had ever asked for. This is the most insidious trap in the startup ecosystem: writing code feels productive, shipping features feels like momentum, and hiring engineers feels like scale, but none of it is real until an actual economic buyer pulls out their credit card and pays you. ## Motion Is Not Traction I see this pattern play out constantly among early teams that boast about an enormous product roadmap, an endless commit history, and pixel-perfect Figma prototypes to prove they are grinding twelve-hour days in the office. Whenever I ask them how many genuine prospective buyers they interviewed this week, the answer is always a weak rationalization about how they are getting close to launch, how they want to polish the core experience first, or how they plan to initiate enterprise sales next month. That next month never arrives because there is always one more critical edge case to handle or another backend migration to finish. The product is never ready because the definition of ready remains a moving target when you have never defined what ready means to someone with purchasing authority. The uncomfortable truth is that your initial version should embarrass you, and if it does not embarrass you, you launched too late. Polishing an unproven interface in month seven is a refinement nobody asked for, and the extra workflows you architect in month eight only solve problems you fabricated in your head rather than the bleeding emergencies your prospective customers face every day. ## The Sunk Cost Spiral The builder's trap compounds over time because of psychological sunk costs. After three months of development, you have invested enough energy that pivoting feels like an admission of failure. After six months, you have told your investors, friends, and family about the vision, and by month nine your personal identity is inextricably bound to the code itself. So rather than stepping back to interrogate whether market demand exists, you double down, shipping more features, redesigning the marketing site, adding integration tests, and convincing yourself that you are just one feature away from unlocking product-market fit. That mythical silver-bullet feature does not exist, because the issue was never an incomplete feature set; the issue was building for months in a vacuum. The inevitable pivot that saved our company forced us to throw seventy percent of our codebase straight into the trash. I am not talking about a refactor; I mean permanently deleting nine months of engineering labor because it solved the wrong problem for the wrong customer. It was excruciating, but it hurt far less than burning another nine months building on top of a foundation nobody cared about. ## The Filter Against the Builder's Trap After tossing nine months of code into the furnace, you become hyper-vigilant against any synthetic feeling of momentum and force yourself to adopt a much harsher operating filter. If fourteen days pass without speaking to a prospective customer or having a customer conversation that forces you to strike a feature off your roadmap, you are not executing with technical discipline; you are hiding in your code editor to avoid hearing that nobody cares about what you are making, because authentic market feedback is always chaotic, contradictory, and ruins the clean architecture you designed with so much pride. The ultimate litmus test is simple: if closing your next ten sales conversations requires coding for two weeks instead of picking up the phone, the problem is not missing software functionality, the problem is that you are building in a vacuum and have zero idea how to sell. ## What Changed After the Crash Today, whenever I initiate a new venture, I forbid myself from touching a database schema or debating backend frameworks until the exact same commercial pain is described independently by ten distinct prospective buyers who have never met each other. Only when the problem is so severe that it is actively bleeding do we assemble the cheapest, most rudimentary manual workflow possible, delivering it through a shared spreadsheet or an automated script to verify whether they will pay cold cash to solve it, because opening an IDE will always feel like progress, but writing software without paying customers is not execution, it is simply the most expensive way to buy yourself temporary peace of mind. # You Are Fighting Over a Pie That Does Not Exist - **Author**: Carlos Rivera (https://carlosrivera.im) - **Published**: 2019-03-15 - **Canonical URL**: https://carlosrivera.im/blog/equity-splits-zero-value - **Tags**: Startups, Infraestructura, Engineering > Debating equity percentages before validating the product is the most expensive mistake founders make. You are fighting over a fraction of nothing. In my first company, I made the amateur mistake of agreeing to a fifty-fifty split on a paper napkin simply because I was terrified of having an awkward conversation during our first week, and the price was waking up six months later with half my cap table held hostage by someone who lost interest in the business and left me with an un-investable corporate shell. I still witness that exact failure mode in coffee shops where two or three people who met two months ago fight over decimal points of equity in a fictitious entity worth precisely zero dollars, exhausting themselves with theatrical emotional friction as if they were dividing a multi-million-dollar lottery jackpot when in reality they are arguing over ownership of a ticket they have not even purchased. ## The 50/50 Trap An even split is the favorite default of conflict-averse founders, an elegant escape hatch where everyone nods politely to avoid tension, yet it almost guarantees the business blows apart at the first operational roadblock. A symmetrical division rests on the naive delusion that every partner will contribute equally across a five-to-seven-year slog, ignoring that real founder commitment is not measured by who types the most lines of code during the first month, but by who resigns from their secure salary, who injects personal savings to cover cloud bills, and who stays in the room to field lawsuits when corporate cash flow runs deep in the red. ## The Idea Is Worth Nothing Someone on the founding team inevitably claims they deserve an outsized equity stake simply because the original concept came out of their head, as if an idea in the shower carried tangible financial value before surviving contact with real buyers. In one of my previous startups, we endured fourteen brutal pivots before finding operational traction, and the person who conceived the original thesis contributed exactly zero value to the business model that actually survived, because an initial concept is nothing more than an opening pretext to get to work. If a prospective partner demands more equity based on originating the idea, you are staring at a massive warning flag from someone looking to cash in on a hallucination before getting their hands dirty with the brutal, unglamorous labor. ## What Actually Moves the Needle Equity splits should be dictated by hard, measurable realities evaluated without sentimentality: who is working full-time from day one while others keep collecting safe corporate salaries, who is personally bankrolling the first six months of legal formation and payroll out of personal savings, and who commands the enterprise relationships necessary to bypass two years of regulatory gatekeeping. Just as critical is determining who holds the tie-breaking vote as CEO, because an entity where two partners command identical voting power and neither can overrule the other is doomed to fatal paralysis the second they hit an irreconcilable disagreement. The resulting cap table must reflect those stark asymmetries in risk tolerance, and by basic economic logic, it should never land on a clean, symmetrical fifty-fifty split. ## Non-Negotiable Vesting It makes no difference whether you have known your cofounder since kindergarten or swore eternal loyalty over drinks; issuing shares without a standard four-year vesting schedule and a twelve-month cliff is planting a financial landmine directly beneath your next funding round. If someone quits or burns out after nine months, they must walk away with exactly zero shares in their pocket, preventing a phantom founder on the cap table that will instantly scare off institutional capital. Vesting protects the partner who stays in the trenches against the partner who throws in the towel the moment reality turns hostile. ## Negotiating Over an Empty Shell Spending weeks agonizing over an extra two percent in a business that does not collect a single dollar of revenue is the clearest symptom of a team terrified of facing the market. Have the uncomfortable conversation during week one, lay your cash contributions and working hours on the table, sign an enforceable shareholders agreement with a startup attorney instead of downloading broken templates from the internet, and stop pretending to be corporate financiers dividing a pie that does not exist in the physical world.