TypeScript para validar una MVP de pedidos en una ferretería tradicional

Este tutorial muestra cómo validar una oferta de pedidos para una ferretería que todavía trabaja con teléfono, cuaderno o WhatsApp. La propuesta no automatiza el negocio: permite probar si los clientes piden materiales con cierta frecuencia, usan el mismo proceso y aceptan una atención personalizada.

Decide qué quieres comprobar

El objetivo de este primer paso es definir qué se va a validar. No se debe construir una app completa ni prometer entrega inmediata. La validación puede responder tres preguntas: cuántos pedidos llegan por semana, qué productos se piden con más frecuencia y qué información falta para cumplir cada pedido.

El equipo debe fijar una meta concreta, como registrar durante 30 días los intentos de pedido y las respuestas de los clientes. También conviene decidir qué se hará si la meta no se alcanza. Por ejemplo, cambiar el mensaje, el canal de contacto o el tipo de producto ofrecido.

Crea un archivo de validación

Abre una carpeta nueva y ejecuta estos comandos:

mkdir pedidos-ferreteria
cd pedidos-ferreteria
npm init -y
npm install -D typescript tsx

Crea un archivo tsconfig.json con este contenido:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true
  },
  "include": ["src/**/*.ts"]
}

Crea src/validate.ts y pega este contenido:

type OrderItem = {
  productId: string;
  name: string;
  quantity: number;
};

type ValidationOrder = {
  customerName: string;
  customerPhone: string;
  address: string;
  items: OrderItem[];
};

const minimumQuantity = 1;
const requiredFields = ["customerName", "customerPhone", "address"] as const;

function validateOrder(input: ValidationOrder): string[] {
  const errors: string[] = [];

  for (const field of requiredFields) {
    const value = input[field];
    if (typeof value !== "string" || value.trim().length === 0) {
      errors.push(`${field} es requerido`);
    }
  }

  if (input.items.length === 0) {
    errors.push("items debe tener al menos un producto");
  }

  for (const item of input.items) {
    if (item.quantity < minimumQuantity) {
      errors.push(`La cantidad de ${item.name} debe ser mayor o igual a ${minimumQuantity}`);
    }
  }

  return errors;
}

const sampleOrder: ValidationOrder = {
  customerName: "Juan Pérez",
  customerPhone: "+56912345678",
  address: "Calle Falsa 123",
  items: [
    {
      productId: "cemento-25kg",
      name: "Cemento 25 kg",
      quantity: 2
    }
  ]
};

const errors = validateOrder(sampleOrder);

console.log(errors.length === 0 ? "Pedido válido" : `Errores encontrados: ${errors.join("; ")}`);

Este archivo no llama a una base de datos ni a una API externa. Solo recibe un objeto con los datos de un intento de pedido y devuelve mensajes específicos. La validación exige nombre, teléfono y dirección; además, exige al menos un producto y una cantidad mayor o igual a uno. El ejemplo usa el identificador cemento-25kg para mostrar cómo se puede distinguir un producto de su nombre.

Ejecuta y mide la validación

1. Ejecuta npm run validate para comprobar el archivo de configuración.
2. Ejecuta npx tsx src/validate.ts para ejecutar el ejemplo.
3. Copia el mismo flujo en la herramienta que usa la ferretería: una planilla, un formulario o un script interno. No cambies las reglas durante la prueba.
4. Registra fecha, canal, producto, cantidad y resultado de validación. No guardes datos sensibles innecesarios.
5. Al finalizar los 30 días, compara los intentos válidos con los pedidos que llegaron a atención. La métrica principal debe ser la proporción de intentos válidos, no una cifra de ventas inventada.

Si aparecen errores, revisa el mensaje devuelto y corrige el dato del cliente o la estructura del formulario. Si no aparecen errores, el flujo básico está listo para probar con una persona real. No se debe considerar válido un pedido solo porque el formulario lo aceptó; la ferretería debe confirmar disponibilidad, precio y condiciones de entrega.

Errores frecuentes

• Confundir validación técnica con validación de negocio: TypeScript puede detectar campos faltantes, pero no sabe si el cliente realmente comprará.
• Guardar todos los datos de contacto sin explicar para qué se usan. Recoge solo lo necesario y define cuánto tiempo se conservará.
• Usar cantidades negativas, textos vacíos o productos sin identificador. Mantén reglas simples y visibles para quien completa el formulario.
• Automatizar de más desde el primer día. No conectes pagos, inventario o envíos hasta entender el proceso real.
• Medir solo pedidos completados. También cuenta los intentos rechazados, las preguntas y las razones por las que un cliente no continúa.

Cuándo conviene y cuándo no

Este enfoque sirve cuando la ferretería quiere probar una atención de pedidos sin contratar una startup ni desarrollar una plataforma completa. También sirve para un equipo de producto que necesita observar el comportamiento antes de definir una base de datos o una interfaz.

No conviene usarlo si el objetivo es procesar pagos, controlar stock en tiempo real o prometer entregas automáticas. En esos casos hay que agregar autenticación, permisos, auditoría, conciliación y un proceso de soporte.

Próximo paso

Después de la prueba, conversa con al menos cinco clientes y cinco personas que atienden la ferretería. Pregunta qué parte del proceso fue confusa, qué dato faltó y qué decisión tomaron. Con esas respuestas, decide si se mantiene el flujo, se elimina un paso o se cambia el canal de contacto.