Forem: Hugo Campañoli

The Lindy Effect: Why Web Standards Are a Safer Financial Investment Than the Latest JS Framework

Hugo Campañoli — Wed, 29 Apr 2026 14:38:48 +0000

Every dependency you add is a bet that someone else won't abandon their project. If the code you write today relies on an abstraction born yesterday, you are buying technical debt with a short expiration date. Choosing tools based on "hype" isn't a criterion, it's gambling.

Experience looks for probability of survival.

What does the Lindy Effect tell us about technical debt?

In software, time acts as the ultimate quality filter. Unlike living beings, ideas and technologies gain "life expectancy" for every year they survive in production.

The Lindy Effect states that the life expectancy of non-perishable technologies is proportional to their current age.

HTML/CSS: 30+ years old. Highly likely to survive another 30.
JS Frameworks: 2-5 years old. High risk of breaking changes and deprecation.

Writing code coupled to the native browser API means the code from 10 years ago still works today without needing to run npm audit fix or fighting broken dependencies.

💡 Takeaway: Web standards aren't boring: they are infrastructure, not an expense. They don't eliminate maintenance, but they eliminate external volatility.

Why is choosing a framework a financial gamble?

Choosing a framework is not a technical decision. It's signing a future contract that includes three mandatory costs:

Forced migrations
Technological lock-in
Constant team retraining

Frameworks are not the problem; the problem is using them where the standard is already enough.

If you can't justify why that extra layer of abstraction will outlast the product's own lifecycle, you are gambling with your client's money.

Long-term ROI: The 0kb Approach

JS Abstraction	Native Web Standards
Ephemeral	High Stability
Technical Annuity	Compound Interest
Constant `npm update`	Just works

Investing in web standards is buying compound interest. Investing in ephemeral frameworks is paying a technical annuity just to keep the ship afloat.

Conclusion

The best code is the one that keeps working when no one is maintaining it. If you need constant updates just to keep your stack alive, you didn't build an investment: you bought a subscription.

What depends less, lasts longer.

Want to dive deeper into engineering strategies for long-term ROI? Follow me here on Dev.to or visit my digital garden.

This post was originally published on campa.dev.

TypeScript DeepPath: Achieving Indestructible Types in Nested Objects

Hugo Campañoli — Tue, 28 Apr 2026 17:59:45 +0000

If you're writing TypeScript code but still using string to reference keys in nested objects (like translation files or configurations), you're missing out on half of the compiler's power.

Mastering Recursive Template Literal Types allows you to create strict accesses that the IDE understands perfectly, rooting out silent "undefined" errors at runtime. It's not about over-typing; it's about designing a developer experience (DX) where the editor won't let you make mistakes.

Why you need DeepPath

Real Validation: "api.endpionts.users" stops compiling automatically.
Full path autocompletion: The IDE natively suggests all possible combinations.
Maintenance: If you change a key in the config, the compiler breaks wherever it's used.

The silent bug

Before looking at the solution, let's see the problem. Using string to access deep properties hides bugs that TypeScript should easily catch:

// Typical in i18n or configs
function getConfig(path: string) { /* ... */ }

// Compiles perfectly, fails in production
const userUrl = getConfig("api.enpoints.users");
// The error? You wrote "enpoints" instead of "endpoints". 
// TS doesn't warn you, and your app returns undefined at runtime.

The pattern: Recursive DeepPath

The secret lies in combining recursion with Template Literal Types. See how we can extract all possible paths from an object as if they were a dot-joined string:

type DeepPath<T> = T extends object
  ? {
      [K in keyof T & string]: T[K] extends object
        ? `${K}` | `${K}.${DeepPath<T[K]>}`
        : `${K}`;
    }[keyof T & string]
  : never;

// Usage example:
interface AppConfig {
  api: {
    endpoints: {
      users: string;
      posts: string;
    };
    timeout: number;
  };
  theme: "dark" | "light";
}

type ConfigPaths = DeepPath<AppConfig>;
// Result: "api" | "theme" | "api.endpoints" | "api.timeout" | "api.endpoints.users" | "api.endpoints.posts"

Developer Evolution: Using `satisfies`

I often see configurations annotated manually (const config: AppConfig = ...). This "flattens" the type and erases the specific inference of your actual data.

For DeepPath<T> to work perfectly, it needs to know the exact literal structure. That's where the satisfies operator comes in: it validates that you meet the interface but keeps the literals intact.

// The "Wizard" Path
const config = {
  api: {
    endpoints: {
      users: "/users",
      posts: "/posts"
    },
    timeout: 5000
  },
  theme: "dark"
} satisfies AppConfig;

// 'config.theme' remains as the literal "dark"
// and we can navigate any path with full safety:
function getProp(path: DeepPath<AppConfig>) {
  // implementation logic...
}

💥 Bonus Track: Return Type Inference (DeepValue)

Validating the input string is great, but true level 500 is inferring the exact return type based on that string. If I request "api.timeout", TypeScript should know it returns a number.

We combine DeepPath with another recursive type called DeepValue:

type DeepValue<T, P> = P extends `${infer K}.${infer Rest}`
  ? K extends keyof T
    ? DeepValue<T[K], Rest>
    : never
  : P extends keyof T
    ? T[P]
    : never;

// Pure magic:
function getConfig<P extends DeepPath<AppConfig>>(path: P): DeepValue<AppConfig, P> {
  // implementation (e.g., using lodash/get)
  return {} as any; 
}

const url = getConfig("api.endpoints.users"); // inferred as string
const timeout = getConfig("api.timeout"); // inferred as number

The cost of magic (Trade-offs)

No advanced pattern comes for free. In production, abusing this recursion has real technical limits that will hit you if the object grows too large.

Pros	Cons
Zero typo-related runtime errors.	Compiler performance: generates massive unions that can slow down the IDE.
100% safe and traceable refactoring.	Recursion limits: TS might halt if the object is excessively deep.
Native autocompletion without extra plugins.	Complexity: Dynamic arrays make inference much harder.

Conclusion

This technique drastically reduces headaches. By implementing these types, you force the compiler to validate the actual structure of your data before the build. If you work on mid-sized projects with predictable configurations or i18n systems, this pattern saves you hours of debugging.

If you're interested in taking type safety to the next level, check out my other posts on campa.dev.

Your Slow Website is a Legal Risk: Why Technical Debt is Now a Liability

Hugo Campañoli — Thu, 23 Apr 2026 12:08:31 +0000

Hey DEV community! 👋 After auditing dozens of enterprise platforms, I’ve noticed a dangerous trend. We talk a lot about JS bloat ruining Core Web Vitals, but there's a much darker side to heavy payloads in 2026.

Web performance is no longer a vanity metric. As we prepare for the full enforcement of strict data protection frameworks—like Europe's GDPR and Paraguay's upcoming Law 7593/2025—the efficiency of your software is a matter of operational sovereignty and legal compliance.

If your platform dispatches megabytes of useless JavaScript, you aren't just frustrating users on 4G networks; you are hiding attack surfaces and monitoring risks that expose your company to massive fines.

The TL;DR

Excessive JS increases the surface area where unaudited third-party integrations can hide.
Latency in rural areas halts B2B logistics and burns money in downtime.
'Vibe Coding' (unsupervised AI generation) is inflating technical debt to unsustainable levels.
A technical performance audit is the first practical step toward making compliance verifiable.

Latency in the Field Burns Money

When evaluating the technical infrastructure of private ports and agro-exporters, the pattern repeats itself. Hundreds of trucks wait during peak harvest while the freight loading system—built on a heavy framework no one asked for—takes 15 seconds to respond. The 4G signal is unstable, and the driver's smartphone freezes trying to parse 5MB of redundant JavaScript.

The truck doesn't move. The line grows. Efficiency plummets.

The Cost of Inefficiency: 15s+ blocking time on mid-range devices under rural networks.
Conversion Impact: ~15% sales loss per second of latency based on 2026 industry benchmarks.

This isn't about user patience. It's a hard technical blockade. Your software cannot rely on a fiber-optic connection to function in a rural silo. Performance is a design constraint, not an afterthought optimization.

Privacy by Design: How to audit hidden trackers in the bundle

Excessive JavaScript doesn't just slow down your site; it drastically increases the attack and monitoring surface where unaudited third-party integrations can hide, often leaking data without oversight.

When auditing corporate systems and B2B platforms, the finding is almost universal: forgotten marketing pixels, analytics from agencies that no longer work with the company, and widgets that read user IPs and behavior without oversight.

Industry benchmarks show that while third-party scripts might only represent 15% of the total page weight, they can monopolize the browser's CPU execution time, often hiding data leaks behind performance bottlenecks. Under modern privacy laws, this is a massive legal liability.

These laws demand Privacy by Design. If you don't know what those 3MB of scripts are loading in your client's browser, you are operating blind. Auditing the Network Payload is the only practical way to verify what data is actually leaving your system. Without that visibility, compliance is purely theoretical. If you cannot audit the origin of every bit you send, you do not have sovereignty over your data.

The systemic impact of AI-driven "Vibe Coding"

Generating code with Claude or Copilot is easy; understanding its systemic consequences is the real job. The trend of "Vibe Coding"—accepting AI-generated code without reviewing new dependencies, bundle size impact, or data flow—is creating systems that are functionally correct but architecturally obese.

An AI agent can deliver a functional portal in 48 hours, but it will hand it to you coupled and full of redundant dependencies that no one will know how to maintain in two years.

The Trade-offs of Vibe Coding:
✅ Pros: Aggressive Time-to-Market, Almost instant prototyping.
❌ Cons: Technical debt multiplied, Payloads that destroy INP and mobile UX, 'Ghost' dependencies that no one audited.

AI writes fast, but your infrastructure pays the bill slowly. A Senior Architect has never been more necessary to filter the noise of generated code.

The Stack Autopsy

At campa.dev, we don't audit to get a 100 on Lighthouse; that's just the baseline. We audit to make your business resilient:

Real Stress Metrics: We test INP (Interaction to Next Paint) on devices people actually use in the field, not on an M3 MacBook Pro.
Payload Cleansing: We identify which scripts violate data protection laws by sending data to external servers without consent.
Migration Path: We evaluate if your bloated SPA should become a static site in Astro 6 to save 40% on server costs.

Most companies don't have a performance problem. They have a visibility problem.
They don't know what's running on their frontend.
They don't know what data is leaving.
They don't know what they are breaking.

A sovereign, fast, and legal system is your right to operate without friction, but you cannot fix what you haven't measured. Do you know what your code is doing right now?

If your business handles critical data and you can't afford to be legally exposed, let's talk. Check out the original deep-dive on my blog: campa.dev - Performance is Compliance

Edge Validation: Why Zod 4 is the Standard for SEO

Hugo Campañoli — Tue, 21 Apr 2026 13:57:36 +0000

If you want Google, Perplexity, and ChatGPT to cite your content with mathematical precision, you can't leave your metadata to chance. Data integrity is the absolute foundation of modern technical authority.

Validating data isn't just about avoiding a terminal error; it's about ensuring your GEO entities and JSON-LD schemas are bulletproof from the server. Zod 4 solves this directly at the Edge or at build time, shielding your ranking without shipping a single byte to the client.

The "Metadata Slop" Problem

We're tired of seeing sites injecting broken JSON-LD because an author forgot to close a quote or put a relative URL in the frontmatter instead of an absolute one.

The Cost of Failure: A malformed schema isn't just ignored in 2026; LLMs assume the source is unreliable, discard your content, and look for the answer on your competitor's domain.

Zod 4 to the Rescue

With the Astro 6 Content Layer, you can process and validate all your content before it even touches the HTML. Zod 4 is the gatekeeper of this frontier.

Performance Pro-Tip: Zod 4 uses a JIT (Just-In-Time) compilation engine that makes it up to 14 times faster than v3. But beware: schema compilation has a cost. Hoist your schemas: always define them outside your collections so they compile only once, not on every loader cycle.

Look at how we build a bulletproof schema using the new official import:

// src/content.config.ts
import { defineCollection } from "astro:content";
import { z } from "astro/zod"; 

// Hoist the schema to leverage Zod 4 JIT 
const seoSchema = z.object({
  title: z.string().max(80),
  canonicalURL: z
    .string()
    .url()
    .transform((val) => val.trim().toLowerCase()),
  geoEntities: z.array(z.string()).min(2, "Minimum 2 entities"),
});

const blog = defineCollection({
  loader: glob({ pattern: "**/*.md", base: "./src/content/blog" }),
  schema: seoSchema,
});

That .transform() is pure magic. It normalizes data (trimming spaces and forcing lowercase) ensuring that your <Schema /> generating component receives exactly what it needs to build the perfect knowledge graph.

Impact on Performance and Authority

Thanks to the new JIT engine, parsing speed is 14 times faster than in Zod 3.

Unlike previous versions, Zod 4 unifies synchronous and asynchronous execution paths without the "double execution" penalty. This allows real-time checks during the Astro 6 build. If the data is bogus, the build fails: failing fast in CI/CD is infinitely better than pushing garbage metadata to production.

Test it today. Break your frontmatter on purpose and see how Zod catches the problem before it ruins your rankings. Implement strict validation if you don't want AI to have any room to invent data about your project.

This TIL was originally published on my blog. You can find more engineering, Astro, and Web Performance deep-dives at campa.dev.

Privacidad por Diseño: Checklist técnico para la Ley 7593/2025

Hugo Campañoli — Thu, 16 Apr 2026 14:50:00 +0000

La privacidad por diseño deja de ser una sugerencia ética para transformarse en el estándar legal obligatorio bajo la Ley 7593/2025 de Paraguay. Este cambio legislativo marca un hito en la madurez digital del país, obligando a empresas y desarrolladores a repensar cómo capturan, almacenan y protegen la información ciudadana.

El MITIC ha sido claro: no bastará con términos y condiciones genéricos; el software debe integrar protecciones técnicas desde la arquitectura inicial, no como un parche posterior.

¿Qué exige la Ley 7593/2025 a tu software?

La ley establece que el responsable del tratamiento de datos debe implementar medidas técnicas y organizativas desde el diseño del sistema. No es un checklist que se añade antes del deploy. Es arquitectura.

Sanciones: La Ley 7593/2025 prevé multas de hasta 20.000 jornales mínimos para quienes no implementen medidas de protección adecuadas. Con el jornal de 2026, eso supera los ₲ 2.230 millones por incidente.

La traducción técnica de la ley es directa:

Artículo de Ley	Qué dice	Requerimiento Técnico
Art. 4(d) — Minimización	Datos "limitados a lo necesario"	Validar que solo se recopilan campos necesarios
Art. 6 — Consentimiento	"Previo, libre, e inequívoco"	Opt-in explícito + registro auditado de versión legal
Art. 9 — Responsable	"Medidas técnicas apropiadas"	Privacy-by-design en la arquitectura
Art. 16 — Seguridad	"Monitoreo y mejora continua"	Cifrado en tránsito y en reposo (AES-256)
Arts. 26-31 — Derechos ARCO	Acceso y supresión en ≤30 días	API de exportación + endpoint de eliminación

¿Cómo implementar privacidad por diseño en tu stack?

La respuesta corta: no guardes lo que no necesitás, cifrá lo que sí guardás, y dejá que el usuario borre todo cuando quiera.

Paso 1: Minimización de datos

Cada campo que agregás a un formulario es una responsabilidad legal. Validá en el schema, no en el frontend:

import * as z from "zod";

// Schema que rechaza datos innecesarios por diseño
export const ContactFormSchema = z.strictObject({
  email: z.email(),
  message: z.string().min(10).max(500),
  // Sin teléfono, sin nombre completo, sin dirección
});

export type ContactForm = z.infer<typeof ContactFormSchema>;

z.strictObject() rechaza cualquier campo que no esté en el schema. Si alguien intenta inyectar data extra, Zod tira un error. La minimización se vuelve inquebrantable.

Paso 2: Consentimiento explícito

Una casilla pre-marcada no es consentimiento. Necesitás un opt-in explícito y auditado:

export interface ConsentRecord {
  userId: string;
  purpose: string;
  timestamp: Date;
  userAgent: string;
  legalTextVersion: string; // El hash del texto legal vigente
}

El legalTextVersion es clave: si actualizás los términos, necesitás saber qué versión aceptó cada usuario.

Paso 3: Cifrado y retención

Los datos que guardás tienen fecha de vencimiento. La retención indefinida es incumplimiento automático:

// Job diario que purga datos expirados
export async function purgeExpiredData() {
  const RETENTION_DAYS = 365;
  const cutoff = new Date();
  cutoff.setDate(cutoff.getDate() - RETENTION_DAYS);

  await db.user.updateMany({
    where: {
      AND: [{ lastActiveAt: { lt: cutoff } }, { purposeConsent: null }],
    },
    data: {
      email: `anon-${crypto.randomUUID()}@anonimizado.local`,
      name: "Usuario Anonimizado",
      status: "pending_deletion",
    },
  });
}

La privacidad por diseño no te hace menos ágil — te hace más profesional. Y en Paraguay, donde la transformación digital del agro y el comercio apenas arranca, ser el que cumple primero es un diferencial que tus clientes van a notar.

Para ver el código completo y los componentes de arquitectura, revisá el artículo original en mi blog.

Algebraic Data Types in TS: Indestructible Payment Flows

Hugo Campañoli — Fri, 10 Apr 2026 18:23:27 +0000

Your payment flow has a status: string field? You're one typo away from a double charge. A silent "pednign" in production won't throw an error; it loses money.

Algebraic Data Types (ADTs) in TypeScript let you model states where invalid data is compiler-illegal. Not just "unlikely." Forbidden.

The problem: The bag of optionals

// ❌ Everything is possible... including double charging
interface PaymentState {
  status: string;
  transactionId?: string;
  errorMessage?: string;
  receiptUrl?: string;
  retryable?: boolean;
}

// When does transactionId exist?
// Is it safe to read receiptUrl?
// Nobody knows. Runtime will tell.

When you use a simple string for status, you end up with an interface where everything is optional. The compiler cannot help you because it doesn't know the relationship between the status and the data.

The solution: Discriminated Unions

// ✅ The compiler forbids illegal states
type PaymentState =
  | { status: "idle" }
  | { status: "pending"; intentId: string }
  | {
      status: "processing";
      intentId: string;
      gateway: "bancard" | "stripe";
    }
  | {
      status: "success";
      transactionId: string;
      receiptUrl: string;
    }
  | {
      status: "failed";
      errorCode: number;
      errorMessage: string;
      retryable: boolean;
    };

Each union variant carries only relevant data. No transactionId in "pending"; no errorMessage in "success". The compiler guarantees integrity.

The Guard: Exhaustive switch with `never`

function handlePayment(state: PaymentState): string {
  switch (state.status) {
    case "idle":
      return "Waiting for user action";
    case "pending":
      return `Intent created: ${state.intentId}`;
    case "processing":
      return `Processing via ${state.gateway}...`;
    case "success":
      return `✅ TX: ${state.transactionId}`;
    case "failed":
      return state.retryable
        ? `Error ${state.errorCode}: retrying`
        : `Fatal error: ${state.errorMessage}`;
    default:
      // Added a new state and forgot to handle it?
      // TypeScript yells here ↓
      const _exhaustive: never = state;
      return _exhaustive;
  }
}

Without that never, any new state added to the union passes silently through the switch. In a payment flow, "silent" means "duplicate charges at 3AM without logs."

ADTs vs. Alternatives

Discriminated Unions (ADTs)

Pros:
- State-specific data (no loose optionals)
- Automatic compiler narrowing in each case
- Native exhaustiveness checks with never
- Zero runtime overhead (erased during compilation)

String Enums / Class Hierarchy

Cons:
- Enums: don't link data to state; everything stays optional
- Classes: runtime overhead + fragile instanceof checks
- Enums + interfaces: you duplicate the source of truth

Why it works (The Aha! Moment)

An ADT combines finite states with specific data variants. The compiler is your first QA. If you forget a case, it yells before the code ever hits staging. In payments, "unlikely" isn't enough; you need it to be illegal to represent.

A string is a promise. A union is a contract.

Originally published at campa.dev

Why Astro 6's 0kb JS is the Ultimate Enterprise SEO Solution

Hugo Campañoli — Thu, 09 Apr 2026 03:00:00 +0000

Crawl Budget is the most scarce resource in enterprise SEO. Google defines it as "the number of URLs Googlebot can and wants to crawl" — and that number has an efficiency ceiling.

Sites with 100k+ URLs that rely on JS-heavy frameworks (Next.js, Nuxt) often waste critical crawling capacity in the Web Rendering Service (WRS). This is Google's infrastructure that executes JavaScript, but it creates processing queues that can last days or even weeks.

Astro 6 solves this by design: Pure static HTML, 0kb JS runtime by default, and an Island architecture that protects rendering fidelity.

The Cost of JavaScript Rendering

Googlebot goes through two passes to index your content:

Crawl: It downloads the HTML.
Rendering: It executes the JS in the WRS.

The second pass is an asynchronous queue. If your content is hidden behind JS, Googlebot won't "see" it until its turn comes up in the queue. This creates "Zombie Pages": URLs that are discovered but have incomplete content in the index.

The 5 Infrastructure Gates

Jason Barnard describes the pipeline as 5 sequential gates:
Discovery → Selection → Crawling → Rendering → Indexing.

With Astro 6, the rendering gate is practically bypassed. The content is already in the HTML that Googlebot downloads during the Crawling phase.

Feature	Legacy (SSR/CSR)	Astro 6 (SSG/Islands)
JS Runtime	150-400kb (typical)	0kb (default)
Infra Gates	5 Gates (Discovery to Index)	4 Gates (Skips Rendering)
Render Fidelity	Variable (Depends on WRS)	100% (HTML is the truth)
AI Bot Visibility	Partial	Complete

The AI Factor: Bots don't execute JS

There is an angle most people ignore: AI bots don't execute JavaScript.

Most search engines (Google, Bing) have rendering capabilities. But Perplexity, smaller AI agents, and training crawlers mostly work with the initial HTML. If your content depends on client-side rendering, to these bots, your content doesn't exist.

Use Cases: Astro 6 vs Next.js

It's not about which framework is "better," but which is right for the job.

✅ Use Astro 6 for (Content is King):

E-commerce with large catalogs (100k+ products).
Directories and Marketplaces with static content.
Technical documentation portals.
Enterprise landing pages at scale.

❌ Use Next.js for (Logic is King):

Real-time data dashboards.
Apps with complex route-based authentication.
Collaborative tools (editors, whiteboards).
SaaS platforms with heavy client-side business logic.

Conclusion: Ockham's Razor for SEO

The simplest solution is usually the right one. If Googlebot isn't indexing all your URLs, the answer isn't more servers or more complex SSR. The answer is less JavaScript.

In 2026, with AI bots becoming a major source of digital visibility, static HTML is no longer just a performance optimization — it's a multi-bot visibility strategy.

Originally published at campa.dev

Zod 4 - From Validation to Data Pipelines

Hugo Campañoli — Wed, 08 Apr 2026 14:42:33 +0000

Validating that a field exists is the floor, not the ceiling. Your CMS or API data is often "dirty": dates as strings, empty tags, non-normalized slugs. If you clean this up in your components, you're duplicating logic that Zod 4 can solve in a single schema.

In this guide, we'll see how to transform your validation into a pure data pipeline.

From Validator to Transformation Pipeline

Look at the difference between a schema that only validates and one that transforms, normalizes, and performs cross-field validation:

// Advanced Schema — Validate + Transform + Normalize
const blogSchema = z.object({
  title: z.string().trim(),
  slug: z.string()
    .transform((s) => s.toLowerCase().replace(/\s+/g, "-")),
  publishedAt: z.string()
    .transform((s) => new Date(s)),
  tags: z.array(z.string())
    .transform((arr) => arr.filter(Boolean)),
}).superRefine((data, ctx) => {
  if (data.publishedAt > new Date()) {
    ctx.addIssue({
      code: "custom",
      message: "Date cannot be in the future",
      path: ["publishedAt"],
    });
  }
});

The Three Patterns You Need to Know

1. .transform() — Modify data after validation
Change the output type directly in the schema.

2. .superRefine() — Cross-field validation
Perfect for complex rules like "Published articles require a date, but drafts don't".

3. .prefault() — The new Zod 4 pre-parse default
In Zod 4, .default() applies after the transform. Use .prefault() if you need the default value to pass through your transformation pipeline (Zod 3 behavior).

Where should the logic go?

In the Schema (Zod): Single source of truth, automatic output typing, zero boilerplate in UI.
In Components: Dispersed logic, harder to test, and redundant.

Validating is easy. Transforming with elegance is the art of a Senior Engineer.

Originally published at: campa.dev

Forem: Hugo Campañoli

The Lindy Effect: Why Web Standards Are a Safer Financial Investment Than the Latest JS Framework

What does the Lindy Effect tell us about technical debt?

Why is choosing a framework a financial gamble?

Long-term ROI: The 0kb Approach

Conclusion

TypeScript DeepPath: Achieving Indestructible Types in Nested Objects

Why you need DeepPath

The silent bug

The pattern: Recursive DeepPath

Developer Evolution: Using satisfies

💥 Bonus Track: Return Type Inference (DeepValue)

The cost of magic (Trade-offs)

Conclusion

Your Slow Website is a Legal Risk: Why Technical Debt is Now a Liability

The TL;DR

Latency in the Field Burns Money

Privacy by Design: How to audit hidden trackers in the bundle

The systemic impact of AI-driven "Vibe Coding"

The Stack Autopsy

Edge Validation: Why Zod 4 is the Standard for SEO

The "Metadata Slop" Problem

Zod 4 to the Rescue

Impact on Performance and Authority

Privacidad por Diseño: Checklist técnico para la Ley 7593/2025

¿Qué exige la Ley 7593/2025 a tu software?

¿Cómo implementar privacidad por diseño en tu stack?

Paso 1: Minimización de datos

Paso 2: Consentimiento explícito

Paso 3: Cifrado y retención

Algebraic Data Types in TS: Indestructible Payment Flows

The problem: The bag of optionals

The solution: Discriminated Unions

The Guard: Exhaustive switch with never

ADTs vs. Alternatives

Discriminated Unions (ADTs)

String Enums / Class Hierarchy

Why it works (The Aha! Moment)

Why Astro 6's 0kb JS is the Ultimate Enterprise SEO Solution

The Cost of JavaScript Rendering

The 5 Infrastructure Gates

The AI Factor: Bots don't execute JS

Use Cases: Astro 6 vs Next.js

✅ Use Astro 6 for (Content is King):

❌ Use Next.js for (Logic is King):

Conclusion: Ockham's Razor for SEO

Zod 4 - From Validation to Data Pipelines

From Validator to Transformation Pipeline

The Three Patterns You Need to Know

Where should the logic go?

Developer Evolution: Using `satisfies`

The Guard: Exhaustive switch with `never`