DEV Community

Open Banking Was Built for the Wrong Future — and That's Why It's Perfect for AI Agents

arun rajkumar — Tue, 07 Apr 2026 19:35:42 +0000

Visa announced infrastructure for AI agents to make payments without asking you first.

GoCardless shipped an MCP server in February so developers can talk to their payment platform in natural language.

I build open banking payment infrastructure for the UK. I've been watching both of these announcements very closely.

And I have a counterintuitive take: the payment rail everyone called "too complicated for normal users" might be the only one that actually works for AI agents.

The Problem With Cards and AI Agents

When an AI agent needs to make a payment on your behalf, the obvious infrastructure is what already exists. Cards. Stored credentials. The same rails your Netflix subscription uses.

Here's the problem.

Card authorisation is broad. When you give Stripe a card token, you're essentially giving that token permission to charge whatever you've authorised — subject to 3DS, fraud rules, and limits. But the authorisation scope isn't bound to a specific action.

For an AI agent, that's dangerous.

You want an agent to book a flight. It has your card token. Nothing technically stops it from booking the wrong flight, adding seat upgrades you didn't ask for, or — if the prompt is maliciously crafted — doing something you absolutely didn't intend.

Visa understands this. Their Trusted Agent Protocol exists precisely to solve it: a way for merchants to verify that an agent is legitimate and acting within its authorised scope. It's clever engineering. But it's being bolted onto rails that weren't designed for it.

Open banking wasn't designed for AI agents either. But its constraints happen to be exactly the right shape.

What Open Banking Consent Actually Looks Like

When a customer pays via open banking — the way Atoa processes payments — here's what actually happens under the hood:

1. Merchant creates a payment consent object
   → amount: £49.99
   → merchant: Atoa test merchant
   → purpose: "Coffee subscription - April"

2. Customer is redirected to their bank
   → Bank shows: "Atoa wants to take £49.99 from your account"
   → Customer approves or declines
   → Bank issues a single-use authorisation code

3. Atoa exchanges the code for the payment
   → One payment. Specific amount. Specific purpose.
   → The authorisation is consumed. It cannot be reused.

Every payment is its own consent event. Every consent is scoped to a specific amount and purpose. You can't overcharge. You can't quietly add extras. You can't reuse the authorisation.

For a human user, this is friction. That's why open banking adoption was slow. Nobody wants to log into their banking app every time they buy something.

For an AI agent, this friction is a feature.

Why the Consent Model Fits AI Agents

Think about what you actually want when an AI agent makes a payment on your behalf.

You want:

It to charge exactly the amount you authorised
The scope to be limited to what you asked it to do
The ability to revoke access without cancelling your card
A clear audit trail showing what was authorised and when
The payment to fail loudly if anything is out of scope — not silently proceed

Open banking gives you all of that by default.

Cards give you none of it by default, and you have to engineer it in.

The FCA even made it better recently. They removed the 90-day re-authentication requirement that was causing 20-40% customer drop-off for third-party payment providers. Persistent consent — once granted to an agent — can now remain valid without forcing a re-authentication loop.

That's a massive unlock for agentic payment flows.

The Real Engineering Challenge: Consent Lifecycle for Agents

Here's where it gets genuinely hard.

When a human completes an open banking payment, the flow is synchronous: they go to the bank, they approve, they come back. Done.

When an AI agent initiates a payment, the flow might look like this:

User: "Book the Bangalore to London flight if the price drops below £600"

Agent: [Monitors prices for 3 days]
Agent: [Price hits £598 on a Wednesday morning]
Agent: [Attempts to initiate payment]
         → But the user's open banking consent was granted for a specific session
         → That session token expired 6 hours ago
         → Payment fails

Result: Agent missed the window. User wakes up to a "couldn't book your flight" message.
        Price is now £640.

Consent that's synchronous and session-bound doesn't work for agents that act asynchronously.

This is the real engineering problem. Not "can AI agents make payments?" — they clearly can. But "what does the consent model look like for an agent that might act hours or days after the user gave permission?"

There are a few approaches:

Option 1: Pre-authorised payment mandates
Open banking supports Variable Recurring Payments (VRPs) — essentially mandates where the user sets a maximum amount and time window, and the payment provider can initiate within those bounds without re-authentication.

// Conceptual structure of a VRP mandate for an agent
interface AgentPaymentMandate {
  agentId: string;
  maxAmountPence: number;      // Agent cannot exceed this
  validUntil: Date;           // Time-bounded consent
  allowedMerchants: string[]; // Scope: only these merchants
  purpose: string;            // What this mandate is for
  requiresConfirmation: boolean; // Some actions still need approval
}

The agent operates within a pre-defined envelope. The user sets the boundaries once. The agent acts within them.

Option 2: Payment intent + human gate
Agent identifies a payment opportunity, creates a payment intent, notifies the user. User approves in one tap. Agent executes.

This is the pattern we're building toward at Atoa — merchant describes what they need in natural language, agent proposes the payment, human approves in one tap, open banking rails execute it.

// What an agent workflow might look like
const intent = await paymentAgent.proposePayment({
  merchant: 'flight-booking-service',
  amount: 59800, // £598.00 in pence
  reason: 'BLR→LHR flight, price hit target of £600',
  expiresAt: new Date(Date.now() + 30 * 60 * 1000), // 30 min window
});

// User gets notified: "Your agent wants to book your flight for £598. Approve?"
// One tap. Payment executes.

Option 3: Programmatic consent with audit trail
For fully autonomous agents — the Visa Intelligent Commerce model — the agent holds delegated credentials scoped to specific actions, with every payment logged against the authorisation that permitted it.

We're not here yet in open banking. But the architecture exists to get there.

What We're Thinking About at Atoa

We build open banking payment infrastructure. POS terminals, payment links, invoicing, online checkouts. Everything goes through bank payment rails.

We're thinking about this differently to most — our payment surfaces each have different agent-readiness, and that's shaped how we're approaching the consent problem. When Visa announced Intelligent Commerce, our first question wasn't "can we compete with this?" It was: "which of our surfaces are ready right now, and which ones need the architecture to change?"

Here's our honest assessment:

Pay by Link — probably the most agent-ready thing we have. An agent could generate a payment link, send it to a customer, and monitor completion. The consent event is triggered by the link recipient, not the agent. The agent just facilitates.

Payment Pages — also strong. A merchant's agent could build and publish a payment page with specific parameters. No card infrastructure needed.

POS Terminal — hardest. The consent flow requires physical presence for SCA. An agent isn't physically present. This one needs new thinking.

Invoicing — interesting. An agent managing a merchant's books could issue invoices and track payment status. The open banking payment confirmation is machine-readable. This is real today.

The shape of "agentic commerce" looks different for each surface. There's no one-size-fits-all answer.

The Question Every Open Banking Developer Should Be Asking

GoCardless shipping an MCP server tells you something important: payment infrastructure companies are now thinking about developers' AI workflows as a first-class use case.

Not just "can humans use our API?" but "can an AI agent use our API safely?"

That's a different design question. An API designed for humans assumes there's a human reading error messages, handling edge cases, making judgment calls. An API designed for agents needs those things to be machine-readable, scoped, and predictable.

Open banking has a head start here. The consent model is explicit. The amounts are bounded. The authorisation chain is auditable. Every payment has a "why" attached to it.

The engineers who figure out the consent lifecycle problem — how do you grant an agent payment permissions that are time-bounded, amount-bounded, and purpose-bounded, without requiring the human to be present at the moment of execution — will be building the infrastructure that the next decade of agentic commerce runs on.

That's the problem I'm thinking about.

What's your take — does the card world catch up to open banking here, or does the consent model give open banking a structural advantage in the agent era?

Arun Rajkumar is CTO & Co-Founder of Atoa, an FCA-authorised open banking payments platform in the UK. He writes about payments, fintech engineering, and building for the UK from India. @mickyarun

The tech market is tough. Here's what actually matters.

Erik Novikov — Tue, 07 Apr 2026 19:35:39 +0000

The situation

Layoffs, an influx of new devs, and AI getting more capable every month. The market is genuinely harder than it was a few years ago — both at entry level and senior. Supply is up, so the average developer's value is down. That's just supply and demand.

But the average developer is not you. Here's why it's not as grim as it looks.

Competence still wins

The market isn't homogeneous. Two developers with the same title and years of experience can be worlds apart in actual ability. What separates them:

1. Problem-solving over knowledge accumulation

The developer who knows three frameworks but can't think through an unfamiliar problem is less valuable than the one with strong fundamentals who can adapt fast. Protocols, concurrency, system design, debugging, fixing and shipping under pressure — these transfer across stacks. Knowing by heart a specific library or framework doesn't.

A concrete example: migrating a microservice from Java to Go. A developer who's never touched Java might freeze. A developer with solid fundamentals in how languages handle concurrency and how services communicate will figure it out. Be the second developer.

2. AI leverage

Use AI to plan, brainstorm, review, and code — but stay in the driver's seat. Vibe-coding your way to a shipped feature might look fast until you spend hours debugging a system you never actually understood. AI is a force multiplier, not a replacement for understanding what you're building.

3. Learning rate

In tech, what you know today matters less than how fast you can learn something new and apply it. The half-life of any specific skill is shrinking. Your ability to pick things up quickly is the most durable asset you have.

Final word

Don't stress over the market. Get extremely good instead. Strong fundamentals, smart use of AI, and a fast learning rate will put you ahead of most. Focus on those and the rest takes care of itself.

What Is Browser Fingerprinting? How Websites Track You Without Cookies (2026)

Hafiz Khurram Javid — Tue, 07 Apr 2026 19:34:43 +0000

You cleared your cookies. You switched to private browsing. You even tried a VPN. And yet the website still knew it was you.

Browser fingerprinting is why - and it works by reading signals from your device that you cannot delete, clear, or turn off.

What Is Browser Fingerprinting?

Browser fingerprinting identifies you by combining technical details about your browser and device into a unique profile. Your GPU model, installed fonts, screen resolution, audio hardware, timezone, and language settings are all read silently - no permission prompt, no cookie banner, no storage on your device.

Each individual signal is not unique. Millions of people have a 1920×1080 screen. Millions use Chrome on Windows. But when you combine 13 or more signals together, the resulting fingerprint is statistically unique for 83–90% of users, according to research from AmIUnique.org and the EFF's Panopticlick project.

Unlike cookies, fingerprinting leaves no trace on your device. There is nothing to clear, nothing to block with standard privacy settings, and nothing that resets when you close your browser.

Cookies vs. Fingerprinting: The Key Difference

	Cookies	Fingerprinting
Stored on your device?	Yes	No
Can you delete it?	Yes	No
Blocked by incognito?	Partially	No
Blocked by cookie banners?	Yes (if compliant)	Rarely
Requires GDPR consent?	Yes	Yes - but often ignored
Survives browser reset?	No	Yes

The 13 Signals That Make Up Your Fingerprint

Here are the main vectors websites use, ranked by how much identifying information each contributes (measured in entropy bits):

🔖 User Agent String - 10.5 bits (High)

Your browser's identity card. Reports your exact browser name, version, OS, and CPU architecture. A single string that narrows you to a very small group.

🎨 Canvas Fingerprint - 8.5 bits (High)

The website draws invisible shapes on a hidden canvas element and reads back the pixel data. Your GPU and OS render these slightly differently, creating a hash unique to your hardware.

🔤 Installed Fonts - 7.5 bits (High)

The exact set of fonts on your system is surprisingly unique. Design tools, games, and work applications all install custom fonts. The combination is often one-of-a-kind.

🔺 WebGL / GPU Renderer - 7.2 bits (High)

WebGL exposes your exact GPU model and driver version to every website without any permission required. Your graphics card is effectively signing every page you visit.

🔊 Audio Fingerprint - 5.4 bits (High)

A silent tone is processed through your audio hardware using the Web Audio API. The tiny differences in how your chip handles it create a unique signature - completely invisible and inaudible.

📐 Screen Resolution - 4.8 bits (Medium)

Your screen width, height, color depth, and device pixel ratio. Multi-monitor and high-DPI configurations are especially distinctive.

🌍 Browser Language - 4.2 bits (Medium)

The languages your browser is configured to use. Multilingual users with uncommon language pairs can be nearly uniquely identified from this single vector.

⚙️ Hardware Profile - 3.1 bits (Medium)

CPU core count and RAM. Combined with other signals, this narrows your device to a small group.

🕐 Timezone - 3.8 bits (Medium)

Your browser reports your real timezone even behind a VPN. A mismatch between your IP geolocation and timezone is a classic VPN detection signal.

How Websites Actually Use Your Fingerprint

The most common uses are ad tracking, fraud detection, and paywall enforcement.

Ad networks build profiles of your browsing behavior across thousands of sites and use fingerprinting to link those sessions together even when you clear cookies. Banks use fingerprinting as a fraud signal - a sudden change in fingerprint triggers verification challenges.

News sites and streaming platforms use fingerprinting to enforce article limits and free trial periods. Clearing cookies resets the counter; fingerprinting does not.

More troublingly, data brokers purchase fingerprint-linked browsing profiles and combine them with offline data. A 2025 investigation found that some brokers could link anonymous browsing sessions to real names and addresses through fingerprint data alone.

Is Browser Fingerprinting Legal?

Under GDPR, fingerprinting constitutes processing of personal data because it creates a unique identifier. This means it requires a lawful basis - almost always consent - and must be disclosed. In practice, most websites outside the EU fingerprint without consent.

Under CCPA and CPRA, browser fingerprints qualify as unique personal identifiers, giving California residents the right to opt out of their sale. Most US state privacy laws passed since 2023 include similar provisions.

The EU's ePrivacy Directive specifically covers fingerprinting and requires consent, but enforcement has been inconsistent.

How to Reduce Your Browser Fingerprint

→ Switch to Brave Browser (highest impact)

Brave actively randomizes canvas, WebGL, audio, and font fingerprinting vectors on every page load. The only mainstream browser with built-in fingerprint randomization that changes per session.

→ Use the Tor Browser (maximum anonymity)

Tor makes every user appear identical by standardizing all fingerprinting vectors. Trade-off: significantly slower browsing.

→ Firefox with Strict Mode (good balance)

Firefox's Enhanced Tracking Protection in strict mode blocks known fingerprinting scripts and restricts font enumeration.

→ Install CanvasBlocker (partial)

A Firefox extension that randomizes canvas fingerprinting output. Effective against canvas tracking but leaves WebGL and audio untouched.

The Paradox of Anti-Fingerprinting

There is a cruel irony at the heart of fingerprinting defense: some protective measures can make you more distinctive.

Enabling Do Not Track, for example, is set by only about 12% of users - meaning having it on is itself a fingerprinting signal. Using an uncommon browser or heavily customizing privacy settings can make your fingerprint more unique rather than less.

The most effective defense is not customization but standardization - using browsers designed to make all users appear identical, like Tor.

Test Your Own Fingerprint

The best way to understand your exposure is to see it directly.

TrustScan's Browser Fingerprint Analyzer runs 13 tracking vectors against your browser, calculates your entropy score, and shows exactly which signals are most identifying - with specific reduction steps.

It runs entirely in your browser. Nothing is collected or transmitted. Free, no account required.

The Bottom Line

Browser fingerprinting is the tracking technique that works after everything else fails. It does not use cookies. It cannot be cleared by standard browser settings. It is not defeated by a VPN alone. And it is used by thousands of advertising networks and data brokers right now.

Understanding what it is - and testing your own exposure - is the first step to making informed decisions about your browser and your privacy.

Originally published at trustscan.dev. TrustScan is a free privacy and security toolkit - 100% client-side, no data collected.

Quantum computing para el dev web que no estudió física: ¿cuándo preocuparse en serio?

Juan Torchia — Tue, 07 Apr 2026 19:32:37 +0000

Hay días que abrís Hacker News y encontrás un post que te hace sentir que sabés muy poco de algo que creías tener medianamente claro. Esta semana fue uno de esos días.

Un criptógrafo cuántico posteó un análisis técnico sobre el estado actual del quantum computing aplicado a criptografía. 289 puntos. 340 comentarios. Yo entendí quizás el 30% del hilo. Y eso que llevo más de una hora intentando seguirlo.

La pregunta que me quedó dando vueltas no es abstracta: ¿cuándo debería yo — un full-stack developer que deployea en Railway, piensa en milisegundos de response time y la semana pasada optimizó una app Next.js de 3 segundos a 300ms — empezar a preocuparme en términos prácticos?

No sé la respuesta. Pero eso es exactamente por qué vale la pena escribir este post.

El quantum computing es básicamente como tener un cerrajero que no intenta cada llave una por una, sino que de alguna manera prueba todas las llaves posibles al mismo tiempo. Y lo que hoy te lleva millones de años romper con fuerza bruta, con esa lógica podría llevar horas.

Una vez que lo ves así, entendés por qué los criptógrafos se ponen nerviosos.

El quantum computing timeline para desarrolladores web: el estado real en 2025

Primer aclaramiento importante: no estoy hablando de algo que pasa mañana. El quantum computing que existe hoy es ruidoso, inestable, y no escala bien. Las máquinas de IBM o Google tienen decenas o cientos de qubits "reales" pero con tasas de error que hacen que la mayoría de los algoritmos criptográficamente relevantes sean imposibles de correr.

Para romper RSA-2048 — el estándar que protege buena parte de HTTPS hoy — necesitarías aproximadamente 4000 qubits lógicos estables. Los qubits lógicos son distintos de los físicos; necesitás muchos físicos para hacer uno lógico confiable por culpa del error de corrección.

Hoy estamos, dependiendo de a quién le preguntés, entre 10 y 20 años lejos de tener máquinas con esa capacidad. Algunos dicen 15 años. Otros dicen que nunca llegamos. Otros dicen que ya hay actores estado-nación haciendo cosas que no vemos.

Ese rango de incertidumbre es exactamente el problema.

Lo que el post de HN me hizo entender

El hilo que mencioné giraba alrededor de algo que se llama "harvest now, decrypt later" (HNDL). La idea es: aunque hoy no podés romper el cifrado, podés interceptar tráfico cifrado ahora y guardarlo para cuando tengas la capacidad cuántica de descifrarlo en el futuro.

Eso cambia la ecuación dramáticamente. Si alguien está capturando tu tráfico HTTPS de 2025 para descifrarlo en 2035, el timeline "10 a 20 años" se convierte en ahora mismo.

¿Quiénes hacen eso? Principalmente actores estado-nación. ¿Le importa eso a mi API de Next.js que muestra recetas de cocina? Probablemente no. ¿Le importa a un sistema de salud, a comunicaciones de defensa, a transacciones financieras de largo plazo? Absolutamente sí.

Así que la primera respuesta práctica es: depende de qué estás construyendo.

Lo que como developer full-stack debería saber sobre post-quantum cryptography

Aquí está lo que aprendí intentando entender el hilo sin tener un PhD en física:

NIST ya tomó decisiones

En 2024, el NIST (National Institute of Standards and Technology) finalizó los primeros estándares de criptografía post-cuántica. Los algoritmos que pasaron son:

ML-KEM (antes CRYSTALS-Kyber): para intercambio de claves
ML-DSA (antes CRYSTALS-Dilithium): para firmas digitales
SLH-DSA (antes SPHINCS+): para firmas digitales

Esto es importante porque significa que el trabajo de estandarización ya pasó. No estamos esperando que los matemáticos se pongan de acuerdo — ya lo hicieron.

TLS 1.3 ya está preparándose

Chrome, Firefox y algunos servidores ya están experimentando con hybrid key exchange — combinan el algoritmo clásico (X25519) con uno post-cuántico (ML-KEM) en el mismo handshake. Si uno falla, el otro sigue funcionando. Si el cuántico resulta tener vulnerabilidades no descubiertas todavía, el clásico te cubre.

Como dev web, probablemente esto te llegue transparentemente vía updates de OpenSSL, nginx, o Node.js. No tenés que hacer nada... todavía.

Lo que SÍ tenés que pensar activamente

// Esto es lo que MUCHOS proyectos hacen hoy
// y que puede ser problemático en un horizonte post-cuántico

// ❌ Algoritmos que eventualmente van a ser vulnerables
const jwt = sign(payload, secret, { algorithm: 'RS256' }) // RSA
const encrypted = crypto.publicEncrypt(rsaPublicKey, data) // RSA

// ✅ Algoritmos simétricos — estos están relativamente bien
// AES-256 sigue siendo seguro en un mundo cuántico
// (Grover's algorithm lo debilita pero no lo rompe — 256 bits -> 128 bits efectivos)
const hash = createHash('sha256').update(data).digest('hex') // OK por ahora
const cipher = createCipheriv('aes-256-gcm', key, iv) // Más seguro

// 🤔 La pregunta real: ¿tus secrets/tokens tienen que durar décadas?
// Si un JWT expira en 1 hora, el riesgo post-cuántico es casi nulo
// Si estás firmando contratos que tienen que ser válidos en 2040...
// ahí sí hay que pensar distinto

La clave práctica que saqué: el riesgo escala con el tiempo de vida de lo que firmás o cifrás. Un access token de 15 minutos y un certificado de firma de documentos legales tienen riesgos completamente distintos.

Los errores de framing más comunes cuando leés sobre quantum computing

Acá está lo que me parece que la mayoría de los posts de divulgación hacen mal — incluyendo probablemente este:

Error 1: Confundir "quantum advantage" con "quantum supremacy" con "cryptographically relevant"

Cuando Google o IBM anuncian un hito cuántico, los medios lo presentan como "ya pueden romper el cifrado". Casi nunca es eso. Quantum advantage significa que resolvieron algún problema específico más rápido que una computadora clásica. Ese problema específico suele ser artificioso y diseñado para que la computadora cuántica brille.

Cryptographically relevant quantum computing — el que realmente importa — es una barra mucho más alta.

Error 2: Pensar que bcrypt o Argon2 están muertos

El hashing de passwords como bcrypt, scrypt o Argon2 usa funciones hash simétricas. El algoritmo de Grover (el que aplica computación cuántica a búsqueda) efectivamente reduce su seguridad a la mitad — pero Argon2 con parámetros modernos tiene margen de sobra. No necesitás cambiar tu sistema de autenticación ahora mismo.

Error 3: Ignorarlo completamente porque "falta mucho"

Este es el error que me parece más peligroso para devs que construyen infraestructura de largo plazo. Si estás construyendo algo que va a manejar datos sensibles por décadas, el timeline importa.

Pensá en todo lo que construí durante el pivote a software development en 2020 — la infraestructura que elegís hoy puede seguir corriendo en producción en 2035. Cuando elegís un stack de autenticación o cifrado hoy, estás eligiendo para ese horizonte de tiempo también.

Error 4: Pensar que esto es solo un problema del devops o del sysadmin

En el ecosistema de 2025 que describí cuando armé mi stack para juanchi.dev, los developers full-stack tomamos decisiones de arquitectura que antes eran de ops. Eso incluye qué librería de crypto usás, cómo firmás tokens, qué tipo de certificados pedís.

No podés delegarlo completamente.

Código: qué revisar en tu proyecto hoy

// Auditoría rápida de superficie de ataque post-cuántica
// Revisá estos patrones en tu codebase

// 1. ALGORITMOS ASIMÉTRICOS — los más vulnerables
// Buscá: RSA, ECDH, ECDSA, DH
// ¿Dónde aparecen?
import { generateKeyPairSync, createSign } from 'crypto'

// ❓ RSA — vulnerable a Shor's algorithm
// Si estos datos tienen que ser válidos en 2035+, pensalo
const { privateKey, publicKey } = generateKeyPairSync('rsa', {
  modulusLength: 2048, // Esto eventualmente no va a ser suficiente
})

// ❓ ECDSA — también vulnerable, aunque más eficiente hoy
const ecKey = generateKeyPairSync('ec', {
  namedCurve: 'prime256v1',
})

// 2. ALGORITMOS SIMÉTRICOS — relativamente OK
// AES-256, ChaCha20-Poly1305, SHA-256/384/512
// Estos necesitan el doble de bits para ser vulnerables (Grover)
// pero con 256 bits tenés colchón de sobra

import { randomBytes, createCipheriv, createDecipheriv } from 'crypto'

const cifrarDatosLocales = (datos: Buffer, clave: Buffer): Buffer => {
  // AES-256-GCM — esto sigue siendo seguro post-quantum
  const iv = randomBytes(16)
  const cipher = createCipheriv('aes-256-gcm', clave, iv)

  const cifrado = Buffer.concat([
    iv,
    cipher.update(datos),
    cipher.final(),
    cipher.getAuthTag() // El tag de autenticación es importante
  ])

  return cifrado
}

// 3. JWT — el caso práctico más común
// La respuesta corta: si expira en horas, no te preocupés
// Si firmás algo permanente con JWT... cuestioná el diseño

const evaluarRiesgoJWT = (expiresInSeconds: number): string => {
  const años = expiresInSeconds / (365 * 24 * 3600)

  if (años < 1) return 'Riesgo post-cuántico prácticamente nulo'
  if (años < 5) return 'Riesgo bajo, monitoreá el timeline'
  if (años < 15) return 'Riesgo moderado, considerá migración'
  return 'Riesgo alto — rediseñá este componente'
}

console.log(evaluarRiesgoJWT(3600)) // "Riesgo post-cuántico prácticamente nulo"
console.log(evaluarRiesgoJWT(10 * 365 * 24 * 3600)) // "Riesgo moderado..."

La función evaluarRiesgoJWT es una simplificación obvia, pero captura el punto central: el tiempo de vida de lo que firmás es la variable más importante.

Cuando definís los patrones de TypeScript que usás en producción, incluir tipos explícitos para el contexto de seguridad — cuánto tiempo vive un token, qué nivel de sensibilidad tienen los datos — es el tipo de diseño que ayuda cuando tenés que hacer una auditoría de esto en el futuro.

Qué hacer concretamente hoy (sin entrar en pánico)

Esta es mi lista personal, honesta, sin exagerar el riesgo:

Ahora mismo (sin importar el tipo de proyecto):

Usá TLS 1.3 — ya implementa algunas mejoras de seguridad y va a recibir actualizaciones post-cuánticas
Preferí AES-256 sobre AES-128 para cifrado simétrico
Mantenés las dependencias actualizadas — la migración post-cuántica va a llegar vía updates de librerías
No implementés crypto propio — en serio, nunca, quantum o no quantum

En los próximos 1-2 años (si manejás datos sensibles de largo plazo):

Inventariá qué en tu sistema usa criptografía asimétrica y cuánto tiempo tienen que vivir esos datos
Empezá a leer sobre las librerías que van a adoptar los algoritmos NIST — Open Quantum Safe ya tiene implementaciones
Considerá diseñar para "cripto-agilidad": que tu sistema pueda cambiar de algoritmo sin reescribir todo

Para el stack que elegiría en 2025:
Hoy elegiría librerías activamente mantenidas por organizaciones que ya tienen planes de migración post-cuántica documentados. Node.js y OpenSSL están en ese camino. Es un criterio más para sumar a la evaluación.

FAQ: quantum computing y desarrollo web

¿HTTPS va a dejar de ser seguro por el quantum computing?

No en el corto plazo, y probablemente no de golpe. TLS ya está siendo actualizado con algoritmos post-cuánticos (hybrid key exchange en TLS 1.3). El browser que usás hoy ya está recibiendo estas actualizaciones gradualmente. Lo que sí es una amenaza real es el ataque "harvest now, decrypt later" para datos muy sensibles — pero eso aplica a actores estado-nación, no al tráfico web promedio.

¿Tengo que cambiar el sistema de login/passwords de mi app?

No urgentemente. bcrypt, Argon2, y scrypt usan funciones hash simétricas que son mucho más resistentes a quantum computing que los algoritmos asimétricos. Argon2id con parámetros modernos tiene margen de seguridad suficiente. La recomendación es seguir con las mejores prácticas actuales y mantenerte actualizado.

¿Los JWTs quedan obsoletos?

Depende de cómo los usés. Si firmás access tokens que expiran en 15 minutos o 1 hora, el riesgo es prácticamente nulo — para cuando exista quantum computing relevante, esos tokens llevan años vencidos. Si usás JWTs para firmar algo que tiene que ser válido por años (documentos, contratos), ahí sí hay que empezar a pensar en alternativas.

¿Qué es "post-quantum cryptography" y en qué se diferencia de "quantum cryptography"?

Post-quantum cryptography (PQC) son algoritmos clásicos — corren en computadoras normales — diseñados para ser resistentes a ataques de computadoras cuánticas. Quantum cryptography (QKD, quantum key distribution) usa principios cuánticos para la comunicación en sí. Como dev web, lo que te importa es PQC — es lo que vas a implementar en tu stack. QKD requiere hardware especializado y es un campo completamente distinto.

¿Cuándo debería empezar a usar las librerías post-cuánticas en producción?

Para la mayoría de las aplicaciones web: cuando lleguen via updates de tus dependencias actuales, que es probablemente lo que va a pasar. Node.js, OpenSSL y los providers de TLS van a implementar los estándares NIST gradualmente. Si manejás datos críticos de largo plazo, vale la pena explorar Open Quantum Safe hoy y empezar a hacer pruebas. Para el resto, mantenete actualizado y no entres en pánico.

¿El quantum computing afecta a blockchain y crypto también?

Sí, y bastante. Las criptomonedas usan ECDSA para firmar transacciones — vulnerable a Shor's algorithm. Bitcoin y Ethereum tendrían que migrar sus sistemas de firma antes de que quantum computing sea relevante. Es uno de los debates más activos en esas comunidades. Como dato de color: las wallets activas están más expuestas que las inactivas, porque las activas exponen la clave pública en cada transacción.

Conclusión: la ignorancia honesta como posición válida

Cuando empecé a escribir este post no sabía bien qué iba a concluir. Sigo sin saber si en 10 años estamos re-cifrando todo el internet o si el quantum computing sigue siendo una promesa que no termina de llegar.

Lo que sí saqué en limpio:

El timeline importa más que el tema. No es un problema binario de "hay que preocuparse" o "no hay que preocuparse". Es una función del tiempo de vida de tus datos y la sensibilidad de los mismos.
La industria ya se está moviendo. NIST finalizó estándares. TLS ya está experimentando con algoritmos híbridos. No vas a tener que hacer todo a mano — va a llegar via ecosistema.
La cripto-agilidad es la mejor inversión. Diseñar tus sistemas para que puedan cambiar de algoritmo sin reescritura total es buena práctica con o sin quantum computing. La historia de la criptografía es la historia de algoritmos que se rompen y se reemplazan.
Para la mayoría de los proyectos: mantenete actualizado y no entres en pánico. Si tu app maneja credenciales de usuarios que expiran, tokens de sesión normales, y datos que no tienen que ser válidos por décadas — el riesgo hoy es bajo. Aplicá las mejores prácticas actuales.

Lo que me queda pendiente es seguir leyendo. El hilo de HN que disparó esto tenía respuestas de gente con décadas de experiencia en criptografía que no se ponía de acuerdo. Eso me dice que la humildad epistémica es la postura correcta.

Si sos el tipo de developer que, como yo, viene de diagnosticar redes a las 11pm en un cyber o de tirar un servidor de producción con rm -rf en la primera semana de trabajo — sabés que la mejor preparación para los problemas grandes no es entrar en pánico cuando aparecen, sino construir sistemas que puedan adaptarse.

Eso aplica acá también.

Este artículo fue publicado originalmente en juanchi.dev

What Happens If You Build Your Own Trading Bot? I Tried It

AdarshGzz... — Tue, 07 Apr 2026 19:30:27 +0000

I Built a Real-Time Paper Trading Bot (To Understand How Trading Systems Work and can i automate it) and it took me 3 weeks.

so recently i wanted to understand how trading systems actually work behind the scenes

not just charts… but like:
• how data comes in
• how decisions are made
• how trades are executed

so i ended up building a paper trading bot for BTC/USDT

(no real money involved 😅)

what it does

it connects to Binance WebSocket and gets live market data

then on every 5-minute candle, it decides:
• go LONG
• go SHORT
• or do nothing

based on a simple strategy

*the strategy *(kept it simple)

i didn’t want anything too complex

so i used:
• EMA (50) → trend
• RSI (14) → momentum

entry logic:
• LONG → price above EMA + RSI > 50 + green candle
• SHORT → price below EMA + RSI < 50 + red candle

entry happens exactly on candle close

risk management (most important part)

this was actually interesting to implement
• only 1% risk per trade
• stop loss based on structure (swing high/low)
• target = 1.5x risk
• auto stop trading if:
• -3% loss
• +5% profit

also restricted trading hours to avoid random moves

tech i used
• Node.js → backend
• WebSockets → real-time data
• PostgreSQL (Neon) → store trades + candles
• React → dashboard

what i learned

this project was less about trading and more about systems
• handling real-time streams is tricky
• small delays can affect decisions
• syncing backend + frontend in real time is not easy
• logic looks simple but edge cases are everywhere

live project

if you want to see it:

👉 https://paper-trader-drab.vercel.app/
👉 https://github.com/AdarshGzz/Paper-Trader

final thought

it’s still a simple bot and not something for real trading

but building it gave me a better idea of:
• how trading engines work
• how data flows in real-time systems

planning to improve it more (maybe better strategies or analytics)

if you’ve built something similar or have ideas, would love to hear 👍

Hello Noir! [Part 2]

0xluk3 — Tue, 07 Apr 2026 19:29:00 +0000

In Part 1 we wrote a circuit, compiled it with nargo, and got two artifacts: a circuit definition and a witness. Now we will use them to actually perform the cryptographic proof check.

1. Where we left off

At the end of Part 1, we had two files in target/:

hello_world.json - the compiled circuit (ACIR bytecode)
hello_world.gz - the witness (our specific input values that satisfy the constraints)

All nargo told us was "yes, these inputs work." That's not a proof anyone else can verify - it's just a local check. To produce an actual cryptographic proof, we need Barretenberg (bb).

2. Generating a proof with Barretenberg

With our Prover.toml set to x = "2" and y = "1" (recall: x is private, y is public), we run:

bb prove -b ./target/hello_world.json -w ./target/hello_world.gz \
  --write_vk --verifier_target evm -o ./target

Scheme is: ultra_honk, num threads: 8 (mem: 8.10 MiB)
CircuitProve: Proving key computed in 29 ms (mem: 24.21 MiB)
Public inputs saved to "./target/public_inputs" (mem: 28.56 MiB)
Proof saved to "./target/proof" (mem: 28.56 MiB)
VK saved to "./target/vk" (mem: 28.56 MiB)
VK Hash saved to "./target/vk_hash" (mem: 28.56 MiB)

Let's break down the flags:

-b - path to the compiled circuit (ACIR bytecode)
-w - path to the witness
--write_vk - also generate the verification key alongside the proof
--verifier_target evm - target the EVM. This does two things: uses Keccak256 (the EVM has a dedicated opcode for it, making verification gas-efficient) and enables the zero-knowledge property (the proof reveals nothing about private inputs)
-o - output directory

This produced four files in target/:

File	Size	What it is
`proof`	7,488 bytes	The cryptographic proof
`vk`	1,888 bytes	Verification key
`vk_hash`	32 bytes	Hash of the vk
`public_inputs`	32 bytes	The public inputs (y = 1)

What is the verification key? It's derived from the circuit structure alone - not from your inputs. It encodes the circuit's "shape": how many gates, what type, how they're wired. Anyone can use it to verify proofs for this circuit. Think of it as the circuit's public fingerprint. The same vk works for any valid proof of this circuit, regardless of what specific values of x and y were used.

One detail worth noting: bb prepends the public inputs to the proof blob. The verifier contract knows to extract them from there.

3. Verifying the proof

bb verify -p ./target/proof -k ./target/vk --verifier_target evm

Scheme is: ultra_honk, num threads: 8 (mem: 8.11 MiB)
Proof verified successfully (mem: 18.36 MiB)

Notice what we did NOT pass: the witness. That would defeat the purpose, wouldn't it? The whole point is that the verifier never sees your private inputs. All it needs is the proof and the verification key.

The proof says: "someone knows a value x such that x != y, where y = 1." It doesn't say what x is.

4. Generating a Solidity verifier

Now we want this verification to happen on-chain. bb can generate a Solidity contract that does exactly the same check:

bb write_solidity_verifier -k ./target/vk --verifier_target evm -o ./target/Verifier.sol

Scheme is: ultra_honk, num threads: 8 (mem: 8.75 MiB)
ZK Honk solidity verifier saved to "./target/Verifier.sol" (mem: 9.87 MiB)

The result is a 2,449-line Solidity file. What's inside:

A HonkVerifier contract that inherits from BaseZKHonkVerifier
The verification key hardcoded as constants (circuit size, elliptic curve points, etc.)
Pairing check logic using EVM precompiles (ecAdd, ecMul, ecPairing, modexp)
A single entry point: function verify(bytes calldata proof, bytes32[] calldata publicInputs) external returns (bool)

This works on any EVM chain that supports the required precompiles - Ethereum mainnet, most L2s, and testnets.

5. Deploying with Foundry

Let's deploy the verifier and verify a proof on-chain. First, set up a Foundry project:

forge init verifier-deploy
cd verifier-deploy

Copy the generated verifier:

cp ../hello_world/target/Verifier.sol src/Verifier.sol

We also need to allow Foundry to read our proof file. Add this to foundry.toml:

fs_permissions = [{ access = "read", path = "../hello_world/target" }]

Deploy script

// script/Deploy.s.sol
// SPDX-License-Identifier: MIT
pragma solidity >=0.8.21;

import "forge-std/Script.sol";
import "../src/Verifier.sol";

contract DeployScript is Script {
    function run() external {
        vm.startBroadcast();
        HonkVerifier verifier = new HonkVerifier();
        console.log("HonkVerifier deployed to:", address(verifier));
        vm.stopBroadcast();
    }
}

Verify script

// script/Verify.s.sol
// SPDX-License-Identifier: MIT
pragma solidity >=0.8.21;

import "forge-std/Script.sol";
import "../src/Verifier.sol";

contract VerifyScript is Script {
    function run() external {
        bytes memory proofBytes = vm.readFileBinary("../hello_world/target/proof");

        bytes32[] memory publicInputs = new bytes32[](1);
        publicInputs[0] = bytes32(uint256(1)); // y = 1

        vm.startBroadcast();
        HonkVerifier verifier = new HonkVerifier();
        console.log("HonkVerifier deployed to:", address(verifier));

        bool result = verifier.verify(proofBytes, publicInputs);
        console.log("Proof verified:", result);
        vm.stopBroadcast();
    }
}

Running it

Start a local testnet and deploy:

anvil --code-size-limit 50000

The --code-size-limit flag is needed because HonkVerifier exceeds the default EIP-170 contract size limit of 24,576 bytes (ours is ~33K). This is fine for local testing. For production, you'd use --optimized when generating the Solidity verifier or split the contract into libraries.

In another terminal:

forge script script/Verify.s.sol \
  --rpc-url http://127.0.0.1:8545 \
  --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 \
  --broadcast --code-size-limit 50000

Script ran successfully.

== Logs ==
  HonkVerifier deployed to: 0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512
  Proof verified: true

ONCHAIN EXECUTION COMPLETE & SUCCESSFUL.

The proof verified on-chain. The same proof that bb verified locally now passes through a Solidity contract running on an EVM.

6. Trust and threat model

Before you ship anything, consider three attack surfaces.

Prover honesty. The circuit enforces constraints, not truth. Nobody can prove that 2 != 2 - the constraint system rejects it. But nothing stops someone from proving 2000 != 18 and claiming that proves their age. The circuit guarantees mathematical correctness of the relationship between inputs, not that the inputs themselves are meaningful. External anchoring (signed attestations, on-chain data, oracles) is required to bind proof inputs to real-world facts.

The bb binary. bb is a local executable. If someone swaps it for a modified version, they could generate proofs that pass a compromised verifier. In any system where the prover and verifier are different entities, the verifier must run its own trusted copy of bb (or verify on-chain where the contract is the trust anchor).

The verifier contract. It's source code - editable before deployment. If the same entity generates the proof and deploys the verifier, there's a circular trust problem. For production, the verifier contract should be deployed by a trusted third party, verified on a block explorer, and ideally immutable (no proxy, no upgradeability). Or at the very least, governed by a multisig with a timelock.

None of these are flaws in the cryptography. These are system design questions that any production deployment needs to answer.

We went from compiled artifacts to a verified on-chain proof. The circuit is trivial, but the pipeline is the same one you'd use for anything more complex - age verification, credential checks, private voting. The hard part isn't the tooling. It's designing the system around it.

Was Web-Entwickler von Game-Engine-Architektur lernen können

Ziva — Tue, 07 Apr 2026 19:28:24 +0000

Wenn du mit React, Vue oder Angular arbeitest, nutzt du Patterns, die aus der Spieleentwicklung stammen. Nicht inspiriert davon. Direkt übernommen. Der Component Tree, den du jeden Tag baust, wurde in den 1980ern als Scene Graph erfunden, lange bevor JavaScript überhaupt existierte.

Hier sind vier Architektur-Patterns aus Game Engines, die dein Web-Development besser machen.

1. Der Scene Graph: Reacts Urgroßvater

Der Scene Graph ist eine hierarchische Baumstruktur, in der jeder Knoten Transformationen und Eigenschaften an seine Kinder vererbt. PHIGS (Programmer's Hierarchical Interactive Graphics System) wurde 1984 entwickelt und 1988 als ANSI-Standard verabschiedet. Es war die erste kommerzielle Scene-Graph-Spezifikation.

Das Prinzip: Du baust eine Szene nicht als flache Liste, sondern als Baum. Ein Raumschiff-Node enthält einen Triebwerk-Node, der enthält einen Partikel-Node. Wenn sich das Raumschiff bewegt, bewegen sich Triebwerk und Partikel automatisch mit. Kaskadierung von Eigenschaften durch die Hierarchie.

Kommt dir das bekannt vor? Reacts Component Tree funktioniert identisch. Context propagiert durch den Baum nach unten. CSS-Variablen kaskadieren. State fließt von Eltern zu Kindern. Das ist kein Zufall. Jordan Walke, der Erfinder von React, hat sich explizit von Szenegraphen und funktionaler Programmierung inspirieren lassen.

Godot macht das noch konsequenter als React. In Godots Scene Tree ist alles ein Node: UI-Elemente, Spiellogik, Physik, Audio. Kein useEffect, kein Lifecycle-Hook. Du hast _ready() (Mount), _process() (Render-Loop) und _exit_tree() (Unmount). Drei Funktionen statt 15 Hooks.

class_name Raumschiff extends CharacterBody2D

func _ready():
    # Wie componentDidMount / useEffect([], ...)
    $Triebwerk.starten()

func _process(delta):
    # Wie requestAnimationFrame, 60x pro Sekunde
    position += geschwindigkeit * delta

2. Composition over Inheritance: Die Spielebranche wusste es zuerst

Das Entity Component System (ECS) hat Composition over Inheritance nicht erfunden, aber es hat bewiesen, dass es skaliert. Thief: The Dark Project nutzte 1998 ein ECS, und der gleiche Ansatz lief später in System Shock 2.

Die Idee: Eine Spielfigur ist keine Klasse in einer Vererbungshierarchie. Sie ist eine leere Entity mit angehängten Components. Braucht sie Physik? PhysicsComponent anhängen. Braucht sie Gesundheit? HealthComponent anhängen. Braucht sie beides nicht mehr? Components entfernen.

React hat dieses Pattern 2018 mit Hooks übernommen. Statt Klassen-Vererbung (class MyComponent extends React.Component) nutzt du Composition mit useState, useEffect und Custom Hooks. Die Game-Engine-Welt hatte das gleiche Problem 20 Jahre früher gelöst.

Unity hat die Performance-Vorteile gemessen: Ihr Data-Oriented Technology Stack (DOTS) mit ECS erreicht 5x bis 50x bessere CPU-Performance als die klassische OOP-Architektur, je nach Parallelisierungsgrad. In der Megacity-Demo von 2018 renderte Unity damit eine Stadt mit 4,5 Millionen Mesh-Renderern.

Für Web-Entwickler heißt das: Wenn du merkst, dass deine Klassen-Hierarchie zu tief wird, denk wie ein Game-Engine-Architekt. Zerlege Verhalten in kleine, kombinierbare Einheiten. In React sind das Hooks. In Godot sind das Nodes. Das Prinzip ist dasselbe.

3. Signals: Observer Pattern ohne den Boilerplate

Godot hat Signals als erstklassiges Sprachfeature. Du deklarierst ein Signal, und andere Nodes verbinden sich damit. Keine Event-Bus-Bibliothek, kein Redux, kein Pub/Sub-Framework.

signal leben_verloren(neues_leben: int)

func schaden_nehmen(menge: int):
    leben -= menge
    leben_verloren.emit(leben)

func _ready():
    spieler.leben_verloren.connect(_bei_leben_verloren)

func _bei_leben_verloren(neues_leben: int):
    label.text = str(neues_leben)

Das ist das Observer Pattern in seiner reinsten Form, ohne Middleware-Layer. Die Web-Welt hat Jahre gebraucht, um an einen ähnlichen Punkt zu kommen. Solid.js Signals, Angular Signals (seit v16), Vue 3 Reactivity: Alle lösen das gleiche Problem, das Game Engines seit den 2000ern gelöst haben.

Der entscheidende Unterschied: In Game Engines sind Signals architektonisch. Sie definieren, wie Systeme kommunizieren. Im Web werden sie oft nur als State-Management-Optimierung behandelt. Game-Engine-Entwickler denken von Anfang an in entkoppelten Systemen, die über Signals kommunizieren. Web-Entwickler sollten das auch tun.

4. Object Pooling: Warum Game Engines Garbage Collection hassen

In einem Shooter entstehen pro Sekunde Dutzende Projektile. Jedes Mal new Bullet() und dann den Garbage Collector aufräumen lassen? Unspielbar. Stattdessen nutzen Game Engines Object Pools: Eine fixe Menge an Objekten wird beim Start erstellt. "Verbrauchte" Objekte werden nicht zerstört, sondern zurückgesetzt und wiederverwendet.

Web-Entwickler kennen das Prinzip als Connection Pooling bei Datenbanken. Aber es geht weiter: React 18s Concurrent Rendering recycelt Fiber-Nodes intern. Workers in Node.js Thread-Pools werden wiederverwendet. Das Pattern ist überall, nur redet im Web kaum jemand darüber.

Wenn du eine Anwendung baust, die viele kurzlebige Objekte erzeugt (Chat-Nachrichten, Tabellen-Zeilen, Animationen), frag dich: Könnte ich die recyceln statt neu zu erstellen? Die Spielebranche beantwortet diese Frage seit 30 Jahren mit Ja.

Die Zahlen hinter Game-Engine-Architektur

Die deutsche Spielebranche hat 2023 mit knapp 1.200 Unternehmen und fast 13.000 Beschäftigten über 3,9 Milliarden Euro Umsatz erwirtschaftet (Quelle: game.de Jahresreport 2025). Das sind keine Hobby-Projekte. Das sind Produktionssysteme, die unter extremen Performance-Anforderungen laufen.

Godot, die Open-Source-Engine mit über 108.000 GitHub Stars, hat beim GMTK Game Jam 2025 einen Marktanteil von 39% erreicht, mehr als dreimal so viel wie noch 2021 (13%). Tools wie Ziva helfen Godot-Entwicklern dabei, effizienter zu arbeiten, aber die Architektur der Engine selbst ist der eigentliche Lernstoff.

Fazit: Lerne von den Leuten, die 60 FPS halten müssen

Web-Entwickler optimieren für Time-to-Interactive. Game-Engine-Entwickler optimieren für 16,67 Millisekunden pro Frame, bei 60 FPS. Diese Einschränkung hat Architektur-Patterns hervorgebracht, die robuster und performanter sind als das, was die meiste Web-Architektur bietet.

Das heißt nicht, dass du deine Next.js-App wie eine Game Engine bauen sollst. Es heißt: Wenn du vor einem Architektur-Problem stehst, schau dir an, wie Godot, Unity oder Unreal es lösen. Die Chancen stehen gut, dass sie das Problem vor 10 oder 20 Jahren schon gelöst haben.

Drei konkrete Schritte:

Lies Game Programming Patterns von Robert Nystrom. Es ist kostenlos online und erklärt jedes Pattern mit konkretem Code.
Bau ein kleines Godot-Projekt. Nicht um Spiele zu entwickeln, sondern um die Architektur zu erleben. Der Scene Tree verändert, wie du über Component-Hierarchien denkst.
Hinterfrage deine Abstraktionen. Wenn du drei NPM-Pakete brauchst, um ein Problem zu lösen, das eine Game Engine in 10 Zeilen löst, stimmt etwas mit der Abstraktion nicht.

Die beste Architektur entsteht nicht in Frameworks. Sie entsteht dort, wo Performance keine Option, sondern eine harte Grenze ist.

StudioMeyer CRM: AI-Native Contact Management with 33 MCP Tools

Matthias Meyer — Tue, 07 Apr 2026 19:27:34 +0000

Most CRM systems are built for enterprises. Dozens of menus, mandatory fields for things you don't need, and per-seat pricing. For freelancers, small agencies, and solo entrepreneurs, that's overkill.

StudioMeyer CRM is an MCP server. No dashboard, no app, no interface -- you talk directly to Claude, and Claude manages your contacts, deals, and pipeline. Everything through natural language.

How does a CRM without an interface work?

Instead of filling out forms, you simply tell Claude what you need:

"Create company Mueller GmbH, industry IT, website mueller-gmbh.de"
"New deal: Website Redesign for Mueller, 5,000 EUR, stage proposal"
"Show me the pipeline"
"Which follow-ups are overdue?"

Claude runs the CRM tools in the background. You see the results directly in the chat -- formatted, sorted, with all relevant details.

30 Tools for the complete CRM workflow

Area	Tools	What you do with it
Companies	3	Create, update, delete (cascading)
Contacts	3	Manage contact persons, mark decision makers
Pipeline	4	Create deals, pipeline overview, forecast
Communication	2	Log interactions (email, call, meeting), timeline
Notes	3	Add notes to companies or deals
Analytics	5	Dashboard, health scores, revenue report, Stripe sync
Search	1	Full-text search across all 7 entity types
Leads	2	Capture, qualify, convert leads
Follow-ups	2	Tasks and reminders with priorities
Extras	5	Import/export, audit log, handoff, guide

Installation

Option 1: Hosted (get started immediately)

https://crm.studiomeyer.io/mcp

Paste the URL into Claude Desktop, OAuth login, done. We handle the database and hosting.

Option 2: Self-hosted

git clone https://github.com/studiomeyer-io/mcp-crm
cd mcp-crm && npm install
cp .env.example .env  # Add DATABASE_URL
npm run db:push && npm start

Claude Desktop configuration:

{
  "mcpServers": {
    "crm": {
      "command": "node",
      "args": ["/path/to/mcp-crm/dist/server.js"],
      "env": {
        "DATABASE_URL": "postgresql://...",
        "CRM_TENANT": "my-company"
      }
    }
  }
}

What you can actually do with it

Morning routine (2 minutes)

"Give me the daily briefing."

Claude shows you: new leads since yesterday, overdue follow-ups (sorted by priority), pipeline overview, and alerts (inactive companies, at-risk health scores). One command instead of ten clicks.

Client management

"Log a call with Mueller GmbH -- discussed timeline, next step is proposal by Friday."

Claude creates the interaction, automatically sets a follow-up, and updates the last contact timestamp. The timeline later shows all interactions and notes chronologically.

Pipeline at a glance

"How's the pipeline looking?"

Claude delivers an overview of all deals, grouped by stage (Lead, Qualified, Proposal, Negotiation, Won, Lost). With weighted probability per stage and MRR/ARR calculation from your deal values.

Stripe integration

If you use Stripe: One command syncs your active subscriptions. For new Stripe customers, a company, contact, and deal are automatically created.

"Sync Stripe."

After that, the revenue report shows: MRR, ARR, growth, and breakdown by customer.

The intelligent search

Search works in three phases:

German full-text search -- Finds "consulting" even when "consult" is stored (stemming)
Fuzzy matching -- Handles typos: "Meuller" finds "Mueller". Umlauts are automatically resolved
Prefix search -- Finds partial terms as a final fallback

The search covers all seven entity types simultaneously: companies, contacts, deals, interactions, notes, leads, and tags.

Health Scores: Which clients need attention?

Every company automatically gets a health score from 0 to 100. The score is based on:

Last interaction (when was the last contact?)
Active deals (are there ongoing business relationships?)
Follow-up discipline (are tasks being completed?)
Communication frequency (how regular is the contact?)

Companies below 40 points get a warning in the dashboard. So you never forget a client.

Import and export

Import

CSV or JSON -- Automatic column recognition for German and English headers
HubSpot import -- 15 column mappings (First+Last Name, Job Title, Company Domain, etc.)
Pipedrive import -- 7 column mappings
Dry-run mode -- Preview without actually importing
Duplicate detection -- Prevents double entries

Export

Export contacts, companies, deals, or leads as CSV or JSON. Maximum 10,000 rows per export.

The built-in guide

On first start, simply type: "Show me the CRM guide."

Claude explains 12 topics interactively: from the first five minutes (create company, contact, deal, dashboard, follow-up) to advanced features like Stripe sync, health scores, and pipeline forecast.

Tips for productive use

Start with five companies. Add your most important clients, each with a contact person and an active deal. Takes five minutes and you have a working pipeline immediately.
Log every interaction. A brief sentence is enough: "Call with Mueller, feedback on design was positive." Over time, a complete timeline emerges.
Use follow-ups as your task list. Instead of a separate to-do app: "Create follow-up: call Mueller, priority high, by Friday."
Automate leads. Through the webhook endpoint, leads can flow automatically from your website form or newsletter into the CRM.
Export monthly. A CSV export of your contacts as a backup and for analysis in Excel or Google Sheets.

Pricing

Tier	Price	Companies	Contacts	Deals
Free	$0	50	200	100
Pro	$29/mo	500	5,000	1,000
Team	$49/mo	Unlimited	Unlimited	Unlimited

All 30 tools are available in every tier. The differences are in data volume and API rate.

Privacy

EU hosting: Supabase, Frankfurt (Germany)
Tenant isolation: Each user has separate, isolated data (Row Level Security)
Self-hosting possible: Docker + your own PostgreSQL database
Audit log: Complete tracking of who changed what and when

StudioMeyer CRM is built for business owners who don't need a complex CRM system -- but a fast one. No onboarding, no training, no interface to learn. You talk to Claude, Claude manages your clients. If you'd like to try it: The free version is enough to get started, and the built-in guide explains everything step by step.

crm.studiomeyer.io

HTCPCP IYKYK: I Built a Browser Extension That Lets Dinosaurs Eat the Internet

John Munn — Tue, 07 Apr 2026 19:26:34 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I built Dinosaur Eats, a Chrome extension that sends a tiny pixel dinosaur onto any webpage and lets it eat the visible text line by line.

Not paragraphs.

Not sections.

Rendered lines.

It solves nothing. If anything, it introduces a new class of browser instability: active prehistoric content loss.

Click the toolbar icon and the extension scans the page for readable text. A dinosaur walks in, lines up the shot, and starts chewing through the page one visible line at a time until the whole thing looks like it got caught in a small but highly motivated extinction event.

Sometimes it’s one dinosaur.

Sometimes it escalates into a full stampede.

And because the challenge is HTCPCP IYKYK, I added a hidden protocol joke.

If the extension is active and you type 418, the dinosaurs mutate into teapotsaurs.

Type 814 and they switch back.

That was the moment I knew the project had crossed from “browser prank” into “deeply respectful nonsense.”

One-line pitch

A tiny dinosaur enters your browser and eats the visible text, but typing 418 mutates it into a teapotsaur because RFCs deserve whimsy too.

Demo

Demo video: https://youtu.be/mSmW5a-bhgo

Code

Source code: https://github.com/Tawe/dinosaur-eats

Built as a Manifest V3 Chrome extension with:

JavaScript
background service worker
content scripts
Chrome activeTab, storage, and scripting
CSS sprite animation
custom dinosaur + teapotsaur sprite sheets
looping chomp audio
optional herd behavior
hidden 418 / 814 mutation triggers
Gemini for iteration during development

The part I got most carried away with was making the dinosaur eat rendered lines instead of DOM blocks.

Deleting paragraphs would have been easy.

Instead I wanted the page to disappear in the exact shape the user sees it, which meant wrapping text, measuring where the browser actually breaks lines, grouping spans into visible rows, randomizing destruction order, and syncing the bite animation so the line disappears on the exact chomp frame.

A completely unreasonable amount of engineering for a joke.

Which is probably why it worked.

How I Built It

At a high level, the extension:

waits for toolbar activation
scans the current page for visible readable text
wraps characters to detect true rendered line breaks
groups them into visible lines
randomizes the destruction order
sends in the dinosaur
removes the line on the bite frame
mutates into teapotsaur mode on 418
reverts back on 814

The strangest technical problem was that browsers don’t really expose “visible lines of text” as a concept.

That layer had to be invented.

So the joke ended up requiring a lot of layout measurement, span grouping, sprite timing, and DOM mutation choreography just to make the page feel like it was literally being eaten.

The premise is silly.

The implementation got weirdly serious.

Best Google AI Usage

I used Gemini throughout development as a fast implementation partner.

It was especially useful for:

working through Manifest V3 structure
refining content-script injection flow
thinking through line grouping logic
improving sprite timing
helping shape the 418 teapotsaur mutation idea into something that actually reads on screen

The final result is proudly useless.

Gemini helped me make it more useless, faster.

Ode to Larry Masinter

The hidden 418 mode is my favorite part.

Typing 418 while the extension is active mutates every dinosaur into a tiny walking teapotsaur.

They still eat the page.

They just do it with much stronger protocol energy.

Typing 814 reverses the mutation, which is objectively not how protocols work, but it felt spiritually correct.

My Journey Contributing to Django Simple Deploy: Improving the PythonAnywhere Plugin for Beginners

victoria nyamai — Tue, 07 Apr 2026 19:26:22 +0000

I’ve recently started contributing to django-simple-deploy, a tool that makes it easier to deploy Django projects with a single command. After watching Eric’s DjangoCon talk and hearing how many beginners struggle with deployment, I decided to focus on improving the PythonAnywhere plugin, especially for people on the free tier. Since PythonAnywhere is where many first-time Django developers go, I want to help make that experience smoother and less confusing. I also want this work to reach Django Girls, because helping more women get into tech is something I really care about.

So what is django-simple-deploy?

Django-simple-deploy is a tool that automates the steps needed to deploy a Django app. Instead of manually setting environment variables, configuring WSGI, or running multiple commands, the tool handles these tasks using platform-specific plugins. You run one command, and it prepares your project for platforms like PythonAnywhere, Fly.io, or Scalingo.

There are also community-built plugins, like one that lets you deploy to any VPS with Kamal, showing that the tool is open for anyone to extend.

My very simple todo list

Some of the tasks I’ll be tackling include testing deployments on different project types, checking how the WSGI file is handled, documenting free-tier restrictions, and exploring how an “update” command could work. I’ll also work on smaller fixes, like improving error messages and clarifying instructions, to make the plugin more beginner-friendly.

Wanna get involved?

If you’re interested in trying django-simple-deploy or want to help improve the PythonAnywhere plugin, you’re welcome to join in. Testing deployments, giving feedback, or picking up small issues in the repo are great ways to get started. Even just sharing your experience helps us understand where beginners struggle.

Ionify vs Vite: What Actually Happens Inside Your Build Tool

KhaledSalem — Tue, 07 Apr 2026 19:24:35 +0000

Most developers use Vite and trust it. It's fast, well-designed, and gets out of the way.

But there's a fundamental assumption baked into Vite's architecture — and every other major build tool — that we decided to challenge when building Ionify.

The assumption: every build starts from zero.

This post is a deep look at what that means in practice, what we built instead, and the architectural tradeoffs we made along the way.

The Stateless Build Problem

When you run vite build, here's roughly what happens:

Vite spins up esbuild/Rollup (now powered by Rolldown + Oxc instead of pure Rollup/Babel in many cases)
Each file goes through its plugin chain independently
main.tsx → TS plugin → JSX plugin → output
utils.ts → TS plugin → output
index.css → CSS plugin → output
Everything gets bundled

The next time you run it? Same thing. All of it.

There's no memory of what already ran. The TS plugin doesn't know the JSX plugin already processed a file. The bundler doesn't know which files actually changed since last time. The entire pipeline is stateless by design.

This isn't a bug — it's a deliberate architectural choice that keeps the tool simple and predictable. But it has a real cost at scale.

How Ionify Thinks About This Differently

Instead of transforming files, Ionify addresses them.

Every module gets a content hash:

SHA-256(source content + config version) → CAS key

The result lives in a Content-Addressable Store (CAS):

.ionify/
  cas/
    <configHash>/
      <moduleHash>/
        transformed.js
        transformed.js.map

Same content + same config = same hash = skip the transform entirely.

Not faster transforms. No transforms at all — for everything that hasn't changed.

The Persistent Graph

The other half of the equation is the dependency graph.

Vite reconstructs its module graph on every dev server start. Ionify persists it.

.ionify/
  graph.db   ← sled-backed embedded KV store (Rust)

When a file changes, Ionify runs a BFS over the reverse dependency index to find exactly which modules are affected:

This means on a 500-module project, changing one utility file might only invalidate 12 modules — not all 500.

Version Isolation: Config Changes Invalidate Everything

One subtle problem with persistent caches: what if your config changes?

Ionify solves this with a deterministic version hash computed from the config:

The Four-Tier CAS Architecture

As the system evolved, we ended up with four distinct caching layers, each solving a different problem:

Tier 1 — Module Transform Cache

Tier 2 — Deps Artifact Store

Tier 3 — Compression CAS

Pre-compressed build outputs. Brotli-11 + gzip-9 computed once, served forever.

Tier 4 — Chunk-Output CAS

Real Config: Migrating from Vite

Here's an actual ionify.config.ts from a production project that migrated from Vite:

import { defineConfig } from 'ionify'

export default defineConfig({
  entry: '/src/main.tsx',
  server: {
    https: true,
  },
  resolve: {
    // Same aliases as tsconfig — Ionify reads these natively
    // Note: if your tsconfig.json is JSONC (comments/trailing commas),
    // auto-alias parsing currently fails — specify manually here
    alias: {
      '@@': '/',
      '@@/Core': '/Core/src',
      '@': '/src',
    },
    extensions: ['.mjs', '.js', '.mts', '.ts', '.jsx', '.tsx', '.json'],
    conditions: ['import', 'module', 'browser', 'default'],
    mainFields: ['module', 'jsnext:main', 'jsnext', 'main'],
  },
  optimizeDeps: {
    include: ['moment-hijri'],   // pre-warm known-problem deps
    sharedChunks: 'auto',
    packSlimming: 'auto',
    vendorPacks: 'auto',
  },
  build: {
    target: 'esnext',
  },
})

This project has more than +10K module and the results of build time at vite roll-down was 3.7 seconds every time after migrating to Ionify. The time was reduced to 2.2 seconds on warm build, and 3.2 seconds for cold build

The Fundamental Difference

Vite is built around the assumption that each build is independent.

Ionify is built around the assumption that most of the work you did last time is still valid.

Both assumptions are reasonable. Vite's leads to a simpler, more predictable system. Ours leads to a system where the second build, the tenth build, and the CI build all benefit from everything that happened before.

The "With Ionify" side of the transform diagram is mostly empty. Not because we're hiding complexity — but because most of the transforms simply don't run.

Ionify is currently in production use. → ionify.cloud

Build a Searchable Creator Database with PostgreSQL and Node.js

Olamide Olaniyan — Tue, 07 Apr 2026 19:24:00 +0000

Every influencer marketing platform charges $300+/month. The core feature? A searchable database of creators.

But here's their secret: it's just a PostgreSQL table with a good search index. The data comes from public APIs. The "AI-powered discovery" is a WHERE clause with some filters.

Let's build the same thing.

What We're Building

A creator database that:

Ingests creator profiles from Instagram and TikTok
Stores them in PostgreSQL with full-text search
Lets you search by niche, follower range, engagement rate, location, and keywords
Auto-enriches new profiles when they're looked up
Exposes a simple REST API for querying

This is the backend that powers tools like Modash, Heepsy, and Upfluence. You'll have a working version by the end of this article.

The Stack

Node.js + Express – API server
PostgreSQL – storage + full-text search
Prisma – database ORM
SociaVault API – fetch creator profiles and posts
node-cron – background enrichment jobs

Database Schema

// schema.prisma
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model Creator {
  id              String    @id @default(cuid())
  platform        String    // instagram, tiktok
  username        String
  displayName     String?
  bio             String?
  followers       Int       @default(0)
  following       Int       @default(0)
  postsCount      Int       @default(0)
  avgLikes        Int       @default(0)
  avgComments     Int       @default(0)
  engagementRate  Float     @default(0)
  profilePicUrl   String?
  isVerified      Boolean   @default(false)
  category        String?   // detected niche
  country         String?
  language        String?
  lastUpdated     DateTime  @default(now())
  createdAt       DateTime  @default(now())

  @@unique([platform, username])
  @@index([platform, followers])
  @@index([category])
  @@index([engagementRate])
}

Run the migration:

npx prisma migrate dev --name init

The Key Trick: Full-Text Search

PostgreSQL has built-in full-text search. No Elasticsearch needed.

-- Add a generated tsvector column for search
ALTER TABLE "Creator" ADD COLUMN search_vector tsvector
  GENERATED ALWAYS AS (
    setweight(to_tsvector('english', coalesce(username, '')), 'A') ||
    setweight(to_tsvector('english', coalesce("displayName", '')), 'A') ||
    setweight(to_tsvector('english', coalesce(bio, '')), 'B') ||
    setweight(to_tsvector('english', coalesce(category, '')), 'C')
  ) STORED;

-- Index it
CREATE INDEX creator_search_idx ON "Creator" USING GIN (search_vector);

Username and display name get weight A (highest priority). Bio gets B. Category gets C. When you search "fitness coach LA", it'll match creators whose username contains "fitness", bio mentions "coach", and location includes "LA" — ranked by relevance.

Step 1: The Ingestion Pipeline

// ingest.js
const axios = require('axios');
const { PrismaClient } = require('@prisma/client');

const prisma = new PrismaClient();
const api = axios.create({
  baseURL: 'https://api.sociavault.com/v1/scrape',
  headers: { 'x-api-key': process.env.SOCIAVAULT_API_KEY },
});

async function ingestCreator(platform, username) {
  // Check if we already have fresh data (< 7 days old)
  const existing = await prisma.creator.findUnique({
    where: { platform_username: { platform, username } },
  });

  if (existing) {
    const daysSinceUpdate = (Date.now() - existing.lastUpdated.getTime()) / 86400000;
    if (daysSinceUpdate < 7) return existing; // Still fresh
  }

  // Fetch profile
  const profileEndpoint = platform === 'instagram'
    ? `/instagram/profile?username=${username}`
    : `/tiktok/profile?username=${username}`;

  const { data: profileRes } = await api.get(profileEndpoint);
  const profile = profileRes.data || profileRes;

  // Fetch recent posts for engagement calculation
  const postsEndpoint = platform === 'instagram'
    ? `/instagram/posts?username=${username}&limit=12`
    : `/tiktok/profile-videos?username=${username}&limit=12`;

  const { data: postsRes } = await api.get(postsEndpoint);
  const posts = postsRes.data || postsRes.posts || [];

  // Calculate engagement metrics
  const totalLikes = posts.reduce((s, p) => s + (p.likesCount || p.diggCount || 0), 0);
  const totalComments = posts.reduce((s, p) => s + (p.commentsCount || p.commentCount || 0), 0);
  const avgLikes = posts.length > 0 ? Math.round(totalLikes / posts.length) : 0;
  const avgComments = posts.length > 0 ? Math.round(totalComments / posts.length) : 0;

  const followers = profile.followersCount || profile.followerCount || 0;
  const engagementRate = followers > 0
    ? parseFloat((((avgLikes + avgComments) / followers) * 100).toFixed(2))
    : 0;

  // Detect category from bio (simple keyword matching)
  const category = detectCategory(profile.bio || profile.signature || '');

  // Upsert into database
  return prisma.creator.upsert({
    where: { platform_username: { platform, username } },
    create: {
      platform,
      username,
      displayName: profile.fullName || profile.nickname || username,
      bio: profile.bio || profile.signature || '',
      followers,
      following: profile.followingCount || 0,
      postsCount: profile.postsCount || profile.videoCount || 0,
      avgLikes,
      avgComments,
      engagementRate,
      profilePicUrl: profile.profilePicUrl || profile.avatarUrl || null,
      isVerified: profile.isVerified || false,
      category,
    },
    update: {
      displayName: profile.fullName || profile.nickname || username,
      bio: profile.bio || profile.signature || '',
      followers,
      following: profile.followingCount || 0,
      postsCount: profile.postsCount || profile.videoCount || 0,
      avgLikes,
      avgComments,
      engagementRate,
      profilePicUrl: profile.profilePicUrl || profile.avatarUrl || null,
      isVerified: profile.isVerified || false,
      category,
      lastUpdated: new Date(),
    },
  });
}

function detectCategory(bio) {
  const lower = bio.toLowerCase();
  const categories = {
    'fitness': ['fitness', 'gym', 'workout', 'personal trainer', 'health coach'],
    'beauty': ['beauty', 'makeup', 'skincare', 'cosmetics', 'hair'],
    'food': ['food', 'recipe', 'cooking', 'chef', 'restaurant', 'baking'],
    'travel': ['travel', 'wanderlust', 'adventure', 'explore', 'backpack'],
    'tech': ['tech', 'developer', 'coding', 'software', 'startup', 'saas'],
    'fashion': ['fashion', 'style', 'outfit', 'clothing', 'designer'],
    'gaming': ['gaming', 'gamer', 'twitch', 'esports', 'streamer'],
    'music': ['music', 'musician', 'singer', 'producer', 'dj'],
    'education': ['teacher', 'education', 'learn', 'tutor', 'professor'],
    'business': ['entrepreneur', 'ceo', 'founder', 'business', 'marketing'],
  };

  for (const [category, keywords] of Object.entries(categories)) {
    if (keywords.some(kw => lower.includes(kw))) return category;
  }
  return 'other';
}

module.exports = { ingestCreator };

Step 2: The Search API

// server.js
const express = require('express');
const { PrismaClient } = require('@prisma/client');
const { ingestCreator } = require('./ingest');

const app = express();
const prisma = new PrismaClient();

// Search creators
app.get('/api/creators/search', async (req, res) => {
  const {
    q,                // text search query
    platform,         // instagram or tiktok
    category,         // fitness, beauty, tech, etc.
    minFollowers,
    maxFollowers,
    minEngagement,
    sort = 'followers',
    order = 'desc',
    page = 1,
    limit = 20,
  } = req.query;

  const where = {};
  const AND = [];

  if (platform) AND.push({ platform });
  if (category) AND.push({ category });
  if (minFollowers) AND.push({ followers: { gte: parseInt(minFollowers) } });
  if (maxFollowers) AND.push({ followers: { lte: parseInt(maxFollowers) } });
  if (minEngagement) AND.push({ engagementRate: { gte: parseFloat(minEngagement) } });

  if (AND.length > 0) where.AND = AND;

  // Full-text search using raw SQL for the tsvector
  let creators;
  const offset = (parseInt(page) - 1) * parseInt(limit);

  if (q) {
    // Use PostgreSQL full-text search
    const searchQuery = q.split(' ').join(' & '); // AND between terms
    creators = await prisma.$queryRaw`
      SELECT *, ts_rank(search_vector, to_tsquery('english', ${searchQuery})) as rank
      FROM "Creator"
      WHERE search_vector @@ to_tsquery('english', ${searchQuery})
        ${platform ? prisma.$queryRaw`AND platform = ${platform}` : prisma.$queryRaw``}
        ${category ? prisma.$queryRaw`AND category = ${category}` : prisma.$queryRaw``}
        ${minFollowers ? prisma.$queryRaw`AND followers >= ${parseInt(minFollowers)}` : prisma.$queryRaw``}
        ${maxFollowers ? prisma.$queryRaw`AND followers <= ${parseInt(maxFollowers)}` : prisma.$queryRaw``}
      ORDER BY rank DESC
      LIMIT ${parseInt(limit)} OFFSET ${offset}
    `;
  } else {
    creators = await prisma.creator.findMany({
      where,
      orderBy: { [sort]: order },
      skip: offset,
      take: parseInt(limit),
    });
  }

  const total = await prisma.creator.count({ where: q ? undefined : where });

  res.json({
    creators,
    pagination: {
      page: parseInt(page),
      limit: parseInt(limit),
      total,
      pages: Math.ceil(total / parseInt(limit)),
    },
  });
});

// Lookup + auto-ingest a specific creator
app.get('/api/creators/:platform/:username', async (req, res) => {
  const { platform, username } = req.params;

  try {
    const creator = await ingestCreator(platform, username);
    res.json(creator);
  } catch (err) {
    res.status(500).json({ error: err.message });
  }
});

app.listen(3000, () => console.log('Creator DB API running on :3000'));

Step 3: Seed the Database

You need initial data. Here's a script that ingests a list of known creators:

// seed.js
const { ingestCreator } = require('./ingest');

const SEED_CREATORS = [
  { platform: 'instagram', username: 'therock' },
  { platform: 'instagram', username: 'cristiano' },
  { platform: 'tiktok', username: 'charlidamelio' },
  { platform: 'tiktok', username: 'khaby.lame' },
  // Add more from your niche...
];

async function seed() {
  for (const creator of SEED_CREATORS) {
    try {
      console.log(`Ingesting ${creator.platform}/@${creator.username}...`);
      await ingestCreator(creator.platform, creator.username);
      await new Promise(r => setTimeout(r, 1000)); // Rate limit
    } catch (err) {
      console.error(`Failed: ${creator.username} — ${err.message}`);
    }
  }
  console.log('Seeding complete.');
}

seed();

Usage Examples

# Search for fitness creators on Instagram with 10K-100K followers
curl "localhost:3000/api/creators/search?q=fitness&platform=instagram&minFollowers=10000&maxFollowers=100000"

# Find beauty creators with 3%+ engagement rate
curl "localhost:3000/api/creators/search?category=beauty&minEngagement=3&sort=engagementRate"

# Look up a specific creator (auto-fetches if not in DB)
curl "localhost:3000/api/creators/instagram/some_creator"

Why This Beats Spreadsheets

The moment you have 500+ creators in the database, spreadsheets become useless. You can't full-text search a CSV. You can't filter by engagement rate AND follower count AND niche in Google Sheets without losing your mind.

With this setup, queries like "find me fitness creators on TikTok with 50K-200K followers and 4%+ engagement" take 3 milliseconds.

What I'd Add Next

Background refresh job — cron that re-fetches the oldest profiles daily
Duplicate detection — same creator on Instagram and TikTok, link them
Export to CSV — for people who still need spreadsheets
Simple frontend — a search bar + filter sidebar + results grid

Read the Full Guide

Build a Creator Database → SociaVault Blog

Build influencer databases with SociaVault — one API for profiles, posts, and engagement data across TikTok, Instagram, YouTube, and 10+ platforms.

Discussion

If you've built a creator/influencer database before, what was your biggest pain point? Schema design? Keeping data fresh? Handling duplicates across platforms?

javascript #postgresql #api #webdev #database