Forem: DevToolsmith

GDPR Audit Automation: 5 Compliance Checks You Are Probably Missing

DevToolsmith — Mon, 20 Apr 2026 10:44:03 +0000

GDPR has been enforceable since 2018, yet enforcement actions keep increasing year after year. The problem isn't that developers don't care — it's that most compliance checks happen once, at launch, and then get forgotten. Here are five critical GDPR requirements that slip through the cracks on most SaaS products.

1. Data Processing Register (ROPA)

The GDPR requires all organisations processing personal data to maintain a Record of Processing Activities (Article 30). Most developers have never heard of it. Your ROPA must document:

What data you collect and why
The legal basis for processing (consent, legitimate interest, contract)
Data retention periods
Third-party processors (AWS, Stripe, Mixpanel — every one)
Cross-border data transfers

The fine for not having one: up to €10M or 2% of global turnover.

2. Data Subject Request Automation

Under GDPR, users have the right to access, rectify, erase, and port their data — within 30 days. Most SaaS products handle these manually (or ignore them entirely). At scale, this becomes unmanageable.

// Minimum viable DSR handler
app.post('/api/dsr/erasure', authenticate, async (req, res) => {
  const userId = req.user.id;

  // Must delete from ALL systems — not just your main DB
  await Promise.all([
    db.users.delete(userId),
    analyticsService.deleteUser(userId),
    emailService.unsubscribeAll(userId),
    backups.scheduleDataPurge(userId), // often forgotten
  ]);

  res.json({ status: 'processing', deadline: addDays(new Date(), 30) });
});

3. Legitimate Interest Assessment (LIA)

"Legitimate interest" is the most used (and most abused) legal basis for data processing. Using it correctly requires a three-part balancing test: purpose test, necessity test, and balancing test. Using it incorrectly — for marketing without consent, for example — is a violation.

4. Cookie Consent That Actually Works

A cookie banner that says "We use cookies" with a single OK button is not GDPR-compliant. Compliant consent requires:

Granular categories (functional, analytics, marketing)
Equal ease of accepting vs rejecting
No pre-ticked boxes
Stored consent records with timestamp and version
Re-consent when purposes change

5. Vendor Due Diligence

Every third-party service your app touches that handles personal data is a "data processor" under GDPR. You need:

A signed Data Processing Agreement (DPA) with each
Documented transfers under Article 46 (SCCs for US vendors)
A way to revoke access if they're breached

Common oversight: using npm packages that phone home (analytics, error tracking, fonts) without documenting them.

Automating the Audit

Running these checks manually is error-prone and time-consuming. Tools like CompliPilot automate 200+ compliance checks across GDPR, HIPAA, CCPA, and NIS2 — giving you a scored audit report in under 60 seconds, with specific remediation steps for each finding.

The goal isn't perfect compliance overnight. It's knowing exactly where your gaps are so you can prioritise the highest-risk issues first.

Visual Regression Testing with Screenshot APIs: Catch UI Bugs Before Users Do

DevToolsmith — Sun, 19 Apr 2026 09:42:31 +0000

Unit tests check logic. Integration tests check API contracts. But neither catches the CSS regression that moves your checkout button off-screen in Safari, or the z-index bug that hides your navigation on mobile. Visual regression testing fills this gap — and with a screenshot API, it's surprisingly easy to set up.

The Core Concept

Visual regression testing works by:

Capturing a "baseline" screenshot of each page/component
After each deploy, capturing a new screenshot
Diffing the two images pixel-by-pixel
Flagging any changes above a threshold as potential regressions

The diff highlights exactly where things changed — so you see "the nav bar is 2px taller" or "this button moved 40px to the right" immediately.

Setting Up a Baseline

First, capture reference screenshots of all critical pages:

const fs   = require('fs');
const path = require('path');

const PAGES_TO_MONITOR = [
  { name: 'homepage',  url: 'https://yourapp.com', viewport: '1920x1080' },
  { name: 'login',     url: 'https://yourapp.com/login', viewport: '1280x800' },
  { name: 'dashboard', url: 'https://yourapp.com/dashboard', viewport: '1440x900' },
  { name: 'mobile-home', url: 'https://yourapp.com', viewport: '390x844' },
  { name: 'pricing',   url: 'https://yourapp.com/pricing', viewport: '1280x800' },
];

async function captureBaseline() {
  const baselineDir = './visual-tests/baseline';
  fs.mkdirSync(baselineDir, { recursive: true });

  for (const page of PAGES_TO_MONITOR) {
    const [width, height] = page.viewport.split('x').map(Number);
    const url = `https://captureapi.dev/v1/screenshot?${new URLSearchParams({
      url:      page.url,
      width:    width.toString(),
      height:   height.toString(),
      format:   'png',
      full_page: 'false',
    })}`;

    const response = await fetch(url, {
      headers: { 'Authorization': `Bearer ${process.env.CAPTURE_API_KEY}` },
    });

    const buffer = Buffer.from(await response.arrayBuffer());
    fs.writeFileSync(path.join(baselineDir, `${page.name}.png`), buffer);
    console.log(`✅ Baseline captured: ${page.name}`);
  }
}

Comparing Against Baseline

After each deploy, capture the same pages and diff them:

const { createCanvas, loadImage } = require('canvas');

async function diffImages(baselinePath, currentPath) {
  const [baseline, current] = await Promise.all([
    loadImage(baselinePath),
    loadImage(currentPath),
  ]);

  if (baseline.width !== current.width || baseline.height !== current.height) {
    return { changed: true, reason: 'Dimensions changed', pixelDiff: Infinity };
  }

  const canvas = createCanvas(baseline.width, baseline.height);
  const ctx    = canvas.getContext('2d');

  ctx.drawImage(baseline, 0, 0);
  const baselineData = ctx.getImageData(0, 0, canvas.width, canvas.height);

  ctx.clearRect(0, 0, canvas.width, canvas.height);
  ctx.drawImage(current, 0, 0);
  const currentData = ctx.getImageData(0, 0, canvas.width, canvas.height);

  let diffCount = 0;
  const diffCanvas = createCanvas(baseline.width, baseline.height);
  const diffCtx    = diffCanvas.getContext('2d');
  const diffImage  = diffCtx.createImageData(canvas.width, canvas.height);

  for (let i = 0; i < baselineData.data.length; i += 4) {
    const rDiff = Math.abs(baselineData.data[i]   - currentData.data[i]);
    const gDiff = Math.abs(baselineData.data[i+1] - currentData.data[i+1]);
    const bDiff = Math.abs(baselineData.data[i+2] - currentData.data[i+2]);
    const diff  = (rDiff + gDiff + bDiff) / 3;

    if (diff > 10) { // threshold for noise
      diffCount++;
      diffImage.data[i]   = 255; // red highlight
      diffImage.data[i+1] = 0;
      diffImage.data[i+2] = 0;
      diffImage.data[i+3] = 255;
    } else {
      // Dim unchanged pixels for contrast
      diffImage.data[i]   = baselineData.data[i]   * 0.3;
      diffImage.data[i+1] = baselineData.data[i+1] * 0.3;
      diffImage.data[i+2] = baselineData.data[i+2] * 0.3;
      diffImage.data[i+3] = 255;
    }
  }

  const totalPixels  = canvas.width * canvas.height;
  const diffPercent  = (diffCount / totalPixels) * 100;

  diffCtx.putImageData(diffImage, 0, 0);
  const diffPng = diffCanvas.toBuffer('image/png');

  return {
    changed:      diffPercent > 0.1, // 0.1% threshold
    pixelDiff:    diffCount,
    diffPercent:  diffPercent.toFixed(3),
    diffImage:    diffPng,
  };
}

GitHub Actions Integration

# .github/workflows/visual-regression.yml
name: Visual Regression
on: [deployment_status]

jobs:
  visual-test:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with: { name: visual-baseline, path: visual-tests/baseline }
      - name: Run visual regression tests
        env:
          CAPTURE_API_KEY: ${{ secrets.CAPTURE_API_KEY }}
          TARGET_URL: ${{ github.event.deployment_status.target_url }}
        run: node scripts/visual-regression.js
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: visual-diffs
          path: visual-tests/diffs/

Practical Tips

Anti-flake strategies:

Wait for network idle before screenshotting (the API handles this automatically)
Exclude dynamic content (timestamps, ads) with CSS: .timestamp { visibility: hidden; }
Use a small pixel threshold (0.1%) to avoid false positives from antialiasing

What to monitor:

All pages in your primary user flow (login → dashboard → key action → checkout)
Mobile viewports — these regress most often
Email clients if you send HTML emails

Updating baselines: When you intentionally change the UI, update the baseline images as part of your PR. Store them in git or a dedicated artifact storage.

CaptureAPI works well for this use case with its CSS selector targeting (capture just the component you changed) and batch endpoint (check 20 pages in one request).

Screenshot APIs vs Headless Chrome: Benchmarks, Costs, and Decision Framework

DevToolsmith — Sat, 18 Apr 2026 09:42:46 +0000

Every developer who needs to automate screenshots eventually asks: should I run Puppeteer/Playwright myself, or use a screenshot API? I've done this comparison across multiple projects. Here's the honest breakdown.

The DIY Headless Chrome Approach

Running your own Puppeteer instance looks simple:

const puppeteer = require('puppeteer');

async function screenshot(url) {
  const browser = await puppeteer.launch();
  const page    = await browser.newPage();
  await page.goto(url, { waitUntil: 'networkidle2' });
  const buffer  = await page.screenshot({ fullPage: true });
  await browser.close();
  return buffer;
}

Looks fine. Now wait for production to hit it.

Hidden Operational Costs

Memory: Each Chrome instance uses 200-400MB RAM. At 10 concurrent screenshots, that's 2-4GB just for Chrome. Kubernetes auto-scaling events, higher instance tier needed.

CPU: Chrome rendering is CPU-intensive. Your screenshot service competing with your API for CPU causes latency spikes across your entire application.

Stability: Puppeteer has a well-documented problem with processes not cleaning up after errors. Memory leaks in long-running processes. Need to implement browser pool management:

// What you actually need to write for production
class BrowserPool {
  constructor(size = 5) {
    this.size     = size;
    this.available = [];
    this.queue    = [];
  }

  async acquire() { /* ... */ }
  async release(browser) { /* ... */ }
  async handleCrash(browser) { /* ... */ }
  async warmUp() { /* ... */ }
  async healthCheck() { /* ... */ }
}

Maintenance: Chrome updates. Headless Chrome API changes. puppeteer-chromium version mismatches. This becomes a part-time job.

Infrastructure: Your screenshot service can't run on serverless (Lambda cold starts with Chromium take 3-5 seconds minimum). Needs persistent containers.

When DIY Makes Sense

Screenshots are your core product feature (not a utility)
You need deep customisation (complex JS execution, credential injection)
Compliance requires keeping data on-premise
Volume: millions of screenshots per day (at scale, API cost exceeds hosting)

The Screenshot API Approach

async function screenshot(url) {
  const response = await fetch(
    `https://captureapi.dev/v1/screenshot?url=${encodeURIComponent(url)}`,
    { headers: { 'Authorization': `Bearer ${process.env.CAPTURE_API_KEY}` } }
  );
  return response.arrayBuffer();
}

Zero infrastructure. Zero maintenance. Scales to any volume automatically.

Capabilities Comparison

Feature	DIY Puppeteer	CaptureAPI
Full page	✅	✅
Viewport sizes (mobile/4K)	✅ custom	✅ 5 presets + custom
CSS selector targeting	✅ custom code	✅ built-in
PDF generation	✅	✅
Watermarks	✅ custom code	✅ built-in
Webhooks on completion	❌ need to build	✅ built-in
Batch processing	❌ need to build	✅ built-in
Status page / SLA	❌ you own it	✅ 99.9% SLA
Maintenance burden	HIGH	None

Real Cost Comparison

Assume 10,000 screenshots per month:

DIY on AWS:

t3.medium EC2 (2 vCPU, 4GB RAM): $30.37/month
Storage + network: ~$5/month
Your engineering time (maintenance, incident response): ~2 hours/month × $150/hr = $300
Total: ~$335/month (mostly hidden engineering cost)

CaptureAPI:

10,000 captures: $29/month
Engineering time: ~0 hours
Total: $29/month

At 100,000 screenshots/month, the crossover point approaches — but even then the operational simplicity often wins.

Performance Benchmarks

Testing from the same region (EU-West):

Metric	Puppeteer (warm)	Puppeteer (cold)	CaptureAPI
Simple page	1.8s	4.2s	1.1s
Complex SPA	3.4s	7.8s	1.9s
Full page (3000px)	2.9s	6.1s	2.3s

APIs win on cold start performance by a significant margin because they run pre-warmed Chrome instances.

Decision Framework

Use a Screenshot API if:

Screenshots are a secondary feature of your product
You want zero infrastructure to maintain
You need reliability guarantees (SLA, 99.9% uptime)
You're a small team where ops overhead matters

Run your own Puppeteer if:

Screenshots are your primary product
You process millions per day
You need maximum customisation (authenticated sessions, complex interactions)
Data sovereignty requires on-premise processing

CaptureAPI offers 200 free captures per month — enough to integrate and validate before deciding whether to use the API or build in-house.

Building an Automated Invoice Processing Pipeline with Node.js

DevToolsmith — Fri, 17 Apr 2026 10:10:38 +0000

Accounts payable teams spend an average of 3.7 minutes manually processing each invoice. At 200 invoices per month, that's 12+ hours of data entry. Here's how to build an automated pipeline that brings this to under 10 seconds per document.

Pipeline Architecture

Email/SFTP/API → Receive → Extract → Validate → Enrich → Store → Notify

Each stage is independent and can fail gracefully without losing the document.

Stage 1: Document Ingestion

Accept invoices from multiple sources:

const express = require('express');
const multer  = require('multer');
const path    = require('path');

const upload = multer({
  dest: '/tmp/invoices',
  limits: { fileSize: 20 * 1024 * 1024 }, // 20MB
  fileFilter: (req, file, cb) => {
    const allowed = ['.pdf', '.docx', '.xlsx', '.png', '.jpg'];
    const ext     = path.extname(file.originalname).toLowerCase();
    cb(null, allowed.includes(ext));
  },
});

app.post('/api/invoices/upload', upload.array('files', 20), async (req, res) => {
  const jobs = req.files.map(file => ({
    id:       generateJobId(),
    path:     file.path,
    filename: file.originalname,
    status:   'queued',
  }));

  await queue.addBatch(jobs);
  res.json({ jobs: jobs.map(j => ({ id: j.id, status: j.status })) });
});

Stage 2: Extraction

async function extractInvoiceData(job) {
  const formData = new FormData();
  formData.append('file', fs.createReadStream(job.path), job.filename);
  formData.append('fields', JSON.stringify([
    'invoice_number', 'invoice_date', 'due_date',
    'vendor_name', 'vendor_address', 'vendor_tax_id',
    'line_items', 'subtotal', 'tax_amount', 'total_amount',
    'currency', 'payment_terms',
  ]));

  const response = await fetch('https://parseflow.dev/api/extract', {
    method:  'POST',
    headers: { 'Authorization': `Bearer ${process.env.PARSEFLOW_KEY}` },
    body:    formData,
  });

  if (!response.ok) {
    const error = await response.json();
    throw new Error(`Extraction failed: ${error.message}`);
  }

  return response.json();
}

Stage 3: Validation

Never trust extracted data without validation:

function validateInvoice(data) {
  const errors = [];

  // Required fields
  if (!data.invoice_number) errors.push('Missing invoice number');
  if (!data.vendor_name)    errors.push('Missing vendor name');
  if (!data.total_amount)   errors.push('Missing total amount');

  // Math validation
  if (data.line_items?.length > 0) {
    const lineTotal = data.line_items.reduce((sum, item) => sum + item.total, 0);
    const tolerance = 0.02; // 2 cents tolerance for rounding

    if (Math.abs(lineTotal - data.subtotal) > tolerance) {
      errors.push(`Line items sum (${lineTotal}) != subtotal (${data.subtotal})`);
    }
  }

  if (data.subtotal && data.tax_amount && data.total_amount) {
    const expected = data.subtotal + data.tax_amount;
    if (Math.abs(expected - data.total_amount) > 0.02) {
      errors.push(`Subtotal + tax (${expected}) != total (${data.total_amount})`);
    }
  }

  // Duplicate detection
  // (check against your DB for same invoice_number + vendor)

  return { valid: errors.length === 0, errors };
}

Stage 4: Enrichment

Match the vendor to your supplier database:

async function enrichInvoice(data) {
  // Fuzzy match vendor name to known suppliers
  const vendor = await db.suppliers.findBestMatch(data.vendor_name);

  if (vendor) {
    data.supplier_id      = vendor.id;
    data.gl_account       = vendor.default_gl_account;
    data.cost_center      = vendor.default_cost_center;
    data.approver_email   = vendor.approver_email;
    data.payment_method   = vendor.preferred_payment_method;
  } else {
    data.requires_review  = true;
    data.review_reason    = 'Unknown vendor — manual matching required';
  }

  return data;
}

Stage 5: Notifications

async function notifyApprover(invoice) {
  // Only for invoices above threshold or from unknown vendors
  if (invoice.total_amount > 5000 || invoice.requires_review) {
    await emailService.send({
      to:      invoice.approver_email,
      subject: `Invoice approval required: ${invoice.invoice_number} — ${invoice.vendor_name}`,
      template: 'invoice-approval',
      data:    invoice,
    });
  }
}

Error Handling and Dead Letter Queue

async function processJob(job) {
  try {
    job.status = 'processing';
    const extracted  = await extractInvoiceData(job);
    const validation = validateInvoice(extracted);

    if (!validation.valid) {
      job.status       = 'validation_failed';
      job.errors       = validation.errors;
      await moveToReview(job);
      return;
    }

    const enriched = await enrichInvoice(extracted);
    await db.invoices.create({ ...enriched, job_id: job.id });
    await notifyApprover(enriched);

    job.status = 'completed';

  } catch (err) {
    job.attempts++;
    if (job.attempts >= 3) {
      job.status = 'dead_letter';
      await alertOps(job, err);
    } else {
      job.status       = 'retry';
      job.retry_after  = addMinutes(new Date(), job.attempts * 15);
    }
  }

  await db.jobs.update(job);
}

Results

A pipeline like this, using ParseFlow for the extraction stage, processes a typical invoice in 4-8 seconds with 94%+ field accuracy across variable formats. The validation stage catches the remaining edge cases and routes them to a human reviewer queue rather than silently accepting bad data.

The full pipeline handles PDF, Word, and Excel with the same code path — no special-casing per format.

Structured Data Extraction from PDFs: Regex vs Template Matching vs AI

DevToolsmith — Thu, 16 Apr 2026 10:12:26 +0000

Invoice processing is one of those problems that looks simple until you actually try to build it. Reading data from a PDF invoice should be straightforward — but the moment you encounter 50 different vendor layouts, foreign languages, scanned images, and multi-page documents, your initial approach falls apart. Here's an honest comparison of the three main approaches.

Approach 1: Regex and String Parsing

For a single, controlled invoice format, regex works fine:

function extractInvoiceData(text) {
  const invoiceNumber = text.match(/Invoice\s*#?\s*([A-Z0-9-]+)/i)?.[1];
  const total = text.match(/Total\s*[:\$]?\s*([\d,]+\.\d{2})/i)?.[1];
  const date  = text.match(/(\d{1,2}[\/.-]\d{1,2}[\/.-]\d{2,4})/)?.[1];

  return { invoiceNumber, total, date };
}

When it works: Internal documents with consistent formatting, fixed-template invoices from a single vendor, structured data exports.

When it breaks: Any layout change. "Invoice No:" vs "Invoice Number:" vs "Ref:" vs just printing the number without a label. International date formats. Currency symbols in different positions. Thousands separators (1.234,56 vs 1,234.56).

Reality: regex-based extraction needs constant maintenance. Every new vendor format requires code changes.

Approach 2: Template Matching

Template matching defines anchor points in a document layout (coordinates or text markers) and extracts data from fixed positions relative to those anchors.

# Example with a hypothetical template engine
template = {
  'invoice_number': { 'after': 'Invoice Number:', 'line': 0, 'field': 0 },
  'total': { 'anchor': 'TOTAL DUE', 'offset_y': 0, 'offset_x': 150 },
}
result = extract_with_template(pdf_path, template)

When it works: High-volume, single-vendor processing (e.g., processing all invoices from one supplier). Government forms with fixed layouts.

When it breaks: Requires one template per vendor. A 200-vendor AP operation needs 200 templates. PDFs with dynamic layout (the total row moves based on number of line items). Scanned documents with slight rotation or skew.

Template matching is maintenance-intensive at scale.

Approach 3: AI-Powered Extraction

Modern document AI models (fine-tuned on millions of documents) understand document structure semantically:

// Using an AI document API
const response = await fetch('https://parseflow.dev/api/extract', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.PARSEFLOW_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    document_url: 'https://your-bucket.s3.amazonaws.com/invoice.pdf',
    fields: ['invoice_number', 'date', 'vendor_name', 'line_items', 'subtotal', 'tax', 'total'],
  }),
});

const data = await response.json();
// Returns structured JSON regardless of layout

Output:

{
  "invoice_number": "INV-2026-0142",
  "date": "2026-04-01",
  "vendor_name": "Acme Corporation",
  "line_items": [
    { "description": "SaaS Platform License", "quantity": 1, "unit_price": 5000.00, "total": 5000.00 },
    { "description": "Implementation Services", "quantity": 10, "unit_price": 250.00, "total": 2500.00 }
  ],
  "subtotal": 7500.00,
  "tax": 750.00,
  "total": 8250.00
}

When it works: Variable layouts, multiple vendors, multi-language documents, scanned PDFs, Word/Excel files.

Limitations: Higher cost per document than local processing. Privacy considerations for sensitive documents (check your provider's data handling).

Honest Comparison

Factor	Regex	Templates	AI API
Setup time	Low	Medium	Very low
Accuracy (known format)	High	High	High
Accuracy (variable formats)	Low	Medium	High
Maintenance burden	High	High	Low
Cost per document	Zero	Zero	Small fee
Scalability	Code changes	Template changes	None

The Practical Choice

For most accounts payable automation projects:

Under 5 vendors, stable formats: Regex is fine
5-50 vendors, some variation: Templates + regex hybrid
50+ vendors or unknown formats: AI extraction is the only practical option

ParseFlow uses the AI approach, handling PDF, Word, and Excel with a single API endpoint. The free tier covers 100 documents/month — enough to validate the approach before committing.

Building Retention Playbooks: Proven Strategies to Reduce SaaS Churn

DevToolsmith — Wed, 15 Apr 2026 10:13:42 +0000

Churn reduction is not a single tactic — it's a system. The best SaaS companies treat each at-risk customer segment differently, with specific playbooks tailored to why they're likely to churn. Here's how to build them.

The Four At-Risk Segments

1. New Customers (Days 1-30)

Risk: Haven't reached activation. Haven't seen core value yet.
Signal: Haven't completed onboarding, low feature usage in week 2.

New customers churn when the gap between signup expectations and reality is too wide. The solution: accelerate time-to-value.

Playbook: Activation acceleration
Day 0:  Personalised welcome + first action prompt
Day 3:  Check-in email: "Have you tried X yet?"
Day 7:  Success story from similar customer
Day 14: Feature spotlight they haven't used
Day 21: "How's it going?" + offer a call
Day 28: Renewal reminder with value recap

2. Disengaged Mid-Tier Customers

Risk: Usage dropping month-over-month. Haven't logged in for 14+ days.
Signal: Login frequency down >50% vs baseline.

These customers haven't decided to cancel yet — they're just drifting. Re-engagement while they're still subscribed is dramatically easier than win-back.

Playbook: Re-engagement
Week 1: Feature they've never tried (personalised)
Week 2: Case study from their industry
Week 3: "We noticed you haven't been around — anything we can help with?"
Week 4: Personal outreach from account manager

3. High-Value Customers at Contract Renewal

Risk: Evaluating alternatives. May downgrade.
Signal: Contract renewal date approaching, recent support tickets, pricing page visits.

These customers represent outsized revenue. They deserve white-glove treatment.

Playbook: Renewal protection
90 days before: Executive Business Review invitation
60 days before: Usage summary + ROI report
45 days before: New features relevant to their use case
30 days before: Renewal conversation with CSM
14 days before: Contract sent with expansion offer

4. Customers After Repeated Payment Failures

Risk: Billing friction converting to active cancellation.
Signal: 2+ failed payment attempts.

A customer who's had 3 payment failures and still hasn't cancelled is signalling intent to stay — they just need to be helped through the update process.

Playbook: Payment recovery
Failure 1: Soft reminder, auto-retry scheduled
Failure 2: Help email with direct update link + live chat
Failure 3: Phone call offer + temporary grace period
Failure 4: "We'd hate to lose you" — discount to stay

Measuring Playbook Effectiveness

Each playbook needs metrics to improve over time:

Playbook	Key Metric
Activation	Time-to-first-key-action
Re-engagement	30-day reactivation rate
Renewal	Net Revenue Retention (NRR)
Payment recovery	Recovery rate %

Track cohorts separately. A customer who needed the payment recovery playbook and stayed is worth more than average — they've demonstrated intent to continue.

Automating Playbook Triggers

// Example: trigger re-engagement playbook
async function checkEngagementHealth() {
  const users = await db.users.findAll({
    where: {
      lastLoginAt: { [Op.lt]: subDays(new Date(), 14) },
      status: 'active',
      segment: { [Op.not]: 'at-risk' }, // not already in a playbook
    },
  });

  for (const user of users) {
    await playbookEngine.trigger('re-engagement', user.id);
    await db.users.update({ segment: 'at-risk' }, { where: { id: user.id } });
  }
}

ChurnGuard includes four pre-built retention playbooks (New Customer, High-Value, Long-Term, Repeat Failure) with customisable email templates, trigger conditions, and a recovery dashboard showing revenue saved per playbook. The automation runs in the background while you focus on building product.

The best churn reduction strategy is the one that runs automatically, 24/7, without requiring a dedicated CSM for every account.

EU AI Act Compliance for SMEs: What You Actually Need to Do Before August 2026

DevToolsmith — Thu, 09 Apr 2026 09:00:07 +0000

The EU AI Act deadline for high-risk AI systems is August 2, 2026. That's roughly 4 months away.

If you're running an SME that uses AI — chatbots, recommendation engines, hiring tools, content moderation, credit scoring — this regulation applies to you. Not just to big tech. Not just to EU-based companies. Anyone serving EU customers.

This guide cuts through the legal jargon and tells you exactly what to do.

Who Is Actually Affected?

The AI Act uses a risk-based classification:

Unacceptable Risk (Banned)

Social scoring by governments
Real-time biometric surveillance in public spaces
Manipulation of vulnerable groups

If you're doing any of these, stop. No compliance checklist will help.

High Risk (Strict Requirements — August 2026 deadline)

HR/Recruitment: AI screening resumes, ranking candidates
Credit scoring: AI assessing creditworthiness
Education: AI grading students, determining access
Healthcare: AI assisting diagnosis or treatment
Law enforcement: AI in predictive policing, evidence evaluation
Critical infrastructure: AI managing energy, water, transport

Limited Risk (Transparency obligations)

Chatbots: Must disclose they're AI
Deepfakes: Must be labeled as AI-generated
Emotion recognition: Must inform the user

Minimal Risk (No obligations)

Spam filters, AI in video games, inventory management

Most SMEs fall into Limited or High Risk. If you have a customer-facing chatbot, you're at minimum in the "limited risk" category with transparency obligations.

The 5 Key Obligations for SMEs

1. Risk Classification

First, classify every AI system you operate or deploy:

What does it do? (chatbot, recommendation, scoring, generation)
Who does it affect? (employees, customers, general public)
What's the impact? (convenience vs. life-changing decisions)

Document this. Regulators will ask.

2. Technical Documentation

For high-risk systems, you need:

Description of the system's purpose and intended use
Design specifications and development methodology
Training data: sources, preparation, known biases
Performance metrics and testing results
Risk assessment and mitigation measures

For limited-risk systems, lighter documentation suffices — but "we use ChatGPT" is not documentation.

3. Human Oversight

High-risk AI must have:

A human who can understand the system's outputs
The ability to override AI decisions
Clear escalation procedures
Logging of AI decisions for review

This doesn't mean a human reviews every decision. It means a human can intervene when needed.

4. Transparency

All AI systems interacting with people must:

Clearly disclose they're AI (chatbots, virtual assistants)
Label AI-generated content (images, text, audio)
Inform users about automated decision-making
Provide explanations when AI decisions affect individuals

5. Data Governance

Training data must be:

Relevant and representative
Free from known biases (or biases documented and mitigated)
Compliant with GDPR (you're already doing this, right?)
Properly versioned and traceable

How to Self-Assess: Step by Step

Step 1: Inventory (Week 1)

List every AI system in your company. Include third-party tools:

Customer support chatbot (e.g., Intercom with AI)
Email marketing personalization
HR screening tools
Recommendation engines
Content generation tools

Step 2: Classify (Week 2)

For each system, determine the risk level using the categories above. When in doubt, classify higher.

Step 3: Gap Analysis (Week 3)

Compare current state with requirements:

Do you have documentation? ❌/✅
Is there human oversight? ❌/✅
Are users informed? ❌/✅
Is training data documented? ❌/✅

Step 4: Remediate (Weeks 4-12)

Prioritize by risk level. High-risk systems first. Start with documentation — it's the most time-consuming.

Step 5: Ongoing Monitoring

Compliance isn't a one-time event. You need:

Regular re-assessment (quarterly)
Incident reporting procedures
Updated documentation when systems change

Tools and Resources

Automated assessment: CompliPilot runs 200+ automated checks against EU AI Act requirements. Free tier: 3 assessments/month. It classifies your AI systems, identifies gaps, and generates documentation templates.

Official guidance: The EU AI Office publishes implementation guidelines — dense but authoritative.

Legal counsel: For high-risk systems, get a lawyer. Automated tools handle the checklist; lawyers handle the gray areas.

The Fines Are Real

Prohibited AI practices: Up to EUR 35M or 7% of global annual turnover
High-risk non-compliance: Up to EUR 15M or 3% of turnover
Incorrect information to authorities: Up to EUR 7.5M or 1% of turnover

For SMEs, there are reduced fines — but "reduced" still means potentially business-ending amounts.

The Other EU Regulation You're Probably Ignoring

While you're sorting AI compliance, check your website accessibility. The European Accessibility Act (EAA) has been enforced since June 2025, with fines up to EUR 300K per violation.

FixMyWeb scans your website for 201 WCAG accessibility issues in 60 seconds. Because getting fined for two EU regulations simultaneously would be embarrassing.

And if your SaaS handles recurring payments, PaymentRescue recovers 30-50% of failed payments automatically — because compliance costs money, and you'll want to plug revenue leaks elsewhere.

Action Plan: April to August 2026

Month	Action
April	Complete AI inventory and risk classification
May	Begin documentation for high-risk systems
June	Implement transparency measures (chatbot disclosures, content labeling)
July	Complete human oversight procedures, test incident reporting
August	Final review, submit conformity assessment if required

Start Now

Four months sounds like a lot until you realize that documentation alone takes 4-6 weeks for a high-risk system.

Run a free compliance check today. You'll know in 5 minutes whether you have a problem — and exactly what to fix.

The companies that start now will be compliant by August. The ones that wait until July will be scrambling. Don't be the latter.

Is your company preparing for the EU AI Act? What's been the biggest challenge? Share in the comments.

How to Build a Visual Monitoring System with a Screenshot API (Node.js + CaptureAPI)

DevToolsmith — Sun, 05 Apr 2026 19:46:55 +0000

Your website looked fine yesterday. Today, the hero banner is broken, the checkout button disappeared behind a modal, and nobody noticed until a customer complained on Twitter.

Visual monitoring catches these issues before your users do. In this tutorial, I'll walk you through building a complete visual monitoring system using Node.js and a screenshot API. By the end, you'll have a working tool that automatically captures screenshots of your web pages, compares them over time, and alerts you when something looks wrong.

What Is Visual Monitoring?

Visual monitoring is the practice of periodically capturing screenshots of your web pages and comparing them against a known-good baseline. Unlike functional testing (which checks if buttons work) or uptime monitoring (which checks if the server responds), visual monitoring catches how things look.

This matters because:

CSS changes can break layouts silently
Third-party scripts (ads, chat widgets) can shift content
CMS updates can overwrite templates
Deployments can introduce visual regressions

The Architecture

Here's what we're building:

+----------------+     +----------------+     +----------------+
|  Scheduler     |---->|  Screenshot    |---->|  Comparison    |
|  (cron job)    |     |  Capture       |     |  Engine        |
+----------------+     +----------------+     +----------------+
                                                      |
                                               +------v------+
                                               |  Alert      |
                                               |  System     |
                                               +-------------+

Components:

A scheduler that runs at defined intervals
A screenshot capture service (using CaptureAPI)
A pixel comparison engine
An alerting system (email/Slack/webhook)

Prerequisites

Node.js 18+
A CaptureAPI account (free tier gives you 200 screenshots/month)
Basic familiarity with async/await

Step 1: Project Setup

mkdir visual-monitor && cd visual-monitor
npm init -y
npm install node-cron pixelmatch pngjs node-fetch@3

Create the folder structure:

mkdir -p screenshots/{baseline,current}

Step 2: Capture Screenshots with CaptureAPI

CaptureAPI provides a simple REST endpoint that returns a screenshot as a PNG. Here's the capture module:

// capture.js
import fs from 'fs/promises';
import path from 'path';

const API_KEY = process.env.CAPTUREAPI_KEY;
const BASE_URL = 'https://api.captureapi.dev/v1/screenshot';

export async function captureScreenshot(url, filename, options = {}) {
  const params = new URLSearchParams({
    url,
    format: 'png',
    viewport_width: options.width || '1280',
    viewport_height: options.height || '800',
    full_page: options.fullPage || 'false',
    delay: options.delay || '2000', // wait for dynamic content
  });

  const response = await fetch(`${BASE_URL}?${params}`, {
    headers: { 'Authorization': `Bearer ${API_KEY}` }
  });

  if (!response.ok) {
    throw new Error(`Screenshot failed: ${response.status} ${response.statusText}`);
  }

  const buffer = Buffer.from(await response.arrayBuffer());
  const filepath = path.resolve('screenshots', 'current', filename);
  await fs.writeFile(filepath, buffer);

  console.log(`Captured: ${url} -> ${filepath}`);
  return filepath;
}

Key decisions:

The delay parameter gives JavaScript-heavy pages time to render
We default to 1280x800 viewport, which represents a common desktop resolution
full_page is off by default to keep comparison fast, but you can enable it for content-heavy pages

Step 3: Build the Pixel Comparison Engine

This is where the magic happens. We'll use pixelmatch, a fast pixel-level image comparison library:

// compare.js
import fs from 'fs/promises';
import path from 'path';
import { PNG } from 'pngjs';
import pixelmatch from 'pixelmatch';

export async function compareScreenshots(baselineFile, currentFile) {
  const baselineBuffer = await fs.readFile(
    path.resolve('screenshots', 'baseline', baselineFile)
  );
  const currentBuffer = await fs.readFile(
    path.resolve('screenshots', 'current', currentFile)
  );

  const baseline = PNG.sync.read(baselineBuffer);
  const current = PNG.sync.read(currentBuffer);

  // Handle size mismatches (layout shift detection)
  if (baseline.width !== current.width || baseline.height !== current.height) {
    return {
      match: false,
      diffPercentage: 100,
      reason: `Size changed: ${baseline.width}x${baseline.height} -> ${current.width}x${current.height}`
    };
  }

  const { width, height } = baseline;
  const diff = new PNG({ width, height });

  const mismatchedPixels = pixelmatch(
    baseline.data, current.data, diff.data,
    width, height,
    { threshold: 0.1 } // tolerance for anti-aliasing
  );

  const totalPixels = width * height;
  const diffPercentage = (mismatchedPixels / totalPixels) * 100;

  // Save diff image for debugging
  const diffPath = path.resolve('screenshots', `diff-${currentFile}`);
  await fs.writeFile(diffPath, PNG.sync.write(diff));

  return {
    match: diffPercentage < 0.5, // less than 0.5% difference = OK
    diffPercentage: Math.round(diffPercentage * 100) / 100,
    mismatchedPixels,
    diffImagePath: diffPath
  };
}

Why 0.5% threshold? In practice, sub-pixel rendering differences between captures can cause tiny variations. A 0.5% threshold filters out noise while catching real issues. You can tune this per page -- a mostly-static landing page might use 0.1%, while a page with animated elements might need 2%.

Step 4: Configure Monitoring Targets

Define the pages you want to monitor in a simple config file:

// config.js
export const pages = [
  {
    name: 'homepage',
    url: 'https://yoursite.com',
    threshold: 0.5,
    viewport: { width: 1280, height: 800 }
  },
  {
    name: 'pricing',
    url: 'https://yoursite.com/pricing',
    threshold: 0.3, // stricter -- pricing page should rarely change
    viewport: { width: 1280, height: 800 }
  },
  {
    name: 'checkout-mobile',
    url: 'https://yoursite.com/checkout',
    threshold: 1.0,
    viewport: { width: 375, height: 812 } // iPhone viewport
  }
];

export const alertConfig = {
  webhookUrl: process.env.SLACK_WEBHOOK_URL,
  emailTo: process.env.ALERT_EMAIL
};

Step 5: Build the Alert System

// alert.js
import { alertConfig } from './config.js';

export async function sendAlert(pageName, result) {
  const message = {
    text: `Visual change detected on *${pageName}*`,
    blocks: [
      {
        type: 'section',
        text: {
          type: 'mrkdwn',
          text: [
            `*Visual Change Detected*`,
            `Page: ${pageName}`,
            `Difference: ${result.diffPercentage}%`,
            `Pixels changed: ${result.mismatchedPixels.toLocaleString()}`,
            result.reason || ''
          ].filter(Boolean).join('\n')
        }
      }
    ]
  };

  // Slack webhook
  if (alertConfig.webhookUrl) {
    await fetch(alertConfig.webhookUrl, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(message)
    });
  }

  // Console fallback
  console.warn(
    `ALERT: ${pageName} changed by ${result.diffPercentage}%`
  );
}

Step 6: Wire Everything Together

// monitor.js
import cron from 'node-cron';
import { captureScreenshot } from './capture.js';
import { compareScreenshots } from './compare.js';
import { sendAlert } from './alert.js';
import { pages } from './config.js';

async function runCheck(page) {
  const filename = `${page.name}.png`;

  try {
    await captureScreenshot(page.url, filename, {
      width: page.viewport?.width,
      height: page.viewport?.height
    });

    const result = await compareScreenshots(filename, filename);

    if (!result.match && result.diffPercentage > page.threshold) {
      await sendAlert(page.name, result);
      return { page: page.name, status: 'changed', ...result };
    }

    return { page: page.name, status: 'ok', ...result };
  } catch (error) {
    console.error(`Error monitoring ${page.name}:`, error.message);
    return { page: page.name, status: 'error', error: error.message };
  }
}

async function runAllChecks() {
  console.log(`--- Visual check started at ${new Date().toISOString()} ---`);

  const results = await Promise.allSettled(
    pages.map(page => runCheck(page))
  );

  const summary = results.map(r =>
    r.status === 'fulfilled' ? r.value : { status: 'error', error: r.reason }
  );

  console.table(summary.map(s => ({
    Page: s.page,
    Status: s.status,
    'Diff %': s.diffPercentage || '-'
  })));
}

// Run every 30 minutes
cron.schedule('*/30 * * * *', runAllChecks);

// Also run immediately on start
runAllChecks();

Step 7: Baseline Management

You need a way to set and update baselines. Add this utility:

// baseline.js
import fs from 'fs/promises';
import path from 'path';
import { captureScreenshot } from './capture.js';
import { pages } from './config.js';

async function updateBaselines() {
  for (const page of pages) {
    const filename = `${page.name}.png`;
    await captureScreenshot(page.url, filename, {
      width: page.viewport?.width,
      height: page.viewport?.height
    });

    // Copy current to baseline
    const src = path.resolve('screenshots', 'current', filename);
    const dest = path.resolve('screenshots', 'baseline', filename);
    await fs.copyFile(src, dest);

    console.log(`Baseline updated: ${page.name}`);
  }
}

updateBaselines().catch(console.error);

Run node baseline.js after every intentional visual change to update your reference images.

Running It in Production

For production, add a package.json scripts section:

{
  "type": "module",
  "scripts": {
    "monitor": "node monitor.js",
    "baseline": "node baseline.js"
  }
}

Then deploy it however you prefer:

Docker + cron: Package it in a container and let the built-in node-cron handle scheduling
GitHub Actions: Use a scheduled workflow to run the check every hour
AWS Lambda + EventBridge: Trigger the check function on a schedule

A GitHub Actions example:

# .github/workflows/visual-monitor.yml
name: Visual Monitor
on:
  schedule:
    - cron: '0 */2 * * *'  # every 2 hours
  workflow_dispatch: # manual trigger

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install
      - run: node baseline.js
        env:
          CAPTUREAPI_KEY: ${{ secrets.CAPTUREAPI_KEY }}
      - run: node monitor.js
        env:
          CAPTUREAPI_KEY: ${{ secrets.CAPTUREAPI_KEY }}
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

Practical Tips From Real Usage

1. Ignore dynamic regions. Cookie banners, timestamps, and ads will trigger false positives. CaptureAPI supports hide_selectors to hide elements before capture:

const params = new URLSearchParams({
  url,
  hide_selectors: '.cookie-banner, .timestamp, .ad-slot'
});

2. Monitor mobile and desktop. Many visual bugs only appear at specific viewports. Test at least 1280px (desktop), 768px (tablet), and 375px (mobile).

3. Run after deployments. Wire the check into your CI/CD pipeline as a post-deploy step. Catch regressions within minutes instead of hours.

4. Pair with other monitoring tools. Visual monitoring tells you what changed. Pair it with document extraction tools like ParseFlow to monitor content changes (prices, terms, legal text), or with FixMyWeb to catch accessibility regressions alongside visual ones.

Cost Estimation

With CaptureAPI's free tier (200 screenshots/month), you can monitor:

3 pages x 2 viewports x every 2 hours = ~360 captures/month
Or 5 pages at desktop-only, checked hourly during business hours = ~220 captures/month

For most small-to-medium projects, the free tier is enough to get started. Paid plans scale up from there.

What We Built

In about 200 lines of code, we created a system that:

Captures screenshots of any URL on a schedule
Compares them pixel-by-pixel against a baseline
Generates diff images for debugging
Sends alerts when visual changes exceed a threshold
Handles multiple viewports and per-page sensitivity

The full source is modular -- you can swap the capture service, add different alerters, or extend the comparison with perceptual hashing for even smarter matching.

Visual monitoring is one of those tools you don't appreciate until the first time it saves you from shipping a broken page to production. Once it catches your first real bug, you'll wonder how you ever lived without it.

Get 200 free screenshots/month at captureapi.dev to start building your own visual monitoring pipeline.

Have you set up visual monitoring for your projects? I'd love to hear about your approach in the comments.

Why I Built 200+ Digital Templates as a Solo Creator (And What Actually Sells)

DevToolsmith — Fri, 03 Apr 2026 18:44:51 +0000

How Failed Payments Are Silently Killing Your SaaS Revenue (And How to Fix It)

DevToolsmith — Thu, 02 Apr 2026 22:08:15 +0000

How Failed Payments Are Silently Killing Your SaaS Revenue

Here's a number most SaaS founders don't track: involuntary churn.

Not the customers who cancel because they're unhappy. The ones who want to keep paying but can't — because their credit card expired, hit its limit, or the bank flagged the transaction.

On average, involuntary churn accounts for 20-40% of total churn in subscription businesses. For a SaaS doing $50K MRR, that's $4,500-$9,000 in annual revenue quietly disappearing.

The Math Behind Failed Payments

Let's break it down:

Average card expiration rate: ~25% of cards per year
Average payment failure rate: 5-10% of renewal attempts
Average recovery rate without dunning: ~15% (banks auto-retry)
Average recovery rate with dunning: 40-60%

If you're not running a dunning process, you're recovering less than a quarter of what you could be.

A Real Example

Say you have:

500 subscribers at $49/month = $24,500 MRR
7% monthly payment failure rate = 35 failed payments
Without dunning: ~5 recovered naturally = $245 saved
With dunning: ~17 recovered = $833 saved
Monthly difference: $588
Annual difference: $7,056

That's a senior developer's bonus. From payments your customers already agreed to make.

Why Payments Fail

The top reasons, based on Stripe's own data:

Insufficient funds (30-35%) — Timing issue. Retry in 3-5 days.
Card expired (25-30%) — Customer needs to update. Email them.
Bank decline (15-20%) — Fraud detection or processing issue. Retry.
Card lost/stolen (10%) — Customer needs new card. Reach out.
Processing error (5-10%) — Temporary. Auto-retry usually works.

Each reason needs a different recovery strategy. A single "your payment failed" email won't cut it.

The 3-Step Dunning Sequence That Works

After analyzing recovery patterns across subscription businesses, here's what consistently performs:

Step 1: Immediate (Day 0)

Subject: "Quick heads up — we couldn't process your payment"

Tone: Helpful, not alarming. Include a direct link to update payment details. Mention the specific plan they're on so it feels personal.

Recovery rate at this step: 25-35%

Step 2: Gentle Follow-up (Day 3)

Subject: "Your [Product] access expires soon — update your card"

Slightly more urgent. Mention what they'll lose access to. Include the amount and next retry date.

Cumulative recovery rate: 40-50%

Step 3: Final Notice (Day 7)

Subject: "Last chance to keep your [Product] account active"

Direct but respectful. Make it clear this is the final attempt. Offer to help if there's an issue with billing.

Cumulative recovery rate: 50-60%

Implementation Options

DIY with Stripe Webhooks

Listen for invoice.payment_failed events and trigger emails via Resend, SendGrid, or Postmark. Works, but you need to:

Handle retries yourself
Build the email templates
Track recovery metrics
Handle edge cases (multiple failures, plan changes during dunning)

Dedicated Dunning Tools

Tools like ChurnGuard connect via Stripe Connect OAuth and handle the entire dunning flow automatically. Setup takes ~5 minutes.

The ROI calculator at paymentrescue.dev/calculator shows exactly how much you're leaving on the table.

Beyond Email: Advanced Recovery Tactics

Smart retry timing — Don't retry at midnight. Retry when the bank is most likely to approve (morning, weekday, after payday).
Card updater services — Stripe's Automatic Card Updating handles some expired cards silently. Make sure it's enabled.
In-app notifications — For active users, show a banner in your app alongside the email.
SMS for high-value accounts — For enterprise plans, a text message can cut through inbox noise.

Measuring Recovery Performance

Track these metrics monthly:

Payment failure rate: Target < 5%
Recovery rate: Target > 50%
Revenue recovered: Track in absolute dollars
Time to recovery: How quickly you're getting payments back

If you're also building APIs, tools like CaptureAPI can help generate visual reports and dashboards showing your recovery metrics over time.

FAQ

How aggressive should dunning emails be?

Never aggressive. These are customers who want to pay you. The tone should be helpful and informative. "Hey, your card didn't go through" not "PAY NOW OR LOSE ACCESS."

Should I pause service during dunning?

Best practice: maintain full access during the dunning period (7-14 days). Locking users out immediately increases voluntary churn on top of the involuntary churn.

Does dunning work for annual subscriptions?

Absolutely — and it's even more important. A single failed annual payment is 12 months of revenue at risk.

Stop losing revenue to expired credit cards. Check your potential recovery at paymentrescue.dev/calculator.

EAA Compliance Checklist: 10 Things Every EU Website Must Fix in 2026

DevToolsmith — Thu, 02 Apr 2026 22:08:11 +0000

EAA Compliance Checklist: 10 Things Every EU Website Must Fix in 2026

The European Accessibility Act (EAA) has been enforced across all 27 EU member states since June 28, 2025. If your website serves European customers, it must meet WCAG 2.1 AA standards — or face fines up to EUR 300,000.

I've analyzed hundreds of websites and these are the 10 most common accessibility failures, with code-level fixes for each.

1. Missing Alt Text on Images

WCAG 1.1.1 — Non-text Content

This is the #1 failure across all websites we scan. Screen readers can't describe images without alt text, making visual content invisible to blind users.

<!-- Bad -->
<img src="hero.jpg">

<!-- Good -->
<img src="hero.jpg" alt="Team collaborating on accessibility audit">

<!-- Decorative (intentionally empty) -->
<img src="divider.svg" alt="">

Rule: Every image needs alt. Decorative images get alt="" (empty, not missing).

2. Insufficient Color Contrast

WCAG 1.4.3 — Contrast (Minimum)

Light gray text on white backgrounds fails 78% of the sites we scan. The minimum contrast ratios:

Normal text (< 18pt): 4.5:1
Large text (>= 18pt or 14pt bold): 3:1
UI components and graphical objects: 3:1

/* Bad: 2.5:1 contrast */
color: #999;
background: #fff;

/* Good: 7:1 contrast */
color: #333;
background: #fff;

3. Missing Form Labels

WCAG 1.3.1 — Info and Relationships

Forms without <label> elements are unusable for screen reader users. They hear "edit text" with no context.

<!-- Bad -->
<input type="email" placeholder="Enter email">

<!-- Good -->
<label for="email">Email address</label>
<input type="email" id="email" placeholder="Enter email">

Note: Placeholder text is NOT a substitute for labels. Placeholders disappear when typing.

4. No Keyboard Navigation

WCAG 2.1.1 — Keyboard

All interactive elements must be reachable with Tab key. The biggest culprits:

Custom dropdown menus built with <div> instead of <select>
Click handlers on non-focusable elements
outline: none with no visible alternative

/* Bad: removes all focus indication */
*:focus { outline: none; }

/* Good: custom but visible focus */
*:focus-visible {
  outline: 2px solid #4A90D9;
  outline-offset: 2px;
}

5. Missing Skip Navigation Link

WCAG 2.4.1 — Bypass Blocks

Keyboard users shouldn't tab through 50 navigation links on every page. Add a skip link:

<body>
  <a href="#main" class="skip-link">Skip to main content</a>
  <nav>...</nav>
  <main id="main">...</main>
</body>

6. Auto-Playing Media

WCAG 1.4.2 — Audio Control

Auto-playing video or audio disorients screen reader users and can trigger issues for users with cognitive disabilities.

Fix: Never auto-play. If essential, provide an immediately visible pause button and keep it under 5 seconds.

7. Missing Language Attribute

WCAG 3.1.1 — Language of Page

Without lang, screen readers guess the language — often incorrectly, resulting in garbled pronunciation.

<html lang="en">
<!-- For inline foreign language -->
<p lang="fr">Bonjour le monde</p>

8. Non-Descriptive Link Text

WCAG 2.4.4 — Link Purpose

Screen reader users often navigate by links. "Click here" tells them nothing about the destination.

<!-- Bad -->
<a href="/guide">Click here</a>

<!-- Good -->
<a href="/guide">Read the EAA compliance guide</a>

9. Missing Heading Hierarchy

WCAG 1.3.1 — Info and Relationships

Screen reader users navigate by headings (H1-H6). Skipping levels breaks this navigation pattern.

<!-- Bad: H1 then H4 (skips H2, H3) -->
<h1>Home</h1>
<h4>Features</h4>

<!-- Good: sequential -->
<h1>Home</h1>
<h2>Features</h2>
<h3>Feature Detail</h3>

10. No Accessibility Statement

EAA Article 14

The EAA specifically requires a public accessibility statement on every website. It must include:

Current WCAG compliance level (A, AA, or AAA)
Known limitations and workarounds
Contact information for accessibility feedback
Date of last accessibility audit

Check All 10 in 60 Seconds

FixMyWeb checks all 10 issues above — plus 191 more — in a single automated scan. The free tier covers 3 scans per month. It also generates an Accessibility Statement automatically.

EAA Fines by Country

Country	Maximum Fine
Spain	EUR 300,000
France	EUR 250,000
Ireland	EUR 200,000
Austria	EUR 200,000
Germany	EUR 100,000

Daily fines of approximately EUR 1,000 are possible until issues are resolved.

FAQ

Does the EAA apply to non-EU companies?

Yes. If your website serves EU customers, the EAA applies regardless of where your company is headquartered.

What WCAG level does the EAA require?

WCAG 2.1 Level AA is the baseline. Some member states may add additional requirements.

Can I use an overlay widget instead of fixing the code?

Overlays do not provide genuine compliance. Many accessibility experts and organizations advise against them. Fix the underlying code.

Scan your website: fixmyweb.dev — 201 checks, free tier. Also: CompliPilot for EU AI Act, CaptureAPI for screenshot API.

How to Build a Website Screenshot API with Node.js and Puppeteer

DevToolsmith — Wed, 01 Apr 2026 23:28:36 +0000

Need to capture website screenshots programmatically? Here is how to build your own screenshot API using Node.js and Puppeteer.

Why Screenshot APIs?

Common use cases:

Social media previews - Generate OG images from any URL
PDF reports - Convert HTML dashboards to PDF
Visual regression testing - Catch UI bugs before deploy
Monitoring - Track visual changes on competitor sites
Documentation - Auto-generate screenshots for docs

The Stack

Node.js + Express + Puppeteer + @sparticuz/chromium

Step 1: Setup

mkdir screenshot-api && cd screenshot-api
npm init -y
npm install express puppeteer-core @sparticuz/chromium

Step 2: Basic Screenshot Endpoint

const express = require("express");
const chromium = require("@sparticuz/chromium");
const puppeteer = require("puppeteer-core");

const app = express();

app.get("/screenshot", async (req, res) => {
  const { url, width = 1280, height = 720 } = req.query;

  if (!url) return res.status(400).json({ error: "URL required" });

  const browser = await puppeteer.launch({
    args: chromium.args,
    executablePath: await chromium.executablePath(),
    headless: chromium.headless,
  });

  const page = await browser.newPage();
  await page.setViewport({ width: +width, height: +height });
  await page.goto(url, { waitUntil: "networkidle0" });

  const screenshot = await page.screenshot({ type: "png" });
  await browser.close();

  res.type("image/png").send(screenshot);
});

app.listen(3000);

Step 3: Add PDF Generation

app.get("/pdf", async (req, res) => {
  const { url } = req.query;
  // ... browser setup same as above

  const pdf = await page.pdf({ format: "A4" });
  await browser.close();

  res.type("application/pdf").send(pdf);
});

Step 4: Deploy to Vercel

Use @sparticuz/chromium-min for Vercel serverless:

npm install @sparticuz/chromium-min

This keeps the bundle under Vercel 50MB limit.

Or Just Use an API

If you do not want to maintain your own infrastructure, CaptureAPI handles screenshots, PDFs, and OG images with a single endpoint. Free tier: 200 captures/month.

curl "https://captureapi.dev/api/screenshot?url=https://example.com"

Full source code and docs at captureapi.dev