DEV Community: Eduardo Villão

AI doesn't fix direction. It accelerates the one you already have

Eduardo Villão — Mon, 29 Jun 2026 14:57:20 +0000

If you're heading in the wrong direction, AI will get you there faster.

Years of research on how to get the best out of people. Decades of literature on management, leadership, processes, teams, feedback, and organizational culture.

And now companies are dropping AI into the middle of all that thinking it fixes things.

It doesn't.

AI doesn't correct your route. It accelerates the one you already have.

If your team delivers well, with clear processes and good communication, AI will amplify that. Results get better, faster, with less friction.

If your team delivers poorly, with messy processes and weak management, AI will amplify that too. Results get worse, faster, with more invisible friction.

The tool has no opinion about direction. It just accelerates.

What people think AI will fix

Some examples of what happens when you put AI on top of broken structure:

"Let's use AI to document our processes."
Great. But if the processes don't exist or are a mess, AI will document the mess with polished language and an air of authority. Now the mess has a well-formatted PDF.

"Let's use AI to give feedback to the team."
But if the manager doesn't know what they want from the team, AI will generate vague feedback with the right words. It looks like feedback. It isn't.

"Let's use AI to speed up onboarding."
But if onboarding has no structure, now you have bad onboarding faster. The new hire gets lost in half the time.

The pattern is always the same: AI executes well what you ask for. The problem is you don't know exactly what to ask for.

What was always the problem is still the problem

AI didn't create new problems in companies. It exposed the ones that were already there.

Teams that already had standards, clarity, and good management keep delivering well, now with more speed. Teams that didn't keep delivering poorly, now with more speed too, and with the illusion that they're evolving because they're using new tools.

AI adoption has become a metric for modernity. But modernity isn't installing tools. It's knowing how to use them with intention, inside a structure that actually works.

What actually needs to happen first

Before adding AI to any process, it's worth asking:

Does this process work without AI? If it doesn't, AI won't fix it. It'll just execute what doesn't work with more efficiency.

Does whoever is managing this process know what they want as an outcome? AI only delivers well when the person asking knows exactly what they're asking for. Vague management leads to vague prompts leads to vague output.

Does the team have clarity on the problem they're solving? AI amplifies execution. If execution is heading in the wrong direction, it'll amplify the mistake.

The one sentence that sums it all up

If you're heading in the wrong direction, AI will get you there faster.

AI is an accelerator. Not a course corrector. Not a substitute for management. Not a solution for missing process.

It's a powerful tool that will get you faster to wherever you were already going.

Before adding speed, make sure the direction is right.

IA não corrige direção. Ela acelera a que você já tem

Eduardo Villão — Mon, 29 Jun 2026 14:55:44 +0000

Se você tá indo na direção errada, a IA vai te fazer chegar errado mais rápido.

Anos de estudo sobre como extrair o melhor das pessoas. Décadas de literatura sobre gestão, liderança, processos, times, feedback, cultura organizacional.

E agora as empresas estão adicionando IA no meio disso tudo e achando que o problema tá resolvido.

Não tá.

A IA não corrige rota. Ela acelera a rota que você já tem.

Se o seu time entrega bem, com clareza de processo e comunicação boa, a IA vai amplificar isso. O resultado vai ser melhor, mais rápido, com menos atrito.

Se o seu time entrega mal, com processo confuso e gestão fraca, a IA vai amplificar isso também. O resultado vai ser pior, mais rápido, com mais atrito invisível.

A ferramenta não tem opinião sobre a direção. Ela só acelera.

O que as pessoas acham que a IA vai resolver

Alguns exemplos do que acontece quando alguém coloca IA em cima de estrutura ruim:

"Vamos usar IA pra documentar nossos processos."
Ótimo. Mas se os processos não existem ou são uma bagunça, a IA vai documentar a bagunça com linguagem bonita e ar de autoridade. Agora a bagunça tem um PDF bem formatado.

"Vamos usar IA pra dar feedback pra equipe."
Mas se o gestor não sabe o que quer do time, a IA vai gerar feedback vago com palavras certas. Parece feedback. Não é.

"Vamos usar IA pra acelerar o onboarding."
Mas se o onboarding não tem estrutura, agora você tem onboarding ruim mais rápido. O novo funcionário fica perdido em metade do tempo.

O padrão é sempre o mesmo: a IA executa bem o que você pede. O problema é que você não sabe exatamente o que precisa pedir.

O que sempre foi o problema continua sendo o problema

A IA não criou problemas novos nas empresas. Ela escancarou os que já existiam.

Times que já tinham padrão, clareza e boa gestão continuam entregando bem, agora com mais velocidade. Times que não tinham continuam entregando mal, agora com mais velocidade também, e com a ilusão de que estão evoluindo porque usam ferramentas novas.

A adoção de IA virou métrica de modernidade. Mas modernidade não é instalar ferramenta. É saber usá-la com intenção, dentro de uma estrutura que funciona.

O que realmente precisa acontecer antes

Antes de colocar IA em qualquer processo, vale a pena perguntar:

Esse processo funciona sem IA? Se não funciona, a IA não vai consertar. Vai só executar o que não funciona com mais eficiência.

Quem está gerindo esse processo sabe o que quer como resultado? A IA só entrega bem quando quem pede sabe exatamente o que está pedindo. Gestão vaga gera prompt vago gera output vago.

O time tem clareza sobre o problema que está resolvendo? IA amplifica execução. Se a execução está indo na direção errada, ela vai amplificar o erro.

A frase que resume tudo

Se você tá indo na direção errada, a IA vai te fazer chegar errado mais rápido.

A IA é um acelerador. Não é um corretor de rota. Não é um substituto pra gestão. Não é uma solução pra falta de processo.

É uma ferramenta poderosa que vai fazer você chegar mais rápido aonde você já estava indo.

Antes de adicionar velocidade, garanta que a direção está certa.

Stop Paying AI to Forget What You Already Know

Eduardo Villão — Fri, 26 Jun 2026 17:25:59 +0000

I'm currently building many apps/things in parallel: a form backend, a WhatsApp review alert tool, my WordPress plugins and a few others. Every single one needs Stripe. Every single one needs transactional emails. Most of them use Cloudflare Workers, D1, and R2.

For a while, I let AI write those integrations from scratch every time.

That was expensive. And dumb.

What Was Actually Happening

When you ask Claude Code (or any coding AI) to "integrate Stripe checkout," it doesn't teleport to a finished implementation. It explores. It writes, evaluates, adjusts. It handles errors, then reconsiders the error handling. It figures out where to put the webhook handler, what metadata to attach, how to structure the response.

All of that costs tokens. And time.

Now multiply that by every project. Every time I started something new, the AI was rebuilding the same mental model for integrations I had already solved.

The code usually came out fine. But I was paying in tokens and in review time for decisions that were already made.

The Fix: `ai-boilerplates`

I created a private repo called ai-boilerplates. The idea is simple: every integration pattern I've solved and validated goes in there, ready to be used as a reference.

ai-boilerplates/
  stripe/
    checkout.ts
    webhook.ts
    customer.ts
  resend/
    transactional.ts
  cloudflare/
    d1-client.ts
    r2-upload.ts
  auth/
    jwt.ts
    session.ts

But the important part isn't just the code. It's the context block at the top of each file:

/**
 * BOILERPLATE: Stripe Checkout Session
 *
 * Use: single product or dynamic price_id checkout
 * Don't use: subscriptions (see stripe/subscription.ts)
 *
 * Decisions already made:
 * - success_url always redirects to /dashboard with session_id
 * - metadata always includes userId to reconcile in webhook
 * - errors return 500 with generic message, never expose Stripe details
 */

That block is the real value. The AI doesn't just copy code. It understands intent, constraints, and prior decisions. It skips the exploration phase entirely.

Wiring It Into Claude Code

I added a dedicated rule file at ~/.claude/rules/ai-boilerplates.md:

## ai-boilerplates

Repo at ~/ai-boilerplates/ contains standard boilerplate implementations.

Before implementing any new integration, check if a boilerplate exists.
If it does, use it as the base, don't rewrite from scratch.

When using a boilerplate:
- Adapt to the project context, don't copy blindly
- Preserve the documented decisions
- If you need to deviate from a decision, comment why in the code

When writing code that could become a boilerplate, suggest adding it to the repo.

Keeping it in rules/ rather than CLAUDE.md is intentional. CLAUDE.md is for general project context: stack, conventions, who you are. Rules are modular and focused, each with a single responsibility.

Now every Claude Code session across every project starts with that context loaded. The AI knows to check before it builds.

What Changed

The difference is noticeable in a few ways:

Fewer tokens on solved problems. The AI isn't re-exploring Stripe webhook verification or Resend error handling. It reads the boilerplate, adapts it, moves on.

More consistent code across projects. The same decisions (metadata structure, error response shape, logging pattern) show up the same way everywhere. That matters when you're context-switching between four codebases.

Less review time. I'm not second-guessing whether the AI made the right call on something I've already thought through. The call was made once, documented, and that's it.

The Cost Angle Is Real

AI inference isn't free, and it's only going to get more complex as agents and subagents become the norm. Running parallel agents on a large feature already costs real money. Anything that reduces redundant work compounds across every session, every project, every team member who touches the same stack.

A boilerplate repo is one of the cheapest optimizations you can make. It costs you an hour to set up and pays back on every single integration after that.

What Goes In a Good Boilerplate

Not every piece of code deserves to be a boilerplate. A good candidate is something you:

Integrate in more than one project
Have already debugged at least once
Have made explicit architectural decisions about

If all three are true, document it. If you're just writing throwaway code, don't bother.

Context Is the Real Asset

Most developers think about AI productivity in terms of prompts: how to ask better questions, how to get better output. That's valid, but it misses the bigger lever.

The real asset is structured context. Boilerplates are one layer. ADRs are another. Rules that encode how your team works, shared memory of why decisions were made. When that context exists and is loaded into every session, the AI isn't starting from scratch. It's building on top of what you've already figured out.

That compounds. Every solved problem makes the next one cheaper. Every documented decision saves tokens, review time, and the cognitive overhead of explaining your conventions again.

A ai-boilerplates repo is a small, concrete place to start. But the habit it builds is what matters.

How I migrated a WordPress site to Cloudflare Pages using AI (and what broke)

Eduardo Villão — Fri, 26 Jun 2026 14:54:40 +0000

WordPress does everything. That's both the problem and the solution.

I've spent years in the WordPress ecosystem: plugins, themes, WooCommerce, Gutenberg, the whole thing. It's a mature, powerful platform that handles complex cases really well. I'm not here to say it's bad.

But with AI there's a category of site where it became overkill: landing pages, product sites, company pages, portfolios. Pages that are essentially static content with a contact form. You're running a full PHP stack, managing plugin updates, paying for server hosting, all for a page that could be pure HTML served from the edge.

For those cases, I've started migrating everything. Destination: Cloudflare Pages. The process: largely AI-assisted.

Here's how it went.

Why Cloudflare Pages

A few reasons it won over Vercel, Netlify, and GitHub Pages for this project:

Global edge network with zero cold starts
Free tier is genuinely generous — unlimited requests, unlimited bandwidth
Cloudflare Workers for any dynamic logic that survives the migration
D1 for lightweight database needs if they come up later
Everything in one ecosystem

If you're already on Cloudflare for DNS (most people are), the migration path is shorter than it looks.

The stack after migration

Static site generator: Astro — outputs pure HTML, partial hydration for any interactive component, excellent build performance
Hosting: Cloudflare Pages
Forms: FormRoute — more on this later
AI used: Claude for content transformation, component generation.

Step 1 — Export and inventory the WordPress content

First step: understand what you actually have.

# Export everything from WordPress
# Admin → Tools → Export → All content
# Downloads an XML file

The XML export gives you posts, pages, categories, tags, authors, and media references. It doesn't give you the actual media files — those come separately.

I fed the XML export to Claude and asked it to:

List every post and page with title, slug, date, and category
Identify which content was actively trafficked vs stale
Flag any posts with embedded shortcodes that would need manual attention

The output was a clean inventory in about 30 seconds. On a large site this alone saves hours.

Prompt I used:

Here's a WordPress XML export. Give me:
1. A table of all posts: title, slug, publish date, category, word count
2. A list of all shortcodes used across the content
3. Any embedded iframes or third-party scripts you can identify
Format as markdown.

Step 2 — Convert content to Markdown

WordPress stores content as HTML with shortcodes mixed in. Astro wants Markdown with frontmatter. Claude handled most of this conversion automatically.

Prompt for content conversion:

Convert this WordPress post HTML to Markdown with Astro frontmatter.
Preserve all headings, links, images, and formatting.
Output the frontmatter with: title, description, pubDate, slug, tags.
Flag any shortcodes you can't convert with a [MANUAL REVIEW NEEDED] comment.

For 80% of posts, the output was clean and ready to use. The remaining 20% had:

Contact form shortcodes ([contact-form-7]) — needed replacement
Gallery shortcodes ([gallery ids="..."]) — needed manual rebuild
Plugin-specific shortcodes — varied by plugin

The shortcode problem is where most WordPress migrations get stuck. More on the form replacement below.

Step 3 — Set up Astro on Cloudflare Pages

npm create astro@latest my-site
cd my-site
npx astro add cloudflare

The Cloudflare adapter handles the build output format for Pages. After that, connect your GitHub repo to Cloudflare Pages and it deploys on every push.

Basic astro.config.mjs:

import { defineConfig } from 'astro/config'
import cloudflare from '@astrojs/cloudflare'

export default defineConfig({
  output: 'static',
  adapter: cloudflare(),
})

For a pure static site, output: 'static' is what you want. No server-side rendering, no cold starts, pure HTML at the edge.

Step 4 — Migrate content and assets

I asked Claude to generate a migration script that:

Read the WordPress XML export
Created individual .md files for each post with proper frontmatter
Renamed media files to a clean slug-based convention
Updated internal image references in the content

// Claude-generated migration script (simplified)
import { parseStringPromise } from 'xml2js'
import { writeFileSync, mkdirSync } from 'fs'
import { slugify } from './utils'

const xml = readFileSync('export.xml', 'utf-8')
const data = await parseStringPromise(xml)
const posts = data.rss.channel[0].item

for (const post of posts) {
  const title = post.title[0]
  const content = post['content:encoded'][0]
  const date = post.pubDate[0]
  const slug = post['wp:post_name'][0]

  const frontmatter = `---
title: "${title}"
pubDate: ${new Date(date).toISOString()}
slug: "${slug}"
---\n\n`

  writeFileSync(
    `src/content/blog/${slug}.md`,
    frontmatter + convertToMarkdown(content)
  )
}

For media, I kept the files in the Cloudflare Pages public folder and updated the references in the Markdown files. For larger sites with heavy media, R2 is worth looking at, but for most company pages and landing pages, serving assets directly from Pages is enough. Claude generated the find-and-replace script for URL rewriting.

Step 5 — The forms problem

This is where every WordPress-to-static migration hits the same wall.

Contact Form 7, Gravity Forms, WPForms — they all depend on PHP running on the server. Move to static and they stop working entirely. There's no server to process the submission.

The options I evaluated:

Write a Cloudflare Worker — possible, but you're now maintaining a backend for what is essentially a contact form. Wiring up email delivery, validation, spam protection. More moving parts than I wanted.

Use a form backend service — drop one endpoint into the form, the service handles everything. No server, no maintenance.

I went with FormRoute. The migration from Contact Form 7 was straightforward:

Before (Contact Form 7 shortcode):

[contact-form-7 id="123" title="Contact form"]

After (Astro component):

---
// src/components/ContactForm.astro
---

<form action="https://api.formroute.dev/f/YOUR_KEY" method="POST">
  <input type="text" name="name" placeholder="Your name" required />
  <input type="email" name="email" placeholder="Your email" required />
  <textarea name="message" placeholder="Your message" required></textarea>

  <div class="cf-turnstile" data-sitekey="YOUR_TURNSTILE_KEY"></div>

  <input type="text" name="_honeypot" style="display:none" tabindex="-1" />

  <button type="submit">Send</button>
</form>

<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async></script>

Spam protection runs via Cloudflare Turnstile, invisible to real users. Submissions go to the FormRoute dashboard and trigger an email notification. Free tier covers 1,000 submissions a month.

Step 6 — Redirects

WordPress URLs don't always match what you want for a static site. You need to redirect old URLs to new ones so you don't lose SEO or break existing links.

Cloudflare Pages handles redirects via a _redirects file in the public folder:

/old-post-url/ /new-post-url/ 301
/category/news/ /blog/ 301
/?p=123 /post-slug/ 301

I fed Claude the old URL list and the new slug list and asked it to generate the redirects file. It handled the mapping in one pass.

For WordPress sites with ?p=123 style URLs, the pattern is:

/?p=:id /blog/:slug 301

You'll need to map each ID to its slug manually or via a script — Claude can generate that script from the XML export.

What broke (honest list)

Comments — WordPress comments don't have a static equivalent. I replaced them with nothing. If comments matter for your site, look at Giscus (GitHub Discussions-based) or just remove them.

Search — WordPress search is server-side. Static sites need client-side search. Pagefind works well with Astro and takes 10 minutes to set up.

WooCommerce — if your WordPress site has ecommerce, this migration path doesn't apply. WooCommerce requires a server. Static + Shopify Buy Button or a headless approach is the alternative.

Some SEO plugins — Yoast SEO data lives in WordPress meta. The XML export includes it but you need to map it manually to your Astro frontmatter. Claude can generate the mapping script but it takes some cleanup.

Plugin-specific shortcodes — anything from a plugin that isn't content (countdown timers, booking widgets, interactive maps) needs a replacement. There's no universal answer here — depends on what the plugin did.

The result

Build time: under 10 seconds
Time to first byte: under 50ms globally (Cloudflare edge)
Lighthouse score: 98–100 across the board
Hosting cost: $0 (Cloudflare Pages free tier)
Maintenance: zero PHP, zero plugin updates, zero server patches

The AI-assisted migration took about a day of actual work for a mid-size site (80 posts, 20 pages). Without AI the same work would have taken a week — content conversion and script generation were the biggest time savings.

Summary — what AI helped with

Task	Time without AI	Time with AI
Content inventory	2–3 hours	10 minutes
HTML to Markdown conversion	1 day	10 minutes
Migration scripts	4–6 hours	10 minutes
Redirects file	2 hours	5 minutes
Component generation	3 hours	20 minutes

The parts AI couldn't help with: judgment calls on what to keep, what to cut, and how to handle plugin-specific functionality. That's still on you.

Resources

Astro docs
Cloudflare Pages docs
FormRoute — form backend for static sites

How to add a contact form to a Next.js app without a backend

Eduardo Villão — Fri, 26 Jun 2026 13:34:47 +0000

If you've ever built a Next.js app and needed a contact form, you've probably hit the same wall: you don't want to set up a backend just to receive an email.

You have a few options. You could write an API route, wire up an email service like Resend or SendGrid, handle validation, add spam protection, deploy, and maintain it forever. Or you could use a form backend service and skip all of that.

This tutorial shows the second path. We'll build a working contact form in Next.js — App Router — that validates fields, blocks spam, and delivers submissions to your inbox. No backend, no server to maintain.

We'll use FormRoute as the form backend. Free tier covers 1,000 submissions a month with a dashboard included.

What we're building

A contact form with:

Name, email, and message fields
Client-side and server-side validation
Spam protection with Cloudflare Turnstile
Success and error states
Zero backend code

1. Create your FormRoute endpoint

Go to formroute.dev and create a free account. After signup, create a new form and copy your endpoint URL. It looks like this:

https://api.formroute.dev/f/YOUR_KEY

That's the only setup you need on the FormRoute side.

2. Add Turnstile to your page

FormRoute uses Cloudflare Turnstile for spam protection. It's invisible to real users — no "click the traffic lights" — and it's handled automatically when you add two lines to your page.

Add the Turnstile script to your layout.tsx:

// app/layout.tsx
import Script from 'next/script'

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <body>
        {children}
        <Script
          src="https://challenges.cloudflare.com/turnstile/v0/api.js"
          strategy="lazyOnload"
        />
      </body>
    </html>
  )
}

3. Build the form component

Create a new component app/components/ContactForm.tsx:

'use client'

import { useState, useRef } from 'react'

export default function ContactForm() {
  const [status, setStatus] = useState<'idle' | 'loading' | 'success' | 'error'>('idle')
  const [errors, setErrors] = useState<Record<string, string>>({})
  const formRef = useRef<HTMLFormElement>(null)

  async function handleSubmit(e: React.FormEvent<HTMLFormElement>) {
    e.preventDefault()

    const formData = new FormData(e.currentTarget)
    const data = {
      name: formData.get('name') as string,
      email: formData.get('email') as string,
      message: formData.get('message') as string,
      'cf-turnstile-response': formData.get('cf-turnstile-response') as string,
    }

    // Basic client-side validation
    const newErrors: Record<string, string> = {}
    if (!data.name || data.name.length < 2) newErrors.name = 'Name is required'
    if (!data.email || !data.email.includes('@')) newErrors.email = 'Valid email is required'
    if (!data.message || data.message.length < 10) newErrors.message = 'Message must be at least 10 characters'

    if (Object.keys(newErrors).length > 0) {
      setErrors(newErrors)
      return
    }

    setStatus('loading')
    setErrors({})

    try {
      const res = await fetch('https://api.formroute.dev/f/YOUR_KEY', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(data),
      })

      if (!res.ok) throw new Error('Submission failed')

      setStatus('success')
      formRef.current?.reset()
    } catch {
      setStatus('error')
    }
  }

  if (status === 'success') {
    return (
      <div>
        <h3>Message sent.</h3>
        <p>We'll get back to you as soon as possible.</p>
      </div>
    )
  }

  return (
    <form ref={formRef} onSubmit={handleSubmit} noValidate>
      <div>
        <label htmlFor="name">Name</label>
        <input
          id="name"
          name="name"
          type="text"
          required
        />
        {errors.name && <span>{errors.name}</span>}
      </div>

      <div>
        <label htmlFor="email">Email</label>
        <input
          id="email"
          name="email"
          type="email"
          required
        />
        {errors.email && <span>{errors.email}</span>}
      </div>

      <div>
        <label htmlFor="message">Message</label>
        <textarea
          id="message"
          name="message"
          rows={5}
          required
        />
        {errors.message && <span>{errors.message}</span>}
      </div>

      {/* Turnstile widget — invisible to most users */}
      <div
        className="cf-turnstile"
        data-sitekey="YOUR_FORMROUTE_TURNSTILE_KEY"
      />

      {/* Honeypot — do not remove */}
      <input
        type="text"
        name="_honeypot"
        style={{ display: 'none' }}
        tabIndex={-1}
        autoComplete="off"
      />

      <button type="submit" disabled={status === 'loading'}>
        {status === 'loading' ? 'Sending...' : 'Send message'}
      </button>

      {status === 'error' && (
        <p>Something went wrong. Please try again.</p>
      )}
    </form>
  )
}

4. Use the component

Add the form to any page:

// app/contact/page.tsx
import ContactForm from '@/components/ContactForm'

export default function ContactPage() {
  return (
    <main>
      <h1>Contact</h1>
      <ContactForm />
    </main>
  )
}

5. How server-side validation works

Even though we validate on the client, FormRoute also validates every submission on the server — on the edge, before anything is stored or forwarded.

You configure validation rules once in your FormRoute dashboard:

{
  "email": "required|email",
  "name": "required|min:2",
  "message": "required|min:10"
}

This means even if someone bypasses your frontend and POSTs directly to your endpoint, garbage doesn't reach your inbox. Both layers run independently.

6. What happens after submission

Every valid submission:

Passes Turnstile + honeypot check
Passes server-side validation rules
Gets stored in your FormRoute dashboard (up to 30 days, configurable)
Triggers an email notification to your inbox

You can review, search, and export submissions from the dashboard at any time. If an email notification falls into spam, your submissions are still there.

What you skipped

By using FormRoute instead of a custom API route, you skipped:

Setting up an email service (Resend, SendGrid, SES)
Writing validation logic server-side
Handling spam protection infrastructure
Deploying and maintaining an API endpoint
Debugging email deliverability

The form works. You ship the feature and move on.

Plain HTML version

If you're not using React, the same result in plain HTML:

<form action="https://api.formroute.dev/f/YOUR_KEY" method="POST">
  <input type="text" name="name" required />
  <input type="email" name="email" required />
  <textarea name="message" required></textarea>

  <div class="cf-turnstile" data-sitekey="YOUR_TURNSTILE_KEY"></div>

  <input type="text" name="_honeypot" style="display:none" tabindex="-1" />

  <button type="submit">Send</button>
</form>

<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async></script>

Wrap up

Contact forms are one of those features that look simple but hide complexity. Validation, spam, deliverability, storage — each one is a small problem that adds up.

A form backend handles all of it so you don't have to. The tradeoff is a dependency on a third-party service — but for most projects, that's a good tradeoff.

FormRoute free tier covers 1,000 submissions a month, includes a dashboard, and has no time limit. formroute.dev

AI Without Standards Is Just Faster Chaos

Eduardo Villão — Mon, 27 Apr 2026 14:46:28 +0000

Every engineering team I talk to is using AI. Nobody's debating that anymore.

What nobody's talking about is that every developer on the same team is using it differently.

The Problem Nobody Admits

Ten developers. Ten different setups. Ten different rules files. Ten different prompting habits. Same codebase, same tickets, same sprint - ten different approaches to how AI touches the code.

One dev has a meticulous CLAUDE.md with architecture decisions, testing conventions, and code style rules. The dev next to them has nothing - just vibes and a blank context window. Both ship code. Both pass review. The inconsistency is invisible until it isn't.

AI didn't create this problem. It amplified what was already broken: the lack of shared engineering standards that actually get enforced.

Three Things That Break

No visibility. You don't know how your team uses AI. Who follows best practices. Who doesn't. What gets reviewed. What ships blind. Engineering managers have dashboards for deployment frequency, test coverage, PR cycle time - but zero visibility into how AI is shaping the code their team writes every day.

No consistency. Same ticket, ten different approaches. One dev asks the AI to write tests first. Another skips tests entirely and asks for the implementation. A third gives the AI the full architectural context. A fourth gives it nothing. The output varies wildly - not because the AI is inconsistent, but because the humans are.

And this isn't just about different code styles. It's about where in the codebase the change happens, what the scope should be, why this approach and not another. There are a thousand ways to solve the same problem. The AI will confidently execute any of them. Without a shared standard for how your team makes these decisions, every AI-generated PR becomes a review burden. Someone has to undo, redo, or reshape work that was technically correct but architecturally wrong. That's rework at scale, and it compounds fast.

Knowledge walks out. When a developer leaves, their context, patterns, and shortcuts leave with them. The rules they built, the prompts they refined, the architectural decisions they encoded in their local setup - gone. The next hire starts from zero. This was already a problem before AI. Now it's worse, because the amount of implicit knowledge in a developer's AI setup is massive and completely undocumented.

Why This Is Harder Than It Looks

The obvious reaction is "just create a shared rules file." That's where most teams start. It's also where most teams stop.

A shared rules file in a repo solves the format problem but not the enforcement problem. Nobody checks if developers actually use it. Nobody knows if it's up to date. Nobody knows if the dev who joined last month even knows it exists.

And rules are just the beginning. What about which models are approved? What about which phases of work should use AI and which shouldn't? What about cost? What about the architectural decisions that should constrain how AI generates code in your specific codebase?

Standardizing AI in an engineering team isn't a file. It's a system. And most teams don't have one.

What Actually Needs to Happen

I think about this in three layers:

Layer 1: Shared context. Every developer working on the same codebase should start with the same foundational context. Architecture decisions, code conventions, testing strategy, dependency rules - this isn't optional, and it shouldn't depend on individual setup. If your ADRs exist but only two people know where they are, they don't exist.

Layer 2: Guardrails. Not everything should be delegated to AI. Some decisions require human judgment. Some code paths are too critical for unsupervised generation. The team needs to define where AI adds value and where it adds risk - and enforce that distinction, not just document it.

Layer 3: Visibility. You need to know what's happening. Not surveillance - signal. Which parts of the codebase are AI-touched. What patterns are emerging. Where the inconsistencies are. Without this, you're managing a process you can't see.

Most teams have none of these layers. Some have a partial Layer 1. Almost nobody has Layer 2 or 3.

The Real Competitive Advantage

Here's what I think most people miss: the competitive advantage of AI in engineering isn't speed. Speed is table stakes. Everyone gets faster.

The advantage is in how consistently and reliably you use it across the entire team. The team that ships fast with shared standards will outperform the team that ships fast with ten different approaches - because the second team is accumulating invisible inconsistency that compounds over time.

Faster chaos is still chaos. It just takes longer to notice.

This Isn't About Tools

I'm not pitching a solution here. I'm describing a problem I see everywhere and that I think is underexplored.

The industry spent the last two years talking about adopting AI. The next conversation needs to be about governing it. Not in a bureaucratic, compliance-heavy way - in a practical, engineering-first way. Shared context, clear guardrails, basic visibility.

Every team that adopted AI without standardizing it is running an experiment with no controls. Some of those experiments will work out fine. Some won't. The ones that don't will be very expensive to fix - because the technical debt from inconsistent AI usage is invisible until it's systemic.

The question isn't whether your team should use AI. It's whether they should all use it the same way.

I think the answer is obvious.

How to Self-Host WordPress Plugins on GitHub and Deliver Updates

Eduardo Villão — Mon, 27 Apr 2026 14:21:37 +0000

Managing plugin updates can be a challenge, especially if you're not relying on the WordPress Plugin Repository. But what if you could self-host your plugins on GitHub and deliver updates seamlessly, without the need for complex libraries or third-party services?

In this guide, I'll walk you through a simple yet powerful solution that adheres to WordPress's standard for updates, making the process completely transparent for your users. To make this possible, I've developed a custom GitHub Action and a PHP script that work together to handle updates effortlessly. This is the same solution I use for some of my own plugins, and now I'm sharing it with the community so you can benefit from it too.

No extra dependencies, no fuss — just GitHub and a bit of PHP magic. Let's get started! 🚀

What is Self-Hosting Plugins?

Before diving in, let's take a step back: self-hosting plugins means managing your plugin's storage and updates independently, outside the WordPress.org repository. You take control of where your WordPress plugins are stored and how updates are delivered, without relying on the official WordPress Plugin Repository. Instead of hosting your plugin on WordPress.org, you use your own infrastructure — such as GitHub, a private server, or any other file host — to manage your plugin's lifecycle.

In essence, self-hosting empowers developers to build, distribute, and update plugins on their own terms, while still providing users with a seamless and familiar update experience.

What is Required?

At a high level, you'll need two things:

1. A server (in our case GitHub):

Host metadata about your plugin, including the latest version, download URL, and other required information.
Store the .zip distribution file, which will be downloaded during the update process.

2. An Update Checker Script in Your Plugin:

Fetch data from the server (GitHub) to retrieve the latest plugin details.
Compare versions to check whether the installed version is outdated.
Forward updates seamlessly into WordPress's default update system.

With these two components working together, you can deliver a smooth and automated update experience for your plugins, all while retaining full control over the distribution process.

The Server Side on GitHub

The GitHub Action automates the creation of everything needed for the plugin update process. Here's the high-level flow:

1. Generate JSON Metadata

The action parses your readme.txt and other relevant files to create a JSON file containing metadata about your plugin — version, download URL, description, and more. This metadata is essential for the PHP script on the plugin side to query the server and verify if the plugin is up to date.

The download URL is automatically generated to point directly to the .zip file in the release created by the action, ensuring WordPress fetches updates directly from GitHub.

2. Prepare the Distribution Package

The action compiles your plugin files into a .zip package, ready for distribution. During this process, specific rules can be defined to exclude unnecessary folders or files — such as development directories, test cases, or build artifacts. This ensures a clean and optimized distribution file.

3. Release Creation

Once the metadata and distribution package are prepared, the action automates the creation of a new GitHub Release. The release is tagged with the corresponding plugin version, ensuring WordPress and the PHP script can correctly fetch the latest version.

This streamlined process ensures that every time you create a new tag/version of your plugin, all required files and metadata are automatically prepared and hosted, ready to deliver updates to your users.

👉 Check the full implementation: wp-self-host-updater-generator

The Plugin Side — Update Checker

The PHP script serves as the "bridge" between the plugin installed on the WordPress site and the server-side metadata hosted on GitHub. Here's how it operates:

1. Add a Simple PHP File to Manage Updates

The update checker script is integrated directly into your plugin. It hooks into WordPress's native update events via filters like plugins_api and site_transient_update_plugins to manage and provide update information dynamically.

2. Request JSON Data from GitHub

The script queries the GitHub-hosted JSON metadata file for the latest information about your plugin — current version, description, download URL, and other details. This ensures the site always has access to accurate, up-to-date plugin information.

3. Compare Current Version vs. Latest Version

Once the JSON data is retrieved, the script compares the currently installed version with the version available in the metadata. If the versions match, no action is taken. If a newer version exists, the script forwards the update information to WordPress's built-in update system.

4. Follow the Default WordPress Flow to Upgrade

If a new version is available, WordPress takes over using its default upgrade mechanism. This ensures a seamless and familiar experience for end users, who can update the plugin just like they would with any other WordPress plugin.

👉 Check the full implementation: wp-self-host-updater-checker

And that's it! 🎉

If you have any questions, need help with implementation, or have tested this solution and want to share feedback, feel free to drop a comment below. I'd love to hear from you!

FAQ

1. Will this work with mu-plugins?
Partially! The server side on GitHub is fully capable of managing MU-Plugins. However, since MU-Plugins don't follow the same update flow as regular WordPress plugins, the PHP script will require some adjustments. Coming soon.

2. Will this work with themes?
Not yet. Some modifications are needed to support themes. For now, this solution works exclusively with plugins — theme support is in progress.

3. Can I validate the user license before delivering updates?
This flow is designed for "free" plugins, so license validation isn't currently supported. I'm exploring ways to incorporate this feature and will share updates soon.

4. Will this work with private repositories?
Almost! The action works as-is, but the PHP script needs changes because a token is required to authenticate requests for the JSON data from private repos. Details coming soon.

Handle Elementor Popup Events Without jQuery

Eduardo Villão — Mon, 27 Apr 2026 14:20:15 +0000

If you've ever worked with Elementor and tried to manipulate its popups programmatically, you've probably noticed that the official documentation provides event handling examples only with jQuery. However, if you prefer a modern and lightweight solution using Vanilla JavaScript, this guide is for you.

With the MutationObserver API, you can monitor changes to the DOM and detect when an Elementor popup modal is injected into the <body>. This allows you to execute custom actions without relying on additional libraries.

Why Use MutationObserver?

The MutationObserver API is a native JavaScript feature that lets you observe DOM changes, such as adding or removing elements, and modifications to attributes of existing elements.

In the case of Elementor popups, it's perfect for detecting when the popup modal is dynamically added to the DOM.

Code to Detect Elementor Popups

Here's a complete code snippet that you can use in your project:

// Select the <body> element
const body = document.body;

// Create a MutationObserver
const observer = new MutationObserver((mutations) => {
    mutations.forEach((mutation) => {
        // Check if new nodes were added
        if (mutation.type === "childList") {
            mutation.addedNodes.forEach((node) => {
                // Check if the added node is an Elementor popup modal
                if (node.classList && node.classList.contains("elementor-popup-modal")) {
                    console.log("Elementor popup detected:", node);
                    // Add your custom logic here
                }
            });
        }
    });
});

// Configure the observer to monitor the <body>
observer.observe(body, { childList: true });

// Stop observing when no longer needed (optional)
// observer.disconnect();

How It Works

Monitoring <body>: The <body> element is observed because Elementor injects its popups as child nodes of <body>.

MutationObserver: We use the MutationObserver to watch for changes in the child nodes of <body> by setting { childList: true }.

Filtering Added Nodes: For each added node, we check if it has the class elementor-popup-modal, which identifies Elementor's popups.

Custom Actions: When the modal is detected, you can execute any logic in the block where the console.log statement is located.

Practical Use Case

Suppose you want to apply a custom animation when an Elementor popup appears. You can modify the code like this:

if (node.classList && node.classList.contains("elementor-popup-modal")) {
    console.log("Elementor popup detected:", node);
    node.style.opacity = 0; // Start invisible
    setTimeout(() => {
        node.style.transition = "opacity 0.5s";
        node.style.opacity = 1; // Fade-in effect
    }, 0);
}

Why Choose Vanilla JS?

No Dependencies: Reduces the overall project size by eliminating libraries like jQuery.

Improved Performance: Vanilla JavaScript is generally faster since it doesn't have the overhead of handling selectors and events.

Modern Compatibility: MutationObserver is supported in all modern browsers, including Edge and Safari.

Using MutationObserver to detect Elementor popups is an elegant and efficient solution, especially for developers who prefer not to rely on jQuery. With this code, you can fully customize how you interact with Elementor popups, whether it's adding animations, tracking events, or implementing other custom logic.

If you found this tip helpful, share it with other developers and leave your ideas for popup customization in the comments!

In the AI Era, Soft Skills Are the Hard Skills

Eduardo Villão — Mon, 27 Apr 2026 14:15:00 +0000

The more powerful AI gets, the more human the bottleneck becomes. You open a new chat, type a vague prompt, get a mediocre response, and blame the model. The model isn't the problem.

What Actually Changed

For the past decade, the most valuable thing a developer could do was execute. Write the code, ship the feature, fix the bug. Speed and technical precision were the differentiators.

AI didn't just speed that up. It changed who does it.

A well-prompted AI agent can write a working feature in minutes. It can refactor a module, generate tests, handle edge cases, and document the result. All before you've finished your second coffee. The execution layer is no longer the bottleneck.

What's left? The part AI can't do on its own: figuring out what to build, why it matters, and how to frame it clearly enough that something else can execute it well.

The bottleneck shifted from execution to clarity.

What Clarity Actually Means

Clarity isn't just "communicate better." That's too vague to be useful.

In practice, clarity means:

Knowing what to build. Not every feature request deserves to be built. Not every bug deserves to be fixed right now. The ability to evaluate, prioritize, and say no is a skill. It becomes more valuable when execution is cheap.

Knowing when to build it. Sequencing matters. Building the right thing in the wrong order creates rework. AI amplifies this problem: it can generate a lot of code very fast, and if the direction is wrong, you have a lot of wrong code very fast.

Knowing what to delegate. Not everything should go to AI. Some decisions require human judgment, context, or accountability. The developer who throws everything at the model and hopes for the best will produce unstable, expensive, hard-to-maintain systems. Knowing the limits of delegation is a skill.

Knowing how to frame it. This is where most people underestimate the work. A vague brief produces a vague result. The better you can define the problem — constraints, expected output, edge cases, context — the better the output. That's not prompting as a trick. That's communication as a discipline.

None of this is technical in the traditional sense. All of it determines whether the technical output is any good.

Managing AI Is Managing People

Here's the thing: none of this is new.

The best practices for working with AI are basically textbook management principles. Break work into smaller tasks. Give clear scope before delegating. Review output before shipping. Don't overload with context. One thing at a time.

Experienced managers figured this out with humans. The difference is that most developers never had to manage anyone. They just had to code. Now they're managing an AI that can out-execute them technically, and they're discovering management the hard way: by getting bad results and wondering why.

The developer who spent years ignoring team dynamics, documentation, and clear communication now has a gap. The developer who built those habits, even informally, has an advantage they didn't expect.

Prompting well is leading well. Scoping a task for AI is the same cognitive work as scoping a task for a junior engineer. The feedback loop is just faster.

The Skills That Were Always There

Soft skills were never actually soft. They were just undervalued because the market paid well for execution alone.

Communication. Structured thinking. Prioritization. Breaking down complex problems. The ability to zoom out from the code and see the product. These were nice-to-haves when shipping code was hard. Now that shipping code is easy, they're the core competency.

The developers who will thrive aren't necessarily the best at writing code. They're the best at knowing what code to write, why, and how to make sure it gets done right. Whether by themselves, a team, or a model.

That's not a soft skill. That's the job now.

What to Do With This

If you're a developer reading this, the question isn't whether AI will replace you. It's whether you're building the skills that AI can't replace.

Start small: next time you open a chat with an AI, write the prompt as if you were briefing a capable but context-free junior engineer. Define the goal, the constraints, what done looks like, and what to avoid. See if the output changes.

It will.

That gap — between a poorly thought-out request and a well-structured one — is exactly where the value is now. Not just how you communicate it, but how clearly you've thought it through before you type anything.

Starting there is the first step. But it goes deeper: spec-driven development, harness engineering, structured AI workflows, how teams are rethinking the entire dev process around these tools. That's what I'll keep writing about here.

Subscribe if you want to follow along.

Your 404 Logs Are a Security Report You're Ignoring

Eduardo Villão — Mon, 27 Apr 2026 14:13:18 +0000

Most WordPress developers install a redirect plugin, set up a few 301s, and never look at their 404 logs again. If they do, it's for SEO, fixing broken links, cleaning up crawl errors. That's the obvious use.

But there's something else in those logs that almost everyone ignores.

Your 404 logs are a real-time map of who's probing your site and what they're looking for. Bots scanning for exposed environment files, credential leaks, config files, path traversal exploits — all of it shows up as 404s before it shows up as a breach.

I pulled the 404 logs from two of my own sites over the past week. Here's what I found, and what I blocked at the CDN level so these requests never hit my server again.

The Numbers

Two WordPress sites. One week of data.

Site A: 1,388 total 404 requests across 1,118 unique URLs
Site B: 2,693 total 404 requests across 1,877 unique URLs

Over 4,000 requests that aren't real users, aren't search engines, and aren't broken links. They're automated scans looking for vulnerabilities.

The Attack Patterns

Every 404 log tells a story. Here are the five categories I found in mine.

1. Environment File Scanning (.env)

This is by far the most common pattern. Bots systematically scan every possible path where a .env file might exist:

/.env                    → 49 hits
/staging/.env            → 20 hits
/backend/.env            → 20 hits
/react/.env              → 15 hits
/.env.local              → 15 hits
/shared/.env             → 13 hits
/api/.env                → 12 hits
/.env.production         → 12 hits
/app/.env                → 10 hits
/server/.env             → 10 hits

And it doesn't stop there. I found requests for .env.backup, .env.bak, .env.save, .env.old, .env_copy, .env_secret, .env~, .env.swp — over 80 different .env variations in total.

What they're looking for: Database credentials, API keys, SMTP passwords, Stripe keys, AWS secrets. One exposed .env file = full access to your infrastructure.

2. Cloud Credential Harvesting

/.aws/credentials        → 17 hits
/.aws/config             → 5 hits
/.AwS/CrEdEnTiAlS        → 5 hits (case variation to bypass rules)
/.terraform/terraform.tfstate → 6 hits
/serviceAccountKey.json  → 4 hits
/credentials.json        → 5 hits

Notice the case variation on .AwS/CrEdEnTiAlS — that's specifically designed to bypass naive pattern matching rules that only check lowercase. They're hunting for AWS keys, GCP service accounts, and Terraform state files that might contain infrastructure secrets.

3. Config & Secret File Probing

/config/initializers/secret_token.rb  → 7 hits (Rails)
/config/storage.yml                   → 6 hits (Rails)
/application.yml                      → 5 hits (Spring Boot)
/docker-compose.yml                   → 4 hits
/sftp-config.json                     → 5 hits (Sublime SFTP)
/.vscode/sftp.json                    → 3 hits (VS Code SFTP)
/config.php.bak                       → 5 hits
/secrets.json                         → 6 hits
/sendgrid.env                         → 7 hits

Bots don't care what framework you use. They scan for Rails, Laravel, Spring Boot, Node.js, Django — all in the same sweep. If you accidentally deployed a config file, they'll find it.

4. WordPress-Specific Probing

/wp-config               → 3 hits
/wp-config~              → 1 hit
/wp-config.production    → 1 hit
/wp-configbak            → 1 hit

They're looking for backup copies of wp-config.php — the file that contains your database credentials. Editor temp files (wp-config~), manual backups (wp-configbak), environment-specific copies. One careless cp wp-config.php wp-config.bak and you've exposed everything.

5. Path Traversal & Code Execution Attempts

/etc/passwd?raw??                                → 3 hits
/@fs/etc/passwd?import&raw??                     → 3 hits
/admin/config?cmd=cat /root/.aws/credentials     → 1 hit
/vendor/phpunit/phpunit/phpunit.xsd              → 2 hits
/pms?module=logging&file_name=../../~/.aws/credentials → 1 hit

These are active exploitation attempts, not just scanning. They're trying to read system files, execute commands, and exploit known vulnerabilities in PHPUnit and other packages.

What to Do About It: Block at the CDN

Here's the key insight: every one of these requests hit your server. Your WordPress installation processed them, your PHP executed, your database was queried for a 404 page — all for a bot that's trying to hack you.

The fix is simple: block these patterns at the CDN level (Cloudflare, Fastly, CloudFront...) so they never reach your server. Zero load on your infrastructure, zero PHP execution, zero risk.

Cloudflare WAF Rules

Here are the rules I set up based on my actual 404 data.

Important: use lower() in all of them — attackers use case variations like .AwS/CrEdEnTiAlS to bypass naive rules.

Rule 1: Block .env file access

(lower(http.request.uri.path) contains ".env")
Action: Block

Rule 2: Block credential/config file access

(lower(http.request.uri.path) contains ".aws/credentials" or
 lower(http.request.uri.path) contains "terraform.tfstate" or
 lower(http.request.uri.path) contains "serviceaccountkey" or
 lower(http.request.uri.path) contains "docker-compose.yml" or
 lower(http.request.uri.path) contains "sftp-config" or
 lower(http.request.uri.path) contains "sftp.json" or
 lower(http.request.uri.path) contains "secrets.json" or
 lower(http.request.uri.path) contains "credentials.json" or
 lower(http.request.uri.path) contains "sendgrid" or
 lower(http.request.uri.path) contains "secret_token.rb" or
 lower(http.request.uri.path) contains "storage.yml" or
 lower(http.request.uri.path) contains "application.yml")
Action: Block

Rule 3: Block wp-config probing

(lower(http.request.uri.path) contains "wp-config" and
 not http.request.uri.path eq "/wp-admin/")
Action: Block

Rule 4: Block path traversal attempts

(lower(http.request.uri.path) contains "etc/passwd" or
 lower(http.request.uri.path) contains "phpunit" or
 lower(http.request.uri.path) contains "update.cgi" or
 http.request.uri contains "cmd=")
Action: Block

Rule 5: Block common backup/install directory probing

(lower(http.request.uri.path) eq "/old/" or
 lower(http.request.uri.path) eq "/new/" or
 lower(http.request.uri.path) eq "/backup/" or
 lower(http.request.uri.path) eq "/wordpress/" or
 lower(http.request.uri.path) eq "/wp/" or
 lower(http.request.uri.path) eq "/test/")
Action: Block

Cloudflare string comparison is case-sensitive by default. The lower() function converts the URI path to lowercase before comparison, so /.AwS/CrEdEnTiAlS gets matched by a rule checking for .aws/credentials. Without lower(), that request slips through.

Why CDN-Level Blocking Matters

When you block at the CDN:

The request never reaches your server
No PHP execution, no database query, no CPU usage
Your server resources go to real users, not bots
You reduce your attack surface to zero for known patterns
Logs stay clean, making it easier to spot new patterns

Blocking at the application level (WordPress plugins, .htaccess) still works, but the request already consumed server resources by the time it's blocked. CDN-level blocking is the difference between a bouncer at the door and a bouncer inside the bar.

Make This a Habit

Pull your 404 logs once a month. Look for patterns. Add new Cloudflare rules.

The bots evolve. New scanning patterns appear. The .AwS/CrEdEnTiAlS case variation trick is a perfect example — someone specifically designed that to bypass lowercase-only rules.

Your 404 logs aren't just broken links. They're a free security audit. Read them.

The data in this post comes from real 404 logs collected over one week from two production WordPress sites. No IPs or identifying information from the attacking bots are included.

Masky.js: A Lightweight Alternative to Inputmask, Cleave.js, and IMask

Eduardo Villão — Mon, 27 Apr 2026 14:05:55 +0000

Finding the right input masking library can be tricky. There are many options, each with its pros and cons. Some are feature-packed but heavy, while others are lightweight but miss critical functionalities like validation or mobile-friendly optimizations.

In today's world, where performance and user experience are top priorities, selecting the right library is crucial. A solution that minimizes bundle size and enhances mobile usability while providing robust validation can make a huge difference in your project.

Popular Libraries and Their Limitations

If you've needed input masking for forms, you've likely come across libraries like Inputmask, Cleave.js, and IMask. These libraries are really great, but they come with trade-offs:

Inputmask:

Powerful and flexible, but significantly increases bundle size (~20 KB gzipped).
Lacks features like inputmode for better mobile experiences.

Cleave.js:

Simple and supports dynamic masks.
However, it lacks built-in validation or automatic configurations like minlength and maxlength.

IMask:

Offers great features with a moderate size (~5 KB gzipped).
It's powerful but can be overkill for simpler use cases.

While these are solid tools, I felt there was room for a solution that's lighter, flexible, and focused on mobile usability.

Introducing Masky.js

That's why I built Masky.js: an ultra-lightweight (just 1.3 KB gzipped) alternative that prioritizes performance without sacrificing flexibility or essential features.

Super Lightweight:

At just 1.3 KB gzipped, it's one of the smallest solutions on the market.
Perfect for projects where bundle size is critical.

Mobile-Friendly:

Automatically sets the inputmode attribute based on the mask, ensuring a better typing experience on mobile devices.

Fully Customizable:

Supports custom masks with prefixes, suffixes, and even reverse masks.

Built-In Validation:

Native support for CPF and CNPJ (Brazilian IDs) validation.

Automation:

Automatically calculates and applies minlength and maxlength based on the mask.

Zero Dependencies:

100% Vanilla JS, making it easy to integrate with any environment or framework.

Comparison

Feature	Masky.js	Inputmask	Cleave.js	IMask
Size (Gzipped)	1.6 KB	20 KB	8 KB	5 KB
Dependencies	None	None	None	None
Custom Masks	✅	✅	✅	✅
Prefixes/Suffixes	✅	❌	✅	✅
Built-in CPF/CNPJ Validation	✅	❌	❌	❌
`inputmode` for Mobile	✅	❌	❌	✅
Automatic Min/Max Length	✅	❌	❌	❌
Reverse Masks	✅	✅	❌	✅

Usage Example

Simplicity is key. Just add the data-mask attribute, and let Masky.js handle the rest — prefixes, suffixes, validations, and even automatic inputmode and minlength adjustments.

<!-- Simple Phone Mask -->
<input type="text" data-mask="(00) 00000-0000" />

<!-- Add Prefix and Suffix -->
<input type="text" data-mask="000-000" data-mask-prefix="+55 " data-mask-suffix=" ext" />

<!-- Built-in CPF Validation -->
<input type="text" data-mask="000.000.000-00" data-mask-validation="cpf" />

<script src="https://cdn.jsdelivr.net/npm/masky-js/dist/masky.min.js"></script>

Check more details of how to use on the documentation.

Try it Out

If you're looking for a fast, flexible, and performance-focused input masking solution, give Masky.js a shot!

👉 GitHub: https://github.com/eduardovillao/masky-js

👉 npm: https://www.npmjs.com/package/masky-js

I'd love to hear your thoughts or suggestions!