Forem: younes

How I Built a Free E-Signature Tool for the French Market with Next.js 15

younes — Wed, 11 Feb 2026 09:39:45 +0000

Why Build Another E-Signature Tool?

DocuSign charges €10/month. HelloSign wants your credit card. And none of them feel right for a French freelancer who just needs to sign a bail or a devis.

So I built Signely — a free, privacy-first e-signature platform built specifically for the French market. No account required. No documents uploaded to a server. Everything runs in your browser.

The Tech Stack

Next.js 15 with App Router and React 19
TypeScript end-to-end
Tailwind CSS 3 for styling
pdf-lib for PDF generation
PDF.js (CDN) for PDF rendering
Canvas API for signature drawing
Vercel for hosting
localStorage for signature persistence

No database. No auth. No backend API. The entire app is essentially a static site with client-side logic.

Architecture: Privacy by Design

The key architectural decision was zero server-side document processing. Every competitor uploads your PDF to their servers. Signely doesn't.

User Flow:
    │
    ├── /creer → Draw or type signature
    │            └── Saved to localStorage (dataURL)
    │
    └── /signer → Upload PDF/image
                  ├── PDF.js renders to <canvas>
                  ├── User places signature via drag
                  ├── Canvas composites document + signature
                  └── pdf-lib generates final PDF
                       └── Download (never leaves browser)

This means I don't need GDPR data processing agreements, server-side encryption, or document retention policies. The browser is the server.

Canvas-Based Signature Drawing

The signature pad uses the Canvas API with touch support for mobile. Here's the core approach:

export function SignatureCanvas({ onSignatureChange }: Props) {
  const canvasRef = useRef<HTMLCanvasElement>(null);
  const [isDrawing, setIsDrawing] = useState(false);

  useEffect(() => {
    const ctx = canvasRef.current?.getContext("2d");
    if (!ctx) return;
    ctx.strokeStyle = "rgb(18, 18, 18)";
    ctx.lineWidth = 2.5;
    ctx.lineCap = "round";
    ctx.lineJoin = "round";
  }, []);

  const getCoordinates = (e: React.MouseEvent | React.TouchEvent) => {
    const canvas = canvasRef.current!;
    const rect = canvas.getBoundingClientRect();
    const scaleX = canvas.width / rect.width;
    const scaleY = canvas.height / rect.height;

    if ("touches" in e) {
      const touch = e.touches[0];
      return {
        x: (touch.clientX - rect.left) * scaleX,
        y: (touch.clientY - rect.top) * scaleY,
      };
    }
    return {
      x: (e.clientX - rect.left) * scaleX,
      y: (e.clientY - rect.top) * scaleY,
    };
  };

  // Mouse/touch handlers → beginPath, lineTo, stroke
  // On stop → canvas.toDataURL("image/png") → parent callback
}

Key gotcha: The scaleX/scaleY calculation is essential. The canvas element's CSS size differs from its pixel dimensions. Without this correction, signatures draw offset on high-DPI screens.

I also added touch-none CSS to prevent scroll-while-drawing on mobile — a subtle but critical UX detail.

PDF Rendering + Signing with Canvas Compositing

The document signer renders PDFs using PDF.js loaded from CDN (to avoid Next.js bundling issues with canvas):

function loadPdfJs(): Promise<PDFJsLib> {
  if (window.pdfjsLib) return Promise.resolve(window.pdfjsLib);

  return new Promise((resolve, reject) => {
    const script = document.createElement("script");
    script.src = "https://cdnjs.cloudflare.com/ajax/libs/pdf.js/3.11.174/pdf.min.js";
    script.onload = () => {
      window.pdfjsLib!.GlobalWorkerOptions.workerSrc =
        "https://cdnjs.cloudflare.com/ajax/libs/pdf.js/3.11.174/pdf.worker.min.js";
      resolve(window.pdfjsLib!);
    };
    document.head.appendChild(script);
  });
}

Once the PDF is rendered to a canvas, placing the signature is just canvas compositing:

const generateSignedDocument = async () => {
  const canvas = document.createElement("canvas");
  canvas.width = documentWidth;
  canvas.height = documentHeight;
  const ctx = canvas.getContext("2d")!;

  // Draw document, then signature on top
  ctx.drawImage(documentCanvas, 0, 0);
  ctx.drawImage(signatureImg, sigX, sigY, sigWidth, sigHeight);

  return canvas.toDataURL("image/png");
};

For PDF export, I use pdf-lib to embed the signed image into a proper PDF:

import { PDFDocument } from "pdf-lib";

const pdfDoc = await PDFDocument.create();
const image = await pdfDoc.embedPng(signedImageBytes);
const { width, height } = image.scale(1);
const page = pdfDoc.addPage([width, height]);
page.drawImage(image, { x: 0, y: 0, width, height });
const pdfBytes = await pdfDoc.save();

Users can download as PNG or PDF — both generated entirely client-side.

Building for the French Market

Language & UX

The entire UI is in French. Not "translated" French — native French. Button labels like "Créer ma Signature", "Télécharger en PDF", "Signer un autre document". Error messages, tooltips, FAQs — everything.

This sounds obvious, but most SaaS tools targeting France are English-first with a French translation bolted on. French users notice.

eIDAS Compliance

Signely implements simple electronic signatures (SES) under the EU eIDAS regulation (n°910/2014). This is the most common tier — legally valid for most everyday documents like contracts, leases, quotes, and NDAs.

The key requirements:

Intent to sign — the user explicitly places and confirms the signature
Document integrity — the signed document is a single composite (no separate layers)
Identification — the signature is visually linked to the signer

For advanced/qualified signatures (notarized acts, real estate), you'd need certificate-based signing. But for 95% of French business documents, SES is sufficient and legally binding.

RGPD (French GDPR)

Since no personal data leaves the browser, RGPD compliance is almost automatic. No cookies to consent to (we use Vercel Analytics, which is cookie-free). No user accounts. No document storage. The privacy page practically writes itself.

SEO Strategy for French Keywords

The French e-signature market searches for very specific terms:

"signature électronique en ligne" (~8K/mo)
"signer un document en ligne" (~5K/mo)
"signature électronique gratuite" (~3K/mo)

I built programmatic SEO pages for specific use cases — /cas-usages/bail, /cas-usages/contrat-travail, /cas-usages/devis — each targeting long-tail French keywords with structured data (FAQ schema, WebPage schema).

// Structured data for every page
export const metadata = buildPageMetadata({
  title: "Signature électronique en ligne | Signely",
  description: "Créez et signez vos documents en quelques secondes...",
  path: "/",
});

// FAQ schema for rich snippets
const jsonLd = [
  buildWebPageJsonLd({ path, title, description }),
  buildFaqPageJsonLd(faqEntries),
];

Each use case page has its own FAQ, legal context, and step-by-step guide — all server-rendered for SEO.

What I'd Do Differently

pdf-lib from the start — I initially tried manipulating PDFs with canvas only. pdf-lib is far better for maintaining PDF structure.
Web Workers for PDF rendering — large PDFs can block the main thread. PDF.js supports workers but I should've prioritized this.
IndexedDB over localStorage — signature dataURLs are large strings. IndexedDB handles binary data better.

Results

Fully functional e-signature tool with zero hosting costs (Vercel free tier)
Client-side architecture eliminates GDPR/data processing headaches
Targeting underserved French market with native-language UX
Sub-3-second signature workflow

Try It

🔗 Signely.fr — Free e-signature for the French market

Create a signature, upload a PDF, sign it, download it. Takes about 30 seconds. No signup required.

Have you built tools targeting a specific language/market? What challenges did you face with localization beyond just translating strings? I'd love to hear your approach in the comments.

Building a Multilingual Virtual Keyboard with Next.js — Supporting 100+ Languages

younes — Mon, 09 Feb 2026 21:18:37 +0000

Ever tried typing in Arabic, Thai, or Georgian on a standard QWERTY keyboard? It's painful. You either install system-level keyboard packs, use clunky OS settings, or hunt for sketchy websites covered in ads.

I built AnyKeyboard — a free online virtual keyboard supporting 100+ languages, from Arabic to Zulu. Here's how.

Why Build This?

The existing virtual keyboard landscape is dominated by a few players:

Lexilogos (110K monthly visitors) — functional but dated UI
Branah (46K) — decent coverage but ad-heavy
TypeIt (80K) — limited language support

None of them felt modern. None were built with Next.js or had proper SEO for every language. There was room for something better.

The Architecture

Stack:

Next.js 15 (Pages Router)
Vanilla JavaScript for keyboard interaction
CSS Grid for keyboard layouts
Vercel for hosting
AdSense for monetization

The key architectural decision was one page per keyboard. Each language gets its own URL:

/languages/middle-eastern/arabic-keyboard
/languages/east-asian/japanese-keyboard  
/languages/south-asian/hindi-keyboard
/languages/european/german-keyboard

This is critical for SEO — someone searching "arabic keyboard online" lands directly on the Arabic keyboard page.

Keyboard Layout System

Each keyboard layout is a JSON file:

{
  "language": "Arabic",
  "direction": "rtl",
  "rows": [
    ["ض", "ص", "ث", "ق", "ف", "غ", "ع", "ه", "خ", "ح", "ج", "د"],
    ["ش", "س", "ي", "ب", "ل", "ا", "ت", "ن", "م", "ك", "ط"],
    ["ئ", "ء", "ؤ", "ر", "لا", "ى", "ة", "و", "ز", "ظ"]
  ],
  "shiftRows": [...]
}

The rendering engine handles:

RTL languages (Arabic, Hebrew, Urdu, Farsi)
Complex scripts (Thai, Khmer, Myanmar with combining characters)
Large character sets (Chinese/Japanese with IME-style input)
Diacritics (Vietnamese, Czech with dead keys)

The RTL Challenge

Right-to-left languages were the trickiest part. It's not just about flipping the text direction — the entire UX needs to feel natural:

/* RTL keyboard layout */
.keyboard-container[dir="rtl"] {
  direction: rtl;
}

.keyboard-container[dir="rtl"] .output-area {
  text-align: right;
  direction: rtl;
  unicode-bidi: bidi-override;
}

The cursor behavior, text selection, and copy/paste all needed special handling for RTL scripts.

SEO: The Growth Engine

With 100+ language pages, SEO was the primary growth strategy:

Unique meta titles/descriptions per language
Structured data (WebApplication schema for each keyboard)
Hreflang tags for 86 supported locales
Internal linking between related keyboards
Programmatic content — each page includes typing tips, character references, and cultural context

Results after 3 months:

645 clicks/month from Google (hockey stick growth)
225 pages indexed out of 333 in sitemap
Top keywords: "arabic keyboard online" (position 4), "ukrainian keyboard" (position 7)

Handling Special Characters

Some keyboards need special input methods:

// Dead key support (for diacritics)
let pendingDeadKey = null;

function handleKeyPress(key) {
  if (isDeadKey(key)) {
    pendingDeadKey = key;
    return;
  }

  if (pendingDeadKey) {
    const combined = combineWithDeadKey(pendingDeadKey, key);
    pendingDeadKey = null;
    return insertText(combined);
  }

  insertText(key);
}

// Example: dead key ˆ + a = â
function combineWithDeadKey(dead, base) {
  const combinations = {
    'ˆ': { 'a': 'â', 'e': 'ê', 'i': 'î', 'o': 'ô', 'u': 'û' },
    '¨': { 'a': 'ä', 'e': 'ë', 'i': 'ï', 'o': 'ö', 'u': 'ü' },
    // ... more combinations
  };
  return combinations[dead]?.[base] || base;
}

Monetization: AdSense + Affiliates

The revenue model is simple:

AdSense — display ads on keyboard pages (high traffic, global audience)
Amazon Affiliates — recommend physical keyboards and keyboard stickers for each language

For example, the Arabic keyboard page shows Arabic keyboard stickers on Amazon. The Hindi page shows Hindi stickers. Each recommendation is contextual.

What I Learned

Programmatic SEO works — 100+ pages targeting long-tail keywords compounds over time
Unicode is hard — every script has edge cases (combining characters, ligatures, ZWJ sequences)
RTL is harder than you think — it affects layout, cursor behavior, and copy/paste
Users want simplicity — no signup, no install, just type
Speed matters — keyboard input must feel instant (<16ms response)

Try It

🌐 AnyKeyboard.io — Free virtual keyboards for 100+ languages

No account needed. Pick a language, start typing, copy your text. That's it.

Some popular keyboards:

Working with non-Latin scripts in your projects? What's been your biggest Unicode headache? I'd love to hear your war stories in the comments.

How I Built a Video Downloader SaaS with Next.js 15, yt-dlp, and Cobalt

younes — Mon, 09 Feb 2026 21:16:41 +0000

The Problem

I needed a reliable way to download videos from multiple platforms — YouTube, TikTok, Instagram, Reddit, X, and more. Existing tools were either ad-infested, unreliable, or didn't offer an API for automation.

So I built BlackHole — a video downloading platform with a clean UI and a REST API for developers.

The Tech Stack

Frontend:

Next.js 15 with React 19 and TypeScript
Tailwind CSS v4 for styling
Clerk for authentication
Convex for the database (real-time, serverless)

Backend (Self-hosted on Hetzner VPS):

yt-dlp — handles YouTube downloads with cookie management
Cobalt — handles TikTok, Instagram, Reddit, X, Facebook, Pinterest, Bluesky
Nginx with SSL termination
Docker Compose for orchestration

Payments:

Mollie (European payment provider — supports iDEAL, cards, PayPal)

Architecture: Why Two Download Engines?

This was the first big design decision. YouTube is hard. Their anti-bot measures evolve weekly. Using a single tool for everything means when YouTube breaks (and it will), your entire platform goes down.

My solution: split the workload.

User Request
    │
    ├── YouTube URL? → yt-dlp service (port 8000)
    │                   └── Cookie manager + JS solver
    │
    └── Other platform? → Cobalt service (port 9000)
                          └── Residential proxy for geo-restricted content

yt-dlp runs with a custom cookie manager that rotates browser cookies and handles YouTube's consent pages. Cobalt handles everything else — it's faster and more reliable for non-YouTube platforms.

The Cookie Problem (YouTube)

YouTube aggressively fights automated downloads. Here's what I learned:

Cookies expire fast — YouTube session cookies last hours, not days
IP reputation matters — datacenter IPs get rate-limited instantly
JavaScript challenges — YouTube serves JS challenges that headless browsers struggle with

My solution was a unified cookie manager:

# Simplified cookie manager concept
class CookieManager:
    def __init__(self):
        self.cookies = self.load_cookies()
        self.last_refresh = time.time()

    def get_cookies(self):
        if time.time() - self.last_refresh > COOKIE_TTL:
            self.refresh_cookies()
        return self.cookies

    def refresh_cookies(self):
        # Extract fresh cookies from browser session
        self.cookies = extract_browser_cookies()
        self.last_refresh = time.time()
        self.notify_health_status()  # Telegram alerts

The manager sends health alerts to Telegram — if cookies go stale or downloads start failing, I know within 10 minutes.

Rate Limiting: Don't Get Abused

Free tier users get 5 downloads/day at 720p. But I also needed to prevent abuse from bots hammering the API.

// IP-based rate limiting middleware
const RATE_LIMIT = 10; // requests per minute per IP
const WINDOW_MS = 60_000;

const rateLimiter = new Map<string, { count: number; resetAt: number }>();

export function checkRateLimit(ip: string): boolean {
  const now = Date.now();
  const entry = rateLimiter.get(ip);

  if (!entry || now > entry.resetAt) {
    rateLimiter.set(ip, { count: 1, resetAt: now + WINDOW_MS });
    return true;
  }

  if (entry.count >= RATE_LIMIT) return false;
  entry.count++;
  return true;
}

The API (For Developers)

The Business tier includes a REST API with HMAC-SHA256 signed webhooks:

curl -X POST https://api.blhole.com/v1/download \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://youtube.com/watch?v=dQw4w9WgXcQ",
    "quality": "1080p",
    "format": "mp4",
    "webhook_url": "https://your-app.com/webhook"
  }'

Webhooks are signed so you can verify they're from BlackHole:

const crypto = require('crypto');

function verifyWebhook(payload, signature, secret) {
  const expected = crypto
    .createHmac('sha256', secret)
    .update(payload)
    .digest('hex');
  return crypto.timingSafeEqual(
    Buffer.from(signature),
    Buffer.from(expected)
  );
}

Deployment: Hetzner VPS + Vercel

The frontend runs on Vercel (free tier handles it fine). The download services run on a Hetzner VPS in Helsinki:

# docker-compose.yml (simplified)
services:
  ytdlp:
    build: ./ytdlp-service
    ports:
      - "8000:8000"
    volumes:
      - ./cookies:/app/cookies

  cobalt:
    image: ghcr.io/imputnet/cobalt:latest
    ports:
      - "9000:9000"
    environment:
      - HTTP_PROXY=${PROXY_URL}  # For geo-restricted content

  nginx:
    image: nginx:alpine
    ports:
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - /etc/letsencrypt:/etc/letsencrypt

Total VPS cost: ~€10/month for a server that handles hundreds of downloads daily.

Monitoring: Know Before Users Complain

I set up a monitoring stack that checks every platform every hour:

Download a test video from each supported platform
Verify file integrity (size > 0, valid container)
Alert via Telegram if any platform fails
Track success rates over time

This has saved me multiple times — I've caught YouTube cookie expirations, Cobalt updates that broke TikTok, and VPS disk space issues before any user reported them.

Pricing Strategy

After researching lifetime deal pricing extensively:

Plan	Price	Limits
Free	$0	5/day, 720p, 20min
Pro	$29/year or $149 lifetime	200/day, 4K, 60min
Business	Custom	API access, webhooks, batch

Key lesson: Don't price lifetime deals too low on products with ongoing server costs. I initially had the lifetime at $69 — way too cheap when each user costs bandwidth and compute forever.

Results

Launched on Product Hunt (February 2026)
Listed on G2, DEV Community, SaaSHub, Fazier, and more
Handles YouTube, TikTok, Instagram, Reddit, X, Facebook, Pinterest, and Bluesky
REST API serving developer integrations

What I'd Do Differently

Start with the API first — the developer audience is more willing to pay
Don't fight YouTube alone — yt-dlp community updates are essential
Monitoring from day one — not after the first outage
Price higher — my initial $69 lifetime was leaving money on the table

Try It Out

🔗 BlackHole — Download videos from 8+ platforms

The free tier gives you 5 downloads/day — enough to test everything. If you're building something that needs video downloads, the API might save you weeks of dealing with platform quirks.

What's your experience with video downloading tools? Have you built anything similar? Drop a comment — I'd love to hear about your approach.

Why I Built a 100% Client-Side PDF Toolkit (And Why Privacy Matters)

younes — Sat, 07 Feb 2026 01:15:31 +0000

Every time you upload a PDF to an online tool, you're trusting a stranger with your data. Tax documents, contracts, personal files — they all pass through someone else's servers. I wanted to change that.

The Problem with Traditional PDF Tools

Most online PDF tools work like this:

You upload your file to their server
Their server processes it
You download the result
Your file sits on their server... forever?

Even with privacy policies, you have no real guarantee of what happens to your data. And for sensitive documents, that's a dealbreaker.

The Solution: 100% Client-Side Processing

I built PDFClic — a free PDF toolkit where everything happens in your browser. Your files never leave your device.

Here's how it works:

// All processing happens locally using pdf-lib
import { PDFDocument } from 'pdf-lib';

async function mergePDFs(files) {
  const mergedPdf = await PDFDocument.create();

  for (const file of files) {
    const pdfBytes = await file.arrayBuffer();
    const pdf = await PDFDocument.load(pdfBytes);
    const pages = await mergedPdf.copyPages(pdf, pdf.getPageIndices());
    pages.forEach(page => mergedPdf.addPage(page));
  }

  return await mergedPdf.save();
}

The magic? Libraries like pdf-lib let you manipulate PDFs entirely in JavaScript, with no server round-trip needed.

What You Can Build Client-Side

PDFClic currently offers 27+ tools, all running locally:

Merge & Split — Combine or separate PDF pages
Compress — Reduce file size without quality loss
Convert — PDF to/from images, Word, Excel
Sign — Add signatures directly in the browser
OCR — Extract text from scanned documents
Protect — Add or remove passwords

The Technical Stack

Building a privacy-first tool requires the right choices:

Next.js 15 — For the frontend framework
pdf-lib — Core PDF manipulation
Tesseract.js — Client-side OCR
Web Workers — Keep the UI responsive during heavy processing

The key insight: modern browsers are powerful enough to do what used to require servers.

Why Privacy-First Tools Matter

This approach isn't just about PDFs. The same philosophy applies to:

Virtual keyboards like AnyKeyboard — type in any language without keyloggers
Image editors — edit photos without cloud uploads
Document converters — transform files locally

Every tool that processes your data client-side is a tool that respects your privacy by design.

Try It Yourself

If you need to work with PDFs, give PDFClic a try. It's free, no signup required, and your files stay on your device.

For developers interested in building privacy-first tools: the browser is more capable than you think. Start with pdf-lib for PDFs, Tesseract.js for OCR, and Web Workers for performance.

What privacy-first tools do you use or build? Drop a comment below!

I Built a Free Video Downloader That Actually Works in 2026 🎬

younes — Fri, 06 Feb 2026 10:04:25 +0000

Hey DEV community! 👋

I just launched BlackHole - a free video downloader that works with YouTube, TikTok, Instagram, Reddit, X (Twitter), Facebook, Pinterest, and Bluesky.

Why I Built This

Most video downloaders are either:

Full of ads and sketchy pop-ups
Limited to one platform
Require registration
Don't work half the time

I wanted something clean, fast, and reliable. So I built it.

Tech Stack

Frontend: Next.js 15, React 19, TypeScript, Tailwind CSS v4
Auth: Clerk
Database: Convex
Payments: Mollie
Backend: yt-dlp + Cobalt on VPS

Features

✅ 8+ platforms supported
✅ HD/4K quality options
✅ No registration required for basic use
✅ Clean UI (no ads, no pop-ups)
✅ Private - we don't store your downloads

Try It Out

🔗 blhole.com

Free tier: 5 downloads/day, 720p, 20min limit
Pro tier: 200/day, 4K, 60min limit

Feedback Welcome!

I'm actively improving it based on user feedback. What features would you want to see? Drop a comment below! 👇

Built with ❤️ using Next.js and deployed on Vercel