Forem: Dany Paredes

How to Create One-Click MCP Installation Deep Links for Cursor and VS Code

Dany Paredes — Thu, 02 Apr 2026 00:00:00 +0000

A few weeks ago, I built the unsplashx MCP. But to make it easier for my friends to use it, I decided to simplify the installation process. Today, I want to explain why using deep links is critical for reducing friction in the MCP ecosystem.

Manual installation is a chore. Instead of asking users to hunt for JSON settings, fix syntax errors, and restart their IDE, we can use one-click deep links to make it invisible.

Why Deep Links?

Think of this as a "mailto:" link for your coding agent. If a user has Cursor or VS Code open, they click a link, and the editor handles the configuration automatically.

Both Cursor and VS Code support these links, but they use different encoding formats. Manually creating these links every time you update your package is exactly the kind of task we should automate.

The Goal: From JSON to One-Click

Let’s see how to transform a standard MCP configuration into a link that works in a real project. We'll use the config for my unsplashx server:

{
  "unsplashx": {
    "type": "stdio",
    "command": "npx",
    "args": ["-y", "unsplashx"],
    "env": {
      "UNSPLASH_ACCESS_KEY": "YOUR_KEY_HERE"
    }
  }
}

Step 1: Cursor Protocol (Base64)

Cursor requires the JSON configuration to be Base64 encoded.

Format:cursor://anysphere.cursor-deeplink/mcp/install?name=$NAME&config=$BASE64_CONFIG

Base64 encoding keeps the URL valid while preserving the entire JSON structure.

Step 2: VS Code Protocol (URL Encoded)

VS Code expects a URL-encoded JSON string (usually via the official MCP extension).

Format:vscode://mcp/install?${JSON_STRING_URL_ENCODED}

Since each editor has its own preference, our automation needs to handle both.

The Solution: A Reusable Script

Here is a simple TypeScript snippet to generate both links for any MCP server:

/**
 * Automate MCP Installation Links
 */
function generateMcpLinks(name: string, config: any) {
  const configString = JSON.stringify(config);

  // 1. Cursor (Base64)
  const cursorBase64 = Buffer.from(configString).toString('base64');
  const cursorLink = `cursor://anysphere.cursor-deeplink/mcp/install?name=${name}&config=${cursorBase64}`;

  // 2. VS Code (URL Encoded)
  const vscodeEncoded = encodeURIComponent(configString);
  const vscodeLink = `vscode://mcp/install?${vscodeEncoded}`;

  return { cursorLink, vscodeLink };
}

// Example for unsplashx
const myConfig = {
  type: "stdio",
  command: "npx",
  args: ["-y", "unsplashx"],
  env: { UNSPLASH_ACCESS_KEY: "" }
};

const links = generateMcpLinks("unsplashx", myConfig);

console.log("Cursor:", links.cursorLink);
console.log("VS Code:", links.vscodeLink);

Try it: One-Click unsplashx Installation

See it in action. These buttons will install the unsplashx MCP directly into your editor (you'll just need to provide your API key in the prompt):

Takeaway

Friction kills adoption. Most people love new tools but hate configuration. By automating these links, you remove the barrier to entry.

If you build an MCP server, don't just ship the code— ship the installation experience.

Photo by Sven on Unsplash

Being a Writer in the Era of Writer/AI Slop

Dany Paredes — Fri, 20 Mar 2026 00:00:00 +0000

After seven years of writing technical articles, during this time I have loved share my headaches faced while building a solution; doing so made it easy to re-read my thoughts before an interview or when I had to solve the same problem again months later.

My articles were, and still are, based entirely on real work experience but nowadays, it looks like we need to write just for SEO or positioning or ChatGPT Position 😭, not for returning real user value. The worst part is that we get more AI visitors than humans, and when a real human reads the article, they feel the difference.

Today, it often feels like we're trapped in a strange loop. Everyone is writing but increasing amount of "empty content" or "AI/Writer Slop." It has become a cycle where robots write for robots, and humans simply press "publish."

When we rely too much on these tools, we lose our unique voices. We stop being developers sharing real fixes and become just more noise in the crowd. To stand out today, I believe we must be more human than ever.

My Experience is My Best Asset

While AI can explain a library's API better than me, reading the full source-code and writing examples, it cannot tell you how it felt to debug a production issue at 2 AM or the scare of running a schema migration. The AI cannot create a unique analogy from scratch that connects with the reader.

I felt happy when, a few days ago, a colleague shared how much she loved my comparison of AI without MCP to a smart friend on the phone. It clicked because it was a direct reflection of my own experience—something I lived, rather than something a machine generated from a template.

Being writer doesn't require inflated phrasing like "delve into this transformative landscape." Instead, you just need to be yourself. My aim is to write for you as if we were having a coffee, telling you directly: "This is what I did, and this is how it worked for me."

Think of your article as a repository. You wouldn't add unnecessary dependencies, right? To keep my voice authentic, I always check my drafts for these points:

Is this my story? : Did I actually try this code myself?
Is my language simple? : Can a junior developer from any country understand me?
Am I using real world examples? : This scenario case a real pain of my readers?
Are my sentences short and direct? : Am I hiding a lack of clarity behind long words?
Did I use a real-world analogy? : Can I explain this like I would to a friend?

Refactoring to a Human Tone

I know the AI is incredible, but it lacks the human touch. When I read some AI generated articles, I feel that they are empty; they don't have the soul of a real developer. Let's look at how I would refactor a typical AI-generated paragraph into my own voice.

How a Robot Writes:"Signals in Angular are pivotal to delve into the transformative capabilities of the new Angular signals to unleash the full potential of your application's reactivity."

How I Write:"Signals in Angular make my apps faster. They simplify how I handle data changes without the complexity of RxJS. Let's see how they work in a real project."

Did you feel the difference? The first line is boring without sharing experiences but with fancy, nice words, but they are empty.

But I love the AI

Yes, I use AI to help me write, but I use it to help me write better, not to write for me. I use it to help me find the right words, not to write the article for me.

I do a lot of typos and use incorrect verb tenses, so I use AI to correct them, but I always re-read the article to make sure it sounds like me.

The AI is perfect to help me with the boilerplate code, fix bugs, or suggest better approaches.

Final Reflections

This is not technical article, its just my feeling writing is about more than just data; it's about sharing a journey. Our real-world "headaches" are our most valuable lessons.

Please, if you like to write, just write.

Write for your future self : Detail the difficult parts.
Learn from others : As Mandy showed me, connection is essential.
Stay authentic : Lived experience is something AI cannot replicate.

Take a paragraph you wrote recently and read it out loud. Ask yourself: "Does this sound like me?" If it doesn't, start cutting the fluff until your own voice begins to shine through.

Photo by VD Photography on Unsplash

Moving from Vercel to Google Cloud: Why and How I Migrated My Next.js Blog

Dany Paredes — Wed, 11 Mar 2026 00:00:00 +0000

Let’s be honest: I love Vercel. It is an amazing platform. The developer experience is probably the best you can find. If you are starting a new project or need to move fast, I still recommend it.

But as I added more projects like zum360 , LearningCool , and my sister’s website, my monthly bill started to grow. Those "Edge Function Execution" charges can be a surprise at the end of the month.

Since I use Google Cloud Platform (GCP) at my current job, I decided it was time to move my personal blog and projects there. I wanted total control and lower costs.

Here is the technical journey of how I did it, developer to developer.

Preparing for Docker

First, you need to package your app. I already wrote a guide on how to deploy Next.js outside Vercel which covers the basics, but here is the specific "secret sauce" for GCP.

Next.js has a built-in standalone mode. This is critical because it creates a very small production build. You don't need to ship your massive node_modules folder.

Update your next.config.ts:

const nextConfig = {
  output: 'standalone',
}

[!TIP] You can find more details in the official Next.js documentation.

Moving to Google Cloud Run

For the hosting, I chose Google Cloud Run. It is a "serverless container" service. This means your app only runs when someone visits your site. It scales to zero when there is no traffic, so you pay almost nothing for a personal blog.

The CLI Setup

First, I installed the Google Cloud CLI. After logging in with gcloud auth login, I was ready to build.

Building and Deploying

Instead of building the Docker image on my laptop (which is slow), I used Cloud Build. This command sends your code to Google’s servers, builds the image, and saves it in a private registry:

gcloud builds submit --tag gcr.io/YOUR_PROJECT_ID/danywalls-blog .

Then, to make it live:

gcloud run deploy danywalls-blog \
  --image gcr.io/YOUR_PROJECT_ID/danywalls-blog \
  --region us-central1 \
  --platform managed \
  --allow-unauthenticated

Managing Secrets (The Professional Way)

On Vercel, you just paste your API keys into a web panel. In GCP, we use Secret Manager.

I stored my ConvertKit API key and Google Analytics ID there and granted my Cloud Run service the Secret Manager Secret Accessor role. Then, I updated the service to mount these secrets as environment variables:

gcloud run services update danywalls-blog \
  --set-secrets=CONVERTKIT_API_KEY=CONVERTKIT_API_KEY:latest

It’s more steps than Vercel, but it’s much more secure. No secrets are ever stored in my code or build logs.

Connecting the Domains (Double Trouble)

My blog uses both danywalls.dev and danywalls.com. To link them, I used Domain Mappings in Cloud Run.

gcloud beta run domain-mappings create --service danywalls-blog --domain danywalls.com

Google gave me a list of A and AAAA records. I use Cloudflare for DNS, so I added those records there.

Important Tip for Cloudflare users:

Set your SSL/TLS mode to "Full (Strict)".
At first, leave the Proxy status to "DNS Only" (Grey cloud) until Google finishes issuing the SSL certificate. Once it's "Ready", you can turn the proxy back on.

"Git Push to Deploy" with GitHub Actions

I didn't want to lose that Vercel feeling where you just push code and it updates the site. I recreated this using GitHub Actions.

I created a .github/workflows/deploy.yml file. This workflow authenticates with Google Cloud using a Service Account key (stored in GitHub Secrets) and runs the build and deploy commands automatically every time I push to main.

In my next article, I’ll dive deeper into exactly how I configured this. I’ll share how my AI assistant helped me set up everything to make the workflow feel as natural and smooth as it did on Vercel. Stay tuned!

Lessons Learned

Leaving Vercel was a big step, but I learned so much:

Cost Control : I now pay a few cents instead of $20/month.
Infrastructure Skills : I now manage my own containers and security policies.
Portability : My app is now a standard Docker image. I can move it to any other cloud in 5 minutes.

If you’re feeling restricted by Vercel’s pricing or just want to level up your engineering skills, building your own "nest" in the cloud is a great experience.

Are you thinking about migrating? Let me know your thoughts on Twitter/X!

Dockerizing Next.js: The Hidden Challenges

Dany Paredes — Sun, 22 Feb 2026 00:00:00 +0000

I wanted to write this article for a month. There is a big difference between a small project on Vercel and a real production app. In Vercel, everything is easy and feels "pink-colored" because the complexity is hidden.

When your project grows, you need more control. You move from a simple setup to a large infrastructure with multiple pods and scaling rules. I use Google Cloud for my projects, but these challenges are the same if you use AWS or Azure.

This move is a big change in architecture. In Vercel, the system is managed for you. Outside of Vercel, you are the architect. In this article, I want to share the first stumble I had when dockerizing Next.js. I never thought it would give me problems, but it did: Environment Variables.

Vercel vs. Self-Managed Architecture

When you use Vercel, they provide a "black box" that handles your build, your deployment, your SSL, and your CDN. When you move to your own infrastructure (like Docker on GCP), you need to replace each piece of that box.

graph TD
    subgraph "The Vercel Way (Managed)"
        A[Git Push] --> B[Vercel Build Engine]
        B --> C[Vercel Edge Network]
        C --> D[User]
    end

    subgraph "The Self-Managed Way (Docker)"
        E[Git Push] --> F[CI/CD Pipeline\nGitHub Actions/GitLab]
        F -->|Build Image| G[Container Registry\nArtifact Registry/ECR]
        G -->|Deploy| H[Cloud Hosting\nCloud Run/App Runner]
        I[Secret Manager] -.->|Runtime Secrets| H
        H --> J[Load Balancer / CDN]
        J --> K[User]
    end

To make this architecture work, the most critical part is the Build Pipeline. This is where your code is converted into a Docker image, and it is exactly where most developers face their first big problem: Environment Variables.

The Technical Wall: Environment Variables

Before we build our architecture, we must understand how Next.js treats environment variables. It puts them into two separate groups: Build-Time Variables and Runtime Variables. In Vercel, this connection is seamless. You add your variables to the dashboard and they work in both cases. In your own architecture, you must handle this manually in your Dockerfile and your CI/CD.

Build-Time Variables (`NEXT_PUBLIC_`)

Variables starting with NEXT_PUBLIC_ are baked into the final JavaScript bundle when you run npm run build. They are visible to the browser.

Example: API URLs or analytics IDs.

If you forget to add these variables during the build step, the final JavaScript will have undefined or empty strings. This happens even if you try to add them later when starting the app.

Runtime Variables (Private)

Variables without the prefix are private and only exist on the server. They are not bundled during build; instead, they are accessed during request time.

Example: Database URLs, API tokens, or payment keys.

The Scenario

Imagine an app that needs to fetch data from an external API. In local development, everything works with no effort. You create a .env.local file and Next.js picks up the values automatically:

# .env.local
NEXT_PUBLIC_API_URL=https://dummyjson.com/products
API_SECRET_KEY=my-super-secret-key-123

NEXT_PUBLIC_API_URL : This is for the frontend. It tells your app where to fetch information.
API_SECRET_KEY : This is a private key for your backend logic.

When you run npm run dev, Next.js reads these variables and your app works perfectly. In your code, you access them like this:

// Frontend: This will be part of the JS bundle
const apiUrl = process.env.NEXT_PUBLIC_API_URL;

// Backend: This will stay only on the server
const secret = process.env.API_SECRET_KEY;

This "magic" happens because Next.js is designed to make local development simple. But as soon as you move to Docker, this magic disappears.

Moving to Docker

After testing the app locally, you might think that moving to Docker is simple. If npm run dev and npm run build work on your machine, the Docker image should work too.

I made my first Dockerfile like this:

FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build # ❌ NEXT_PUBLIC_ variables are missing!
CMD ["npm", "start"]

I built the image, started the container, and found my first stumble. The app was running, but the frontend variables were missing. This is because Next.js needs NEXT_PUBLIC_ variables during the build process. In my simple Dockerfile, the npm run build command had no access to these variables.

The result? The compiled files were created with undefined values.

The Solution: ARG and ENV

To fix this, we need to pass these variables during the build phase using Docker ARG and ENV.

ARG (Build Argument): This is a temporary variable used only while the image is being built.
ENV (Environment Variable): This is a permanent variable inside the container.

Here is the correct way to write the Dockerfile:

FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci

# 1. Capture build-time args
ARG NEXT_PUBLIC_API_URL
# 2. Assign to ENV for the build process
ENV NEXT_PUBLIC_API_URL=$NEXT_PUBLIC_API_URL

RUN npm run build
CMD ["npm", "start"]

Now you can build the image with the correct values:

docker build --build-arg NEXT_PUBLIC_API_URL="https://api.com" -t my-app .

What about private variables?

Private variables (without the NEXT_PUBLIC_ prefix) are different. You should never put them in the Dockerfile. These variables are used when the server is running, not when you build the image.

You can inject them when you start the container:

docker run -e API_SECRET_KEY="my-secret" my-app

Security Concerns

When you move your app to a production environment, security is very important. In Vercel, you add your secrets in the dashboard and they are encrypted automatically.

In your own infrastructure, you might think about using the -e API_SECRET_KEY=... flag when you start Docker. This is not a good idea for a real project. It is not secure and it is not scalable. Typing your passwords in plain text in the terminal is a big risk.

Instead, you should use a Secret Manager. Big cloud providers like Google Cloud, AWS, and Azure provide services to manage your secrets safely.

When your container starts, the cloud provider injects these secrets directly into the environment. This is a much better way to work because your secrets are never saved in your CI/CD logs, your terminal history, or your Docker image layers. This keeps your application safe as it grows to multiple pods and complex setups.

Recap

Now that our Docker image is ready, we can move it to any cloud provider like Google Cloud , AWS , or DigitalOcean. Choosing the right architecture is a big step when you move beyond Vercel or your local machine.

In a real production environment, you might use a more complex setup with many pods and Kubernetes. I wanted to focus on this first "stumble" because it is the most common reason why Next.js deployments fail.

In a future article, I will explain the next step: how to upload this image to Google Cloud and how to use their Secret Manager to handle your enterprise secrets.

I hope this guide helps you when you move your application from Vercel to a real Cloud environment.

Happy coding!

WebMCP: AI Agents are your new web visitors

Dany Paredes — Sat, 14 Feb 2026 00:00:00 +0000

This weekend, I decided to play with something that seems to have a lot of potential. As you probably know, I've been experimenting a lot with MCP lately (I even created mcpclick.com), and this discovery feels like a game-changer.

The web is changing. Until now, we built websites only for humans. But today, a new user is visiting our pages: AI Agents.

Have you ever tried to make an AI enroll in university courses or search for a specific class schedule on a student portal? It is slow and often fails. Why? Because the agent has to "read" the website like a human. It looks at the HTML and guesses which fields to fill. If you change your CSS even a little bit, the agent gets lost.

What problem does this solve for us as developers? It gives us a simple, fast way to tell the AI: "Don't guess. Use these tools instead."

This is WebMCP (Web Model Context Protocol).

What is WebMCP?

WebMCP is a new standard proposed by Microsoft and Google. Its goal is to make your website ready for agents.

Think of this as a Sitemap for actions. A sitemap.xml helps Google find your pages. WebMCP involves telling AI models (like Gemini, GPT, or Claude) what they can do on your site.

Two ways to use it:

The HTML Way (Declarative): Great for forms. You add two simple attributes, and the browser handles the rest.
The JavaScript Way (Imperative): For complex tasks, like calculations or real-time searching.

Setting Up Your Lab

This is new technology and has not yet arrived in standard browsers. To interact with it, you will need a special version of Chrome that includes the latest experimental features.

Don't worry, you can install it alongside your normal Chrome.

Download Chrome Canary or Chrome Dev.
- Note: You need version 146 or higher.
Open Chrome Canary and go to chrome://flags.
Search for #web-mcp (Web Model Context Protocol) and fully enable it.
Restart the browser.

Important: This is experimental software. Features may change or break without notice. It is designed for developers, so expect some rough edges!

The HTML Way

Imagine you have a blog. You want a user to say to their browser: "Search Dany’s blog for React articles."

Computers are bad at guessing. With WebMCP, we tell them exactly what to do using HTML:

<form 
  action="/search" 
  toolname="search_articles" 
  tooldescription="Search for tech articles by topic in the blog.">

  <input type="text" name="query" placeholder="What to learn?" required />

  <select name="category">
    <option value="react">React</option>
    <option value="typescript">TypeScript</option>
    <option value="ai">AI</option>
  </select>

  <button type="submit">Search Now</button>
</form>

What did we just do? We added toolname and tooldescription. Now, the browser reads this form and creates a manual for the IA. The agent knows exactly how to use your search bar. It does not need to guess.

The JavaScript Way

Sometimes a form is not enough. Maybe you need to verify if a course has open seats without reloading the page. For this, we use JavaScript.

// Check if the browser supports this
if ('modelContext' in navigator) {
  navigator.modelContext.registerTool({
    name: "check_course_availability",
    description: "Checks if a university course has open seats.",
    inputSchema: {
      type: "object",
      properties: {
        courseId: { type: "string", description: "The course code (e.g., CS101)" },
        semester: { type: "string", description: "Target semester (e.g., Fall 2026)" }
      },
      required: ["courseId", "semester"]
    },
    execute: async (args) => {
      // Fetch real-time data from your API
      const response = await fetch(`/api/courses/${args.courseId}/status?sem=${args.semester}`);
      const data = await response.json();
      return { 
        available: data.seats > 0, 
        remainingSeats: data.seats,
        professor: data.professorName
      };
    }
  });
}

Why is this cool? Now, an AI (like a browser Copilot) can call check_course_availability directly. It doesn't need to navigate complex tables. It just asks your code for the answer.

Is it Safe?

Yes. Security is built-in:

You know who called: You can check if a human or an AI sent the form (the proposal adds an agentInvoked property to SubmitEvent).
Private: The agent only sees the tools you list.
Consent: The browser usually asks the user before the AI takes action (like buying something).

Go Explore!

This is just the beginning. We are moving to a web where sites are APIs for AI.

I encourage you to try it out. It is fun to be an early adopter.

Don't just read about it. Experiment. Try to make your own "Agent-Ready" website.

Moving to Cybersecurity from a Software Developer Role

Dany Paredes — Tue, 10 Feb 2026 00:00:00 +0000

Moving to a new field is always a challenge. But when I joined Neuraltrust, a cybersecurity company, I realized that my "standard" developer security skills were simply not enough. 😅

I have been a developer for years. I thought I understood security because I knew the standard practices: hash passwords, use HTTPS, sanitize database inputs, and never commit secrets to GitHub.

But during my first week of meetings, the heavy use of acronyms like SIEM. IPA. IDP. PII. SPII. made me feel completely lost. It felt like I was learning a new language.

After about a month, I started to understand. I realized these are not just complex business words—they are the foundation of trust. As developers, we focus on building features. Cybersecurity focuses on protecting those features.

If you are moving to Cybersecurity from a developer role, this post is for you. It is the guide I wish I had on my first day. Here is a simple explanation of these terms from a developer's perspective. Instead of seeing them as hurdles, I began to see them as layers of a defense strategy.

Let’s start with how we handle the "noise" and security events.

SIEM: More Than Just Logs

We love logs, right? Logging is for fixing bugs. If the app crashes, we check the logs to see the error.

But in Cybersecurity, logs are much more than that, you will hear the term SIEM very often. But what SIEM is? To make short, it is a Security Information and Event Management, but what does it mean?

Imagine your application is a house. You check the locks (authentication) and maybe install a camera (logging).A SIEM is like a central security station that watches every camera in the neighborhood at the same time. It collects logs from your app, but also from firewalls, servers, databases, and routers. It uses logic and AI to find connections between events.

If a user fails to login 5 times in your app, that is a simple log. If that same IP address tried to access the database server 2 seconds earlier, the SIEM connects these two events and alerts the team of an attack.

Your logs are not just for you; they are data for the SIEM. If you create bad logs (like console.log("error here")), the SIEM cannot understand them. To fix this, you should structure your logs using JSON format and include key context like the User ID, IP address, Action, and Timestamp. Just be careful not to log sensitive data, which leads us to the critical topic of Data Protection.

The most common tools you will encounter are Splunk , which is popular for analyzing massive amounts of log data, and Google Chronicle , which is built for speed and feels like searching Google for your logs.

However, knowing what happened in the logs is only half the battle. You also need to know who did it, which brings us to identity and compliance.

IdP & HIPAA: Identity vs. Compliance

If I need to create a feature for user authentication, like a login page, I will create a users table and I am done, but in the real world it is much more complex.

What IdP ?

In a large system, you do not want every app to manage its own passwords. You want one central place to manage users. An IdP (like Okta, Auth0, or Microsoft Entra ID) is that central place. It confirms who the user is and gives your app a token.

Break Glass or The Emergency Key

What happens if the login system (IdP) stops working? Or if the admin loses their phone and cannot use 2FA? This is why we need a Break Glass account. In simple terms, it is a special account with full power that we never use for normal work. It is kept in a safe place and only used during a real emergency. It is like an emergency key to enter your house. It ensures that if everything else fails, we are not locked out of our own system.

What HIPAA ?

I thought this was "HIPPA" or just some medical rule. It stands for Health Insurance Portability and Accountability Act. If you touch any health-related data, you must follow this. It dictates how data is encrypted, who can access it, and how you audit it.

Recognizing who is accessing the system and what regulations apply is just the first step. The next is understanding the nature of the data itself.

PII vs. SPII: Data Types Matter

What PII (Personally Identifiable Information) is

Any data that can identify a specific person, such as their name, email, phone number, or IP address.

What SPII (Sensitive PII) ?

This is even more critical. If stolen, it can cause severe harm. We are talking about Social Security Numbers, passport details, biometric data like fingerprints, medical records, or financial account numbers.

I used to treat a "Notes" field as a simple text box. But if a user types their credit card number into that "Notes" field and I save it to the database, I have created a serious security problem. The key is to know what you are storing. SPII must be encrypted (database passwords aren't enough), and PII must be masked in logs so you never expose a user's email or phone number in plain text.

Once you understand the sensitivity of the data you're handling, you need a philosophy to protect it. This is where the core philosophy of security comes in.

The CIA Triad: The Core Principles

Before this job, my security checklist was random. Now I know that everything connects to three main concepts: C-I-A. It stands for Confidentiality (only authorized people see data), Integrity (data hasn't been tampered with), and Availability (the system is actually online).

When you build a feature, ask yourself: Does this affect Confidentiality, Integrity, or Availability?

The CIA triad gives us our goals, but how do we actually achieve them at scale? We use established frameworks to guide our processes.

The Frameworks: NIST CSF & Security Controls

My mindset as a developer was that security policies were just boring documents. Since I come from frameworks like Angular, I thought, "Hey, this is going to be some cool code!" — well, it turns out it's more about structure, processes, and strategy.

What NIST CSF (Cybersecurity Framework) is

It is a guide that breaks security down into five simple steps. I realized my job involves the whole cycle: we start by Identifying what we have and Protecting it with standard measures like auth and encryption. But we also need to Detect when something goes wrong, Respond with a plan, and Recover the system after an attack.

What CISSP ?

This is a major certification for security professionals. For developers, Domain 8: Software Development Security is the most important. It teaches that security must be part of the design, not added at the end.

This fundamentally changed how I view typical security requests. When a security engineer asks for a "Software Bill of Materials" (SBOM), they are simply following the Identify step of the framework. When they require Two-Factor Authentication , they are implementing a standard Security Control. Seeing the bigger picture turns these from annoying tasks into necessary architecture.

But even the best architecture can fail, and when it does, you need a plan.

The Playbook: Response Plans

My mindset as a developer was: If we get hacked, everyone just starts fixing things randomly.

What a Playbook ?

A playbook is a recipe for handling a specific type of attack. For example, a Phishing Playbook might instruct the team to isolate the affected computer and reset the user's password immediately. Then, they check the logs (via Splunk or Chronicle) to see what was accessed and notify the legal team.

As a developer, your job is often to provide the tools or logs that make these playbooks possible. And when the playbook says "Access the backup server," you might be the one reaching for the Break Glass credentials to save the day.

Quick Recap

If you are in the middle of an interview process or just stepping into the world of Cybersecurity, here is a quick summary of the key concepts:

SIEM: The "security camera system" for your logs (like Splunk or Chronicle).
IdP & Break Glass: Your centralized login system and your emergency backup keys.
PII vs. SPII: Distinguish between personal data (to protect) and sensitive data (to encrypt).
HIPAA: The strict rulebook you must follow if you touch medical data.
CIA Triad: The core principles of Confidentiality, Integrity, and Availability.
NIST CSF: The primary framework used to Identify, Protect, Detect, Respond, and Recover.
CISSP & Playbooks: The gold standard certification and your step-by-step recipes for responding to attacks.

The biggest change for me was realizing that security is a process, not a feature. As developers, we are naturally optimists; we build for the "Happy Path" where everything works perfectly. In contrast, Cybersecurity looks at the "Unhappy Path"—where someone is actively trying to break the system.

My first two months I'm not fighting or hacking but I'm building systems that are easy to monitor (SIEM), have secure users (IdP), and protect data properly (PII). And honestly? It changes the way I think and solve my coding challenges.

MCP One-Click Installers: From Pain to One-Click Magic

Dany Paredes — Sun, 18 Jan 2026 00:00:00 +0000

Let's be honest: setting up MCP (Model Context Protocol) servers is usually a "copy-paste and hope" experience.

You find a cool tool, like the Kendo Telerik MCP (which I use daily for UI scaffolding), and then the dance begins:

Open editor settings.
Find the JSON config.
Paste the snippet.
Check the commas.
Restart.

It’s manual. It’s friction. And for someone trying your tool for the first time, it’s often where they give up.

The "A-ha!" Moment

While building my first MCP server, I realized that both Cursor and VS Code support deep links. They have a secret way of saying: "Hey, if you click this link, I'll install the server for you."

But there was a catch. The link formats are... let's just say "developer-unfriendly":

Cursor requires Base64 encoding.
VS Code requires specific URL encoding patterns.

I spent more time encoding JSON strings than actually coding features. That’s when the idea for mcpclick.app was born.

Making Installation Invisible

I wanted a way to share the Kendo Telerik MCP with my friends and team without explaining the technical details. I wanted them to just click a button.

So I built mcpclick.app to handle the "boring stuff."

How it works (The 10-second version):

You go to mcpclick.app/generate.
You paste your raw JSON config.
You get professional buttons for Cursor , VS Code , and VS Code Insiders.

No more btoa() in the console. No more broken URL parameters. Just professional, standard badges ready for your GitHub README or blog.

The Result: One-Click Joy

Now, when I want to share the Kendo Telerik setup, I don't send a block of JSON. I send this:

Why this matters

If you are a developer building an MCP or a team lead trying to standardize tools, installation is your first point of Developer Experience (DX).

By using magic links, you:

Remove all friction : One click vs. Five steps.
Avoid typos : The config is baked into the link.
Look professional : Official-looking badges build trust.

I built mcpclick.app as a gift to the community. It’s free, it’s fast, and it hosts over 500+ curated servers if you're looking for inspiration.

Go make your MCPs one-click ready! 🚀

How I Improved My Blog with Vercel Agent Skills and React Best Practices

Dany Paredes — Fri, 16 Jan 2026 00:00:00 +0000

Early this morning, I found that Vercel had released a new Agent Skill about React Best Practices.

I thought: Who better than Vercel? They have taken React to the next level. I wondered how the experience of their entire team of developers could help me improve my blog.

So I ran one command, and here is what happened.

The Problem: Good Code That Could Be Great

My blog was already using Next.js 16 and React 19. The build was passing, linting was clean, and users seemed happy. But as developers, we know that "working" and "optimized" are two different things.

I had questions:

Was I using React hooks correctly?
Were my components re-rendering too much?
Could my images load faster?
Was my code accessible for keyboard users?

These aren't the kind of problems that break your app. They're the silent performance killers that add up over time.

Why Vercel's Experience Matters

If there is one company that truly understands React and Next.js at scale, it is Vercel. The sheer volume of products and solutions they have developed is brutal. They have seen it all: the performance bottlenecks, the complex edge cases, and the headaches that keep us up at night.

For years, that knowledge was largely locked inside their engineering team. But now, thanks to Agent Skills , we can access that collective wisdom directly in our editor.

The Solution: One Command, Instant Expertise

Vercel recently released react-best-practices, a collection of React optimization patterns packaged as Agent Skills. These skills work with AI coding assistants like Cursor, Claude Code, and others.

The best part? Installing them is ridiculously simple:

npx add-skill vercel-labs/agent-skills

That's it. One command, and your AI assistant now has access to 40+ React optimization rules, ordered by impact.

What the Agent Uncovered

We all miss things. Sometimes we're in a rush to ship, or we simply overlook details assuming they "don't matter much."

The agent caught several things I had either ignored or discarded due to time constraints. It wasn't just "fixing bugs"—it was highlighting standard practices I had drifted away from. Now, thanks to the Vercel Agent Skill , I feel much more confident and calm about the code I'm shipping.

These aren't micro-optimizations. They're the kind of improvements that show up as:

Faster perceived performance (users feel the difference)
Better accessibility scores (more users can use your site)
Lower maintenance costs (consistent patterns across the codebase)

The agent skills framework prioritizes fixes by impact:

CRITICAL : Eliminate waterfalls, reduce bundle size
HIGH : Server-side performance, client-side fetching
MEDIUM : Re-render optimization
LOW : Advanced patterns

This ordering is brilliant. It prevents you from optimizing the wrong thing. No point in shaving microseconds off a loop if you have a 600ms request waterfall.

How to Use This in Your Projects

Here's my recommendation:

Step 1: Install the Skills

npx add-skill vercel-labs/agent-skills

Step 2: Ask Your AI Assistant

Tell your coding assistant:

"Review this project using React best practices from Vercel"

Step 3: Prioritize by Impact

Don't try to fix everything at once. Start with CRITICAL issues:

Are you blocking async work unnecessarily?
Is your bundle size growing?
Are components re-rendering too much?

Step 4: Verify the Changes

Always run your tests and build:

npm run lint
npm run build

Make sure nothing broke. Performance improvements shouldn't introduce bugs.

What I Learned

The most valuable lesson? Performance work compounds. Every small regression you ship today becomes a long-term tax on every user session.

By applying these best practices early, you're not just making your app faster today. You're preventing future slowdowns.

Think of it like this: Would you rather fix 40 performance issues in one focused session, or discover them one by one over the next year when users complain?

Try It Yourself

If you maintain a React or Next.js project, I highly recommend trying this. The setup takes 30 seconds, and the insights are invaluable.

Here's what to do:

Install the agent skills: npx add-skill vercel-labs/agent-skills
Ask your AI assistant to review your code
Start with the CRITICAL fixes
Verify everything still works

You'll be surprised at what you find. I know I was.

Have you tried agent skills in your projects?

Resources

Protect Your API: Why You Need Rate Limiting (and How to Add It)

Dany Paredes — Wed, 14 Jan 2026 00:00:00 +0000

Yesterday, I was talking to a friend about the importance of security when building applications. We were discussing a classic feature: a newsletter subscription form.

You know the drill. You create an endpoint, say /api/subscribe, and you add the usual validations:

Is the email field empty?
Does it look like a real email (regex)?
Is this person already subscribed?

"That's enough, right?" he asked.

"Well," I said, "it's enough to keep your database clean, but it's not enough to keep your server alive."

The problem isn't just bad data—it's volume. Without protection, a simple bot script could hit your endpoint 10,000 times in a minute. Even if you reject the bad emails, your database is still working hard to check if they exist. Your server is still parsing JSON. You are paying for those cycles.

What problem does this solve for us as developers? Rate limiting ensures that no single user (or bot) can degrade the experience for everyone else or bankrupt us with server costs.

The Concept

Think of Rate Limiting as a bouncer at a club. The bouncer doesn't care if your ID is valid (that's the data validation); he cares about how many people are trying to push through the door at once. He keeps the flow manageable.

The "Do It Yourself" Approach (And Why It Fails)

Let's say we want to limit users to 5 requests every 60 seconds.

Your first instinct might be: "I don't need a fancy library. I'll just use a Javascript Map in memory."

It might look something like this in a Next.js API route:

const rateLimitMap = new Map();

export async function POST(request: Request) {
  const ip = request.headers.get("x-forwarded-for") || "127.0.0.1";
  const now = Date.now();
  const windowSize = 60 * 1000; // 60 seconds

  // Get user's recent request timestamps
  const userHistory = rateLimitMap.get(ip) || [];

  // Filter out timestamps older than 60 seconds
  const recentRequests = userHistory.filter(timestamp => now - timestamp < windowSize);

  if (recentRequests.length >= 5) {
    return Response.json(
      { error: "Too many requests, slow down!" }, 
      { status: 429 }
    );
  }

  // Record this request
  recentRequests.push(now);
  rateLimitMap.set(ip, recentRequests);

  // ... proceed with subscription logic ...
  return Response.json({ message: "Subscribed!" });
}

The Problem with "In-Memory"

This code works perfectly... on your local machine. But the moment you deploy this to a serverless environment like Vercel or AWS Lambda, it breaks.

Statelessness : Serverless functions spin up and die. Next time the function runs, your rateLimitMap is empty.
Multiple Islands : If your app scales to handle traffic, you might have 50 different instances running at once. Instance A doesn't know that the user just hit Instance B 500 times.

So, how do we share this "memory" across thousands of short-lived server instances?

The Solution: Redis (Upstash)

To solve this, we need an external memory—a database that is fast enough to check "has this IP made 5 requests?" in milliseconds. Redis is the standard tool for this.

For serverless apps, I love using Upstash. It's Redis over HTTP, so you don't need to manage persistent connections.

Setup

Let's clean up our naive code. First, install the specialized library:

npm install @upstash/ratelimit @upstash/redis

Grab your UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN from the Upstash Console and add them to your .env file.

Implementation

Now, protecting our /api/subscribe endpoint is incredibly simple. We don't need to write logic for sliding windows or timestamps; the library handles it.

// app/api/subscribe/route.ts
import { NextResponse } from "next/server";
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
import { headers } from "next/headers";

// Create a unified limiter instance
const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(5, "60 s"), // 5 requests per 60s
  analytics: true,
});

export async function POST(request: Request) {
  // Use IP as key (or user ID if logged in)
  const ip = headers().get("x-forwarded-for") || "127.0.0.1";

  // Ask Redis: "Can this guy pass?"
  const { success } = await ratelimit.limit(ip);

  if (!success) {
    return NextResponse.json(
      { error: "Too many requests. Please try again later." },
      { status: 429 }
    );
  }

  // ✅ Safe to process the subscription
  const body = await request.json();

  // Example subscription logic
  console.log(`Subscribing email: ${body.email}`);

  return NextResponse.json({ message: "Successfully subscribed!" });
}

So far we've set up the limiter and applied it to a route. This moves the state to Upstash, so it doesn't matter if your API is running on one server or a thousand Lambda functions across the globe.

Summary

Rate Limiting is not just a "nice to have" feature; it's a fundamental security practice.

We learned that functional validation (regex) isn't enough to protect resources.
We saw why in-memory solutions fail in modern serverless architectures.
We built a robust, distributed rate limiter with Redis.

Challenge

Now that you have this working, try to extend it:

Can you create different limits for free vs. premium users? ($user.plan === 'pro')
Try blocking specific IPs permanently if they exceed a "ban" threshold.

Happy coding!

My Newsletter Went to Spam (Here is How I Fixed It for Free)

Dany Paredes — Wed, 14 Jan 2026 00:00:00 +0000

It started with a WhatsApp message from a friend: "Hey checking your blog, I subscribed but I never got the confirmation email."

I told him to check his Spam folder. "Yep, it's there," he replied.

That was a red flag. I rushed to check my Kit (ConvertKit) dashboard and saw the trend: my open rates had dropped significantly since I migrated. I was sending emails from my personal my-personal-email@gmail.com address, which I thought was fine.

It turns out, I was breaking the rules of the internet.

The Problem: DMARC and "Fake" Senders

Gmail and Yahoo recently updated their spam rules. Basically, they say: "If an email claims to be from @gmail.com but comes from a marketing server (like Kit/Mailchimp), it's fake."

To fix this, you need two things:

A Custom Domain (like danywalls.com).
Authentication (DKIM/SPF) to prove you own that domain.

The catch? I didn't want to pay $6/month for Google Workspace just to have hola@danywalls.com. I already pay for my domain and hosting; I wanted a free solution.

The Solution: Cloudflare Email Routing

Since I host my blog on Vercel but manage my DNS with Cloudflare , I discovered a hidden gem: Cloudflare Email Routing.

This allows you to create professional email addresses (aliases) that forward automatically to your personal Gmail.

Inbound : People email hola@danywalls.com -> Cloudflare forwards to my-personal-email@gmail.com.
Outbound : Kit sends as hola@danywalls.com -> We verify the DNS so Gmail trusts it.

What problem does this solve for us? We get a professional, deliverable email setup for $0/month.

Implementation Guide

Here is how I set it up in 10 minutes.

1. Enable Email Routing in Cloudflare

Go to your Cloudflare Dashboard -> Email -> Email Routing.

Click "Get Started" and define your custom address.

Custom Address : hola (creates hola@danywalls.com)
Destination : your-personal@gmail.com

Cloudflare will send you a verification email to your personal Gmail. Click the link, and you are verified.

Note: Cloudflare will ask to add some DNS records (MX and TXT) automatically. Let it do it.

2. Verify Your Domain in Kit

Now we need to tell Kit that it's allowed to send emails as this new address.

Go to Kit Settings -> Email.
Add your Verified Sending Domain (danywalls.com).
Kit will give you 3 CNAME records.

Pro Tip: If you are already using Cloudflare, Kit has a button to configure this automatically. It opens a pop-up, you log in to Cloudflare, and acts as a "One-Click install". It saves you from copy-pasting manually.

3. The "Gotcha" with Cloudflare Proxy

This is where I got stuck. When adding these CNAME records to Cloudflare:

MAKE SURE TO TURN OFF THE ORANGE CLOUD (Proxy).

Set them to "DNS Only" (Grey Cloud). If you leave the proxy on, Kit cannot verify the records because Cloudflare hides the real values.

4. Update Your Sender Identity

Once the domain is verified (it takes about 5 minutes), go back to Kit and add hola@danywalls.com as your sender.

Now, when you send a newsletter:

It comes from a professional domain.
It creates a "pass" on DMARC checks.
It lands in the Inbox, not Spam.

Summary

Deliverability is "invisible" tech debt. You don't see it until your open rates crash.

We learned that sending marketing emails from @gmail.com is a bad practice.
We built a forwarding system using Cloudflare Email Routing.
We saved money by avoiding a paid rigorous email hosting plan.

So far we've fixed the technical setup. Now, go double-check your own open rates—you might be surprised.

Happy coding!

Make GitHub Work for You: GitHub MCP and Dependabot

Dany Paredes — Sat, 10 Jan 2026 00:00:00 +0000

Lately, I wanted to automate my daily work. I need to see my tasks quickly, report bugs with good details, and stop worrying about security holes in my code.

The problem? I was always switching between my code editor and the GitHub website. Creating Pull Requests (PRs), adding labels, writing bug reports, checking for updates—it felt like boring work that stopped my flow.

Then I found GitHub MCP and Dependabot. Now my work is automatic, and I almost never use the GitHub website.

What I Wanted to Automate

I needed three things: easy interaction with GitHub (PRs, comments, tags, issues), automated security monitoring, and control over when and how updates happen. GitHub MCP handles the first part, Dependabot handles security, and together they've transformed how I work.

GitHub MCP: Easy GitHub Interaction

GitHub MCP lets me work with GitHub easily. I can create PRs, write comments, add tags, and open issues—all without leaving my code editor.

Think of GitHub MCP as a bridge. It connects your AI-powered editor (like Cursor) directly to GitHub.

Instead of opening Chrome or Safari, you just ask your AI:

"Create a PR with these labels"
"Add a comment to issue #42"
"Open a bug report for this error"
"What tasks do I have left?"

Everything happens right inside your editor.

Setting Up GitHub MCP in Cursor

Step 1: Get Your Token

Go to GitHub's token settings.
Click Generate new token (classic).
Select these permissions (scopes): repo, workflow, read:org.
Copy the token.

Step 2: Configure Cursor

Open ~/.cursor/mcp.json and add:

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer YOUR_GITHUB_PAT"
      }
    }
  }
}

Replace YOUR_GITHUB_PAT with your token, save, and restart Cursor.

Step 3: Verify

Go to Settings → Tools & Integrations → MCP Tools.
Look for a green dot using "github".
Test it by asking: "List my GitHub repositories".

Checkpoint: Now your editor can talk to GitHub. You can create PRs and issues just by chatting.

How I Use This Every Day

Once it is set up, I use it all the time. I stay in my editor while the AI does the boring GitHub work.

But How Do I Automate Security?

GitHub MCP helps with my tasks, but what about security? That is where Dependabot helps.

Dependabot is a tool that watches your project libraries (dependencies) for security problems. It does three things:

Finds security issues.
Creates PRs to fix them.
Keeps your libraries up to date.

Here is the trick: by default, Dependabot sends PRs to the main branch. If you use a develop branch for your work, this breaks your flow.

But we can fix this. We can tell Dependabot to use develop. We can also tell it to run only once a week, so it doesn't bother us every day.

Setting Up Dependabot

Enable Dependabot

Go to your repository on GitHub.
Click Settings → Code security and analysis.
Enable Dependabot alerts , security updates , and version updates.

Configure Dependabot

Create .github/dependabot.yml with this configuration:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
    open-pull-requests-limit: 5
    target-branch: "develop"
    commit-message:
      prefix: "chore"
    labels:
      - "dependencies"

Why these settings?

target-branch: "develop": Sends updates to your development branch, not production.
open-pull-requests-limit: 5: Prevents too many PRs at once.
schedule: weekly: Checks only on Mondays, so you don't get notifications every day.

Commit and push:

git add .github/dependabot.yml
git commit -m "chore: configure dependabot"
git push

Handling Dependabot PRs

When Dependabot creates a PR:

Read the description.
Check the changes (diff).
Make sure tests pass.
Merge or close it.

I usually merge security fixes fast, but I wait until the end of the week for normal updates.

What We Learned

Automation is key. Simplifying tasks improves your speed and reduces mistakes.

GitHub MCP handles your daily work—creating PRs, comments, and issues from your editor.
Dependabot handles security—watching your libraries and fixing problems automatically.

Together, they give you what every developer needs: less boring work and better security.

Challenges

Ready to try it?

Connect MCP : Set up the GitHub MCP server in your editor today.
Configure Dependabot : Add the .github/dependabot.yml file to one of your projects using the develop branch.
Try a command : Ask your AI to "List my open issues" and see what happens.

Let the tools do the work for you!

Why I Switched from Loom to Cap

Dany Paredes — Sat, 10 Jan 2026 00:00:00 +0000

For years, Loom was my go-to tool for screen recordings. Whether I was explaining a bug to my team, creating quick tutorials, or sharing feedback on a pull request, Loom made it easy. But recently, I found myself looking for something better.

What problem does this solve? We need tools that are fast, reliable, and don't break the bank. We also value tools that respect our privacy and give us control over our data.

After trying Cap.so, I made the switch. Let me tell you why.

What is Cap?

Think of Cap as the open-source alternative to Loom. It's lightweight, powerful, and works across platforms. But what makes it special isn't just that it's open source—it's how it fits into a developer's workflow.

Cap gives you two modes that fit different workflows. When I need something quick, I use Instant Mode —just record, stop, and share. Your video is live in seconds with auto-generated captions and summaries. But when I need that extra polish for a client presentation or a tutorial, Studio Mode gives me full editing capabilities to make everything perfect.

Why I Made the Switch

1. Screenshots and Screen Recording in One Tool

One thing that immediately caught my attention was Cap's ability to handle both screenshots and screen recordings. We often need to quickly capture what's on our screen—sometimes a static image is enough, sometimes we need a video.

Before Cap, I was juggling multiple tools. I used Gifox for quick GIF captures and Shottr for screenshots with annotations. Both are great tools, but switching between them broke my flow. With Cap, I don't need to switch between different tools anymore—everything is in one place.

Screenshot Mode isn't just a basic grabber. It includes a dedicated editor that I use all the time. I can add shapes and text annotations to highlight what matters, apply sensitive masking when I need to hide API keys or passwords, adjust backgrounds and padding to make screenshots look professional, and then export or share everything with a single click.

I can take a screenshot when I need to show a quick UI state, or record a video when I need to explain a complex flow. This might seem small, but it saves me time throughout the day.

2. Easy Sharing That Just Works

Sharing videos should be simple. With Cap, you get shareable links that work instantly. What I love is that the tool automatically generates captions, titles, summaries, and even chapters for longer videos. This means when I share a recording with my team, they can quickly understand what it's about without watching the entire video. For async collaboration, this is a game-changer.

Another feature I absolutely love is the auto-zoom cursor. When you're recording tutorials or demos, Cap automatically zooms in on your cursor when you click, making it crystal clear what you're doing. This is perfect for creating professional-looking tutorials without any post-production work. Here's a quick demo I recorded:

3. The Price That Makes Sense

Here's the deal: Loom Business costs $12.50/user/month. Cap's Desktop License? $29/year or $58 lifetime. You do the math.

Cap has three tiers: Free (unlimited local recording, 5-min shareable links), Desktop License ($29/year for commercial use), and Cap Pro ($8.16/month for unlimited sharing and AI features). For solo developers, the lifetime license is a no-brainer. For teams, Cap Pro is still way cheaper than Loom.

Real-World Use Cases

I use Cap daily for bug reports (show, don't tell), code reviews (walk through changes with auto-generated summaries), quick tutorials for new team members, and client demos. The auto-zoom cursor and captions make everything look professional without any editing.

What About the Free Version?

The free version of Cap is quite generous. You get unlimited local recordings, shareable links up to 5 minutes, export to MP4 or GIF, and even Studio Mode with the full editor. For many developers, this is enough. I used the free version for weeks before upgrading. You only need to upgrade if you need unlimited cloud storage, longer shareable links, AI features like auto titles and transcriptions, custom domain support, or team spaces.

My Recommendation

If you're looking for a screen recording tool, give Cap a try. The free version is generous enough to test it out, and the Desktop License at $29/year is incredible value. For teams needing AI features and unlimited sharing, Cap Pro at $8.16/month per user is significantly cheaper than Loom.

The only reason to stick with Loom? If your entire team is already locked in and migration feels too painful. Otherwise, download Cap using my referral link and see the difference for yourself.

Try It Yourself

Ready to make the switch? Here's what to do:

Download Cap : Visit cap.so and download for your platform
Try the free version : Record a few videos and see how it feels
Compare with your current tool : Use both for a week and see which fits your workflow better
Upgrade if needed : If you like it, the Desktop License is a no-brainer at $29/year

Final Thoughts

After years of using Loom, switching to Cap was one of the best decisions I made. Screenshots and screen recording in one tool, incredible pricing, and the freedom to own my data—it just works.

Give Cap a try and let me know what you think. I'm curious to hear if it fits your workflow as well as it fits mine.

Forem: Dany Paredes

How to Create One-Click MCP Installation Deep Links for Cursor and VS Code

Why Deep Links?

The Goal: From JSON to One-Click

Step 1: Cursor Protocol (Base64)

Step 2: VS Code Protocol (URL Encoded)

The Solution: A Reusable Script

Try it: One-Click unsplashx Installation

Takeaway

Being a Writer in the Era of Writer/AI Slop

My Experience is My Best Asset

Refactoring to a Human Tone

But I love the AI

Final Reflections

Moving from Vercel to Google Cloud: Why and How I Migrated My Next.js Blog

Preparing for Docker

Moving to Google Cloud Run

The CLI Setup

Building and Deploying

Managing Secrets (The Professional Way)

Connecting the Domains (Double Trouble)

"Git Push to Deploy" with GitHub Actions

Lessons Learned

Dockerizing Next.js: The Hidden Challenges

Vercel vs. Self-Managed Architecture

The Technical Wall: Environment Variables

Build-Time Variables (NEXT_PUBLIC_)

Runtime Variables (Private)

The Scenario

Moving to Docker

The Solution: ARG and ENV

What about private variables?

Security Concerns

Recap

WebMCP: AI Agents are your new web visitors

What is WebMCP?

Two ways to use it:

Setting Up Your Lab

The HTML Way

The JavaScript Way

Is it Safe?

Go Explore!

Moving to Cybersecurity from a Software Developer Role

SIEM: More Than Just Logs

IdP & HIPAA: Identity vs. Compliance

What IdP ?

Break Glass or The Emergency Key

What HIPAA ?

PII vs. SPII: Data Types Matter

What PII (Personally Identifiable Information) is

What SPII (Sensitive PII) ?

The CIA Triad: The Core Principles

The Frameworks: NIST CSF & Security Controls

What NIST CSF (Cybersecurity Framework) is

What CISSP ?

The Playbook: Response Plans

What a Playbook ?

Quick Recap

MCP One-Click Installers: From Pain to One-Click Magic

The "A-ha!" Moment

Making Installation Invisible

How it works (The 10-second version):

The Result: One-Click Joy

Why this matters

How I Improved My Blog with Vercel Agent Skills and React Best Practices

The Problem: Good Code That Could Be Great

Why Vercel's Experience Matters

The Solution: One Command, Instant Expertise

What the Agent Uncovered

How to Use This in Your Projects

Step 1: Install the Skills

Step 2: Ask Your AI Assistant

Step 3: Prioritize by Impact

Step 4: Verify the Changes

What I Learned

Try It Yourself

Resources

Protect Your API: Why You Need Rate Limiting (and How to Add It)

The Concept

The "Do It Yourself" Approach (And Why It Fails)

Build-Time Variables (`NEXT_PUBLIC_`)