DEV Community: Alejandro Olivar

(Spanish)📝 Caso de Estudio: Si Presto! — De cuadernos de notas a una arquitectura Offline-First en Flutter

Alejandro Olivar — Sun, 12 Jul 2026 17:04:34 +0000

📌 Introducción: El origen del problema (De una libreta a código)

El software más útil nace de resolver problemas reales cotidianos. Este proyecto comenzó cuando observé a un familiar que prestaba dinero de manera informal. Su sistema de gestión consistía en una libreta física y hojas de cálculo en Excel.

El resultado era caótico:

Olvidos frecuentes en las fechas de cobro.
Falta de claridad al calcular abonos parciales o intereses acumulados.
Horas perdidas redactando manualmente estados de cuenta por WhatsApp.

Para solucionar esto, decidí diseñar e implementar Si Presto!, una aplicación móvil nativa construida con Flutter y Firebase enfocada en el control de préstamos informales, optimizada para contextos de baja conectividad y con un modelo híbrido de monetización.

🏗️ La Arquitectura: Diseño de Software y Flujo de Datos

Para asegurar un rendimiento óptimo en dispositivos de cualquier gama, estructuré la aplicación bajo una Arquitectura Limpia (Clean Architecture) organizada en un Monorepo móvil con separación estricta de responsabilidades:

lib/
  ├── core/                  # Temas, PDF engines, notificaciones locales
  ├── domain/                # Entidades inmutables (Freezed) e interfaces
  ├── data/                  # Fuentes de datos (Isar NoSQL, Firebase Auth) y modelos
  └── presentation/          # Gestión de estado (Riverpod) y páginas UI

El Flujo de Datos Híbrido:

UI ➔ Riverpod StateNotifiers ➔ Repositorios ➔ Isar DB (Local) ➔ Firebase Cloud Backup (Premium).

Toda la generación de código inmutable y reactivo se automatizó utilizando build_runner con herramientas como @freezed, @riverpod e @Isar.

🛡️ Los 4 Grandes Retos Técnicos de Ingeniería

1. Sincronización Offline-First y Consistencia de Datos en Venezuela

El Problema: La aplicación debe funcionar sin fricciones en zonas con conectividad intermitente o nula. Si el cobrador registra un abono en la calle sin señal, los saldos locales no pueden duplicarse ni corromperse al recuperar la red.

La Solución: Implementé un modelo Offline-First utilizando Isar Database como almacenamiento NoSQL local de alto rendimiento. La aplicación realiza todas las operaciones CRUD de forma síncrona en la base de datos local y, mediante un servicio de sincronización en segundo plano, respalda la información en la nube con Cloud Firestore únicamente si el usuario cuenta con conectividad y posee el plan Premium.

2. Generación Dinámica de PDF Nativos en Dispositivos de Gama Baja

El Problema: Generar reportes financieros detallados consume memoria. Si el renderizado se realiza de forma ineficiente, los teléfonos de gama baja pueden sufrir cierres inesperados (crashes por OOM).

La Solución: Diseñé un motor de renderizado transaccional utilizando los paquetes nativos pdf y printing. El motor procesa las colecciones inmutables de transacciones en bloques (chunks) directamente en la memoria caché del dispositivo, ensamblando el PDF en tiempo real para que el cobrador pueda exportarlo y compartirlo inmediatamente por WhatsApp sin sobrecargar el procesador del teléfono.

3. Modelo de Monetización Híbrido (AdMob + RevenueCat)

El Problema: Mantener la aplicación requiere rentabilidad, pero saturar una herramienta financiera de cobros con anuncios intrusivos arruina por completo la experiencia de usuario (UX).

La Solución: Implementé un esquema Freemium controlado minuciosamente desde la capa de datos:

Free Tier: Límites lógicos quemados en el repositorio (Máximo 3 deudores y 4 pagos por préstamo) financiados mediante banners publicitarios no intrusivos usando Google Mobile Ads.
Premium Tier: Integrado de manera limpia con el SDK de RevenueCat. Al detectar la compra activa mediante el singleton PurchaseService, la aplicación remueve por completo los anuncios, desbloquea deudores/pagos ilimitados, habilita la exportación a PDF y activa el respaldo en la nube con Cloud Firestore.

4. Automatización de Alertas y Notificaciones Locales

Para eliminar la dependencia constante de servidores externos (Push Notifications) que pueden fallar si el dispositivo no tiene datos móviles, configuré un servicio autónomo basado en flutter_local_notifications. La aplicación programa internamente recordatorios de cobro locales basados en las fechas límite de las entidades del dominio de datos, manteniendo al cobrador alerta sin consumir datos de red.

🎨 Identidad Visual: Estética Neobrutalista Oscura

Para mantener la coherencia con mi marca personal, la interfaz de Si Presto! adopta un estilo Neobrutalista Oscuro caracterizado por:

Un fondo oscuro profundo de alto contraste combinado con un verde neón eléctrico (#00FF99) para destacar los saldos positivos.

Tarjetas de resumen financiero con bordes marcados y sombras sólidas planas desplazadas, rompiendo con los diseños tradicionales y planos de las aplicaciones bancarias comunes.

🧠 Lecciones de Ingeniería de Producto

Construir Si Presto! partiendo de una necesidad familiar real me enseñó que la arquitectura de software senior no se mide por la cantidad de servicios en la nube que utilices, sino por saber delegar eficientemente el cómputo. Al elegir almacenar datos localmente con Isar, renderizar PDFs nativos en el cliente y programar notificaciones locales, reduje los costes de infraestructura de la aplicación a prácticamente cero dólares para el nivel gratuito, asegurando un producto escalable y altamente rentable.

Link: https://portfolio-three-topaz-81.vercel.app/es/projects/si-presto

📝 Caso de Estudio: Cómo construir un SaaS Multi-tenant con Next.js 16, NestJS 11 y PostgreSQL RLS

Alejandro Olivar — Sat, 27 Jun 2026 16:05:22 +0000

Introducción: El problema de los portafolios aburridos

Seamos honestos. La mayoría de los portafolios de desarrolladores se ven exactamente iguales: una plantilla minimalista genérica, una cuadrícula con proyectos simples y una lista de tecnologías que nadie entra a auditar.

Cuando rediseñé mi espacio web, quise enfocarlo de otra manera: mostrar ingeniería real aplicada a producción. En lugar de subir 10 proyectos pequeños, decidí desglosar casos de estudio profundos.

Este es el análisis técnico de Äbasto, un SaaS B2B full-stack para la gestión de inventario y puntos de venta (POS) que resuelve el aislamiento de datos, subdominios dinámicos y un sistema de suscripción con periodos de gracia bajo un único monorepo con pnpm workspaces.

🏗️ El Stack Tecnológico

El proyecto está estructurado de manera eficiente en un monorepo:

Frontend: Next.js 16 (App Router), Zustand (para persistencia de estado local) y Tailwind CSS v4.

Backend: NestJS 11, TypeORM y PostgreSQL.

🛡️ Reto 1: Aislamiento de datos a nivel de Base de Datos (PostgreSQL RLS)

Cuando construyes un SaaS donde múltiples bodegas independientes gestionan inventarios, las filtraciones de datos entre clientes son tu peor pesadilla. Depender de añadir un WHERE warehouse_id = X en cada query del backend es peligroso y propenso a errores humanos.

La Solución: Row-Level Security (RLS)
Delegué el aislamiento de datos directamente al motor de PostgreSQL usando seguridad a nivel de fila.

Cada transacción se ejecuta de forma aislada. Un JwtAuthGuard personalizado en NestJS intercepta la petición, decodifica los datos del inquilino (tenant) e inyecta variables de sesión en la base de datos usando comandos SQL SET LOCAL:

// Inyección dinámica del contexto del inquilino
async function injectTenantContext(queryRunner: QueryRunner, warehouseId: string) {
  // Ejecución segura dentro del bloque de la transacción de la petición
  await queryRunner.query(`SET LOCAL app.current_warehouse_id = '${warehouseId}'`);
}

En la base de datos, las tablas imponen el aislamiento de forma nativa:

ALTER TABLE inventory ENABLE ROW LEVEL SECURITY;

CREATE POLICY warehouse_isolation_policy ON inventory
    USING (warehouse_id = NULLIF(current_setting('app.current_warehouse_id', true), ''));

Esto significa que incluso si a un desarrollador se le olvida filtrar por bodega en el código, PostgreSQL bloqueará por defecto cualquier intento de acceso cruzado.

🌐 Reto 2: Subdominios dinámicos multi-tenant en Next.js 16

Quería que cada dueño de bodega tuviera un subdominio único y limpio (ej: mi-tienda.lvh.me:3000).

La Solución: Proxy de reescritura dinámica
En lugar de saturar el sistema con un middleware.ts pesado, utilicé un bloque de ejecución proxy.ts en el servidor de Next.js 16. Este lee la cabecera Host en tiempo real y reescribe las rutas internamente:

// frontend/src/proxy.ts (Lógica simplificada)
export function handleSubdomainRewrite(requestHeaders: Headers) {
  const host = requestHeaders.get('host'); // ej: 'bodega-x.lvh.me:3000'
  const subdomain = host.split('.')[0];

  // Ignorar las rutas del sistema reservadas internamente
  if (subdomain === 'admin' || subdomain === 'www') {
    return null; 
  }

  // Realiza una reescritura interna hacia la ruta dinámica de la tienda
  return `/store/${subdomain}`;
}

El truco de seguridad Server-Side
Para evitar que un usuario manipule la URL y suplante la identidad de otra tienda, el proxy lee la cookie de sesión token (configurada con alcance global domain=.lvh.me), decodifica el JWT en el servidor y verifica si la bodega autorizada coincide estrictamente con el subdominio solicitado. Si no hay coincidencia, redirige inmediatamente a /no-access.

⏳ Reto 3: Restricción automatizada y motor de suscripciones

Un SaaS real necesita monetizarse y aplicar restricciones de uso de forma inteligente, sin bloquear el acceso histórico del cliente arbitrariamente. Diseñé un modelo con un periodo de gracia de 3 días.

Estado Activo -> [Fecha Expiración] -> Periodo de Gracia (Banners) -> Bloqueo Completo de Operaciones

El Guardián del Backend (SubscriptionGuard)
Construí un SubscriptionGuard global aplicado a todos los endpoints de escritura (POST, PATCH, DELETE) en los módulos críticos de productos, inventario y proveedores:

@Injectable()
export class SubscriptionGuard implements CanActivate {
  async canActivate(context: ExecutionContext): Promise<boolean> {
    const req = context.switchToHttp().getRequest();
    const { expiresAt, gracePeriodDays } = req.user; // Datos inyectados en la sesión

    const absoluteDeadline = new Date(expiresAt);
    absoluteDeadline.setDate(absoluteDeadline.getDate() + (gracePeriodDays || 3));

    if (new Date() > absoluteDeadline) {
      throw new ForbiddenException('Suscripción expirada. Operaciones de escritura bloqueadas.');
    }
    return true; // Las peticiones GET (lectura) siguen abiertas
  }
}

Comportamiento en el Frontend

Faltando 5 días para vencer: Un banner ámbar dinámico (SubscriptionBanner) aparece en el Dashboard.
Durante el Periodo de Gracia: El banner cambia a color naranja de advertencia.
Pasado el Periodo de Gracia: Un componente de bloqueo de pantalla completa (SubscriptionLock) toma el control del punto de venta (POS) mostrando un botón directo de soporte mediante enlaces dinámicos de WhatsApp (wa.me).

📨 Reto 4: Notificaciones híbridas (Emails con Resend y atajos de WhatsApp)

Para mantener una comunicación operativa fluida sin incurrir en costes elevados de infraestructura, implementé un sistema de notificación de doble canal:

Canal A (Mails transaccionales automatizados): Un módulo global de notificaciones se conecta con el SDK de Resend en el backend. Dispara correos formateados con plantillas HTML de estilo neobrutalista oscuro ante eventos críticos (bienvenida, restablecimiento de contraseña y alertas de facturación gestionadas por un CRON job diario a mediodía).
Canal B (Flujos manuales de WhatsApp): Desde el panel de administración, el SuperAdmin cuenta con botones contextuales que generan mensajes dinámicos basados en el estado de cuenta del cliente, facilitando el cobro manual con un solo clic.

🧠 Conclusiones

Desarrollar Äbasto me demostró que vale mucho más la pena documentar la resolución de problemas arquitectónicos reales y complejos que acumular repositorios sencillos. Esto valida habilidades críticas:

Comprensión avanzada de seguridad y rendimiento en bases de datos.
Arquitectura de redes y enrutamiento en el servidor (proxies, manejo de DNS internos).
Enfoque de producto y lógica de negocio orientada a la monetización.

Link: https://portfolio-three-topaz-81.vercel.app/en/projects/abasto

¿Cómo gestionas tú el aislamiento de datos en tus proyectos SaaS? ¿Prefieres bases de datos separadas o aislamiento lógico por fila (RLS)? ¡Debatamos en los comentarios!

Deep Dive: Handling Multi-Tenancy Subdomains and DB Isolation without breaking Next.js 16

Alejandro Olivar — Thu, 25 Jun 2026 16:07:04 +0000

The Boring Portfolio Problem

Let's be honest. Most developer portfolios look exactly the same: a clean minimalist template, a grid of generic projects, and a bulleted list of tech stacks.

When I built my portfolio, I wanted to showcase real-world production engineering. Instead of pushing 10 tiny code sandboxes, I decided to focus on deep-dive case studies.

This is the breakdown of Äbasto, a full-stack, multi-tenant B2B SaaS for warehouse and POS management that handles data isolation, dynamic subdomains, and an automated grace-period subscription model under a single pnpm workspace monorepo.

🏗️ The Architecture Stack

he project is structured as a scalable monorepo using pnpm workspaces:

Frontend: Next.js 16 App Router, Zustand (state persistence), and Tailwind CSS v4.
Backend: NestJS 11, TypeORM, and PostgreSQL.

🛡️ Challenge 1: Tenant Data Isolation at DB Level (PostgreSQL RLS)

When building a B2B SaaS where multiple independent warehouses manage inventory, global multi-tenancy leaks are your worst nightmare. Adding WHERE warehouse_id = X to every database query is prone to human error and scale bugs.

The Solution: Row-Level Security (RLS)
I delegated data isolation directly to PostgreSQL using Row-Level Security.

Every database transaction runs securely isolated. A custom JwtAuthGuard in NestJS intercepts the request, decodes the tenant data, and injects session variables directly using SQL SET LOCAL commands:

// A high-level view of injecting session context dynamically
async function injectTenantContext(queryRunner: QueryRunner, warehouseId: string) {
  // Safe runtime execution within the request transaction block
  await queryRunner.query(`SET LOCAL app.current_warehouse_id = '${warehouseId}'`);
}

In the DB layer, tables enforce isolation natively:

ALTER TABLE inventory ENABLE ROW LEVEL SECURITY;

CREATE POLICY warehouse_isolation_policy ON inventory
    USING (warehouse_id = NULLIF(current_setting('app.current_warehouse_id', true), ''));

This means even if a developer forgets to filter by warehouse in a frontend component, PostgreSQL will completely block cross-tenant data leaks.

🌐 Challenge 2: Dynamic Multi-Tenant Subdomains in Next.js 16

wanted every warehouse owner to have their own distinct subdomain (e.g., my-store.lvh.me:3000).

The Solution: Dynamic Rewrite Proxy
Instead of cluttering the system with a heavy middleware.ts, I utilized a specialized server-side proxy.ts execution block in Next.js 16. It dynamically reads the Host header and rewrites paths directly:

export function handleSubdomainRewrite(requestHeaders: Headers) {
  const host = requestHeaders.get('host'); // e.g., 'bodega-x.lvh.me:3000'
  const subdomain = host.split('.')[0];

  // Bypass reserved internal system paths natively
  if (subdomain === 'admin' || subdomain === 'www') {
    return null; 
  }

  // Perform an internal server rewrite to the dynamic store template
  return `/store/${subdomain}`;
}

The Catch: Server-Side Token Security
o prevent identity spoofing, the proxy reads the token cookie (configured with a root domain scope domain=.lvh.me), decodes the JWT payload on the server side, and natively verifies if the token's authorized warehouse matches the requested subdomain. If there is a mismatch, it triggers an immediate rewrite redirect to /no-access.

⏳ Challenge 3: Automated Lock-Out & Subscription Engine

A true SaaS needs to handle monetization and enforcement without blocking access to historical data arbitrarily. I designed a customized multi-state subscription model with an embedded 3-day grace period.

Active State -> [Expiration Date] -> 3-Day Grace Period (Banners) -> Fully Locked POS Screen

The Backend Enforcement Guard
We built a centralized SubscriptionGuard applied globally to all mutable endpoints (POST, PATCH, DELETE) across the products, inventory, and supplier components:

@Injectable()
export class SubscriptionGuard implements CanActivate {
  async canActivate(context: ExecutionContext): Promise<boolean> {
    const req = context.switchToHttp().getRequest();
    const { expiresAt, gracePeriodDays } = req.user; // Appended by auth verification

    const absoluteDeadline = new Date(expiresAt);
    absoluteDeadline.setDate(absoluteDeadline.getDate() + (gracePeriodDays || 3));

    if (new Date() > absoluteDeadline) {
      throw new ForbiddenException('Subscription completely expired. Write operations locked.');
    }
    return true; // GET endpoints remain open cleanly
  }
}

The Frontend Reaction Flow

Within 5 days of expiration: A contextual Amber SubscriptionBanner pops up in the Dashboard.
During Grace Period: An Orange warning stays fixed.
Past Grace Period: A full-screen SubscriptionLock overlay takes over the POS component with a pre-configured WhatsApp manual link (wa.me) leveraging a centralized support module to handle instant payment updates.

📨 Challenge 4: Transactional Communications via Resend & Manual WhatsApp Fallbacks

To ensure smooth operational communication without overhead costs, I implemented a hybrid Dual-Channel Notification System:

1. Channel A (Automated Transacational Mail): A global NotificationsModule hooks into backend services using the Resend SDK. It triggers beautifully designed, dark Neobrutalist HTML templates on critical events:

sendWelcomeEmail: Sends temporary credentials and system subdomain links immediately upon setup.
sendSubscriptionExpiringEmail: Triggered daily at noon via a NestJS @nestjs/schedule CRON job with clean in-memory de-duplication (Set).

Channel B (Manual WhatsApp Flows): For payment tracking, the SuperAdmin dashboard incorporates manual communication helpers that parse tenant states dynamically into contextual text reminders, generating a frictionless single-click chat initiation link.

🧠 Key Takeaways

Building Äbasto proved that your portfolio doesn't need to be an archive of 20 unmaintained projects. Dedicating your space to full-scale engineering breakdowns showcases:

Deep comprehension of DB performance and security models.
Familiarity with server-side network engineering architecture (proxies, domain parsing).
Product mindset implementation (subscription gates, user retention design).

Link: https://portfolio-three-topaz-81.vercel.app/en/projects/abasto

What does your current portfolio project stack look like? Are you team Single-DB isolation or separated clusters? Let's discuss in the comments below!