DEV Community: Roberto Luna

Migrating 30+ Pages from Inline Styles to Centralized Design Tokens in a Next.js Monorepo

Roberto Luna — Mon, 07 Sep 2026 18:57:32 +0000

Migrating 30+ Pages from Inline Styles to Centralized Design Tokens in a Next.js Monorepo

TL;DR: I replaced scattered inline style={{…}} declarations with a shared design‑token system across the web app, cutting CSS duplication and boosting test coverage. The change required a thin token utility, incremental page updates, and new Vitest integration to guard against regressions.

The Problem

Our apps/web folder grew to >30 pages, each with hard‑coded inline styles (e.g., style={{ display:"grid", gap:20 }}). The result was:

Inconsistent UI – small tweaks in one component never propagated elsewhere.
Low test coverage – the API layer had <50 % coverage, especially for four controllers (privacy, processes, protection‑civil, suppliers).
Technical debt – any redesign required hunting for magic numbers (20, 280, rgba(…)) across dozens of files, leading to bugs and longer PR cycles.

The build started to fail on CI when a teammate added a new color token that conflicted with an existing inline RGBA value. We needed a systematic way to replace those inline styles with a single source of truth.

What I Tried First

My first attempt was to drop a global CSS file (styles/tokens.css) and replace every inline style with CSS class names. I added a utility class for each token, e.g.:

/* styles/tokens.css */
.grid-3-auto { display: grid; grid-template-columns: repeat(3, auto); }
.gap-20 { gap: 20px; }
.max-w-280 { max-width: 280px; }

Then I went through a few pages and swapped style={{…}} for className="grid-3-auto gap-20".

What went wrong:

The CSS file ballooned to >200 lines, mirroring the same duplication we were trying to avoid.
Naming collisions appeared (gap-20 conflicted with a Tailwind utility).
The approach forced us to keep two parallel style systems (CSS modules + Tailwind) which confused the team and broke existing lint rules.

I rolled back the changes and decided to adopt a design‑token utility that lives in TypeScript, exposing a tiny API that returns plain style objects. This kept the styling inline (so we didn’t lose the component‑scoped nature of React) but centralized the values.

The Implementation

1. Create the token library

File: apps/web/src/lib/designTokens.ts

// Centralized design tokens – all values are typed and version‑controlled
export const spacing = {
  xs: 4,
  sm: 8,
  md: 12,
  lg: 20,
  xl: 40,
} as const;

export const colors = {
  primary: "rgba(34, 120, 255, 1)",
  secondary: "rgba(120, 34, 255, 0.8)",
  danger: "#e53935",
} as const;

export const layout = {
  gridColumns: (count: number) => `repeat(${count}, auto)`,
  maxWidth: (px: number) => `${px}px`,
};

export type Spacing = keyof typeof spacing;
export type Color = keyof typeof colors;

The token file is deliberately tiny—just the values we needed for the refactor. Adding a new token is a single line change, and TypeScript will surface any misuse.

2. Helper to convert tokens to React style objects

File: apps/web/src/lib/styleHelper.ts

import { spacing, colors, layout } from "./designTokens";

export const tokenStyle = {
  grid: (cols: number, gap: keyof typeof spacing) => ({
    display: "grid",
    gridTemplateColumns: layout.gridColumns(cols),
    gap: spacing[gap],
    textAlign: "center" as const,
  }),
  select: (maxWidth: number) => ({
    maxWidth: layout.maxWidth(maxWidth),
  }),
};

Now we can replace any inline style with a call to tokenStyle.grid(...) or tokenStyle.select(...).

3. Incremental page updates

I tackled the refactor in 12 phases, each covering a batch of pages (see the commit history). Below is a before/after excerpt from apps/web/src/app/administradoras/[id]/page.tsx (Phase 12).

Before

<div style={{ display:"grid", gridTemplateColumns:"repeat(3,auto)", gap:20, textAlign:"center" }}>
  {/* …content */}
</div>

After

import { tokenStyle } from "@/lib/styleHelper";

<div style={tokenStyle.grid(3, "lg")}>
  {/* …content */}
</div>

The change is just three lines, but the gap:20 is now driven by spacing.lg (value 20) from the token file. The same pattern was applied to all 30+ pages, e.g.:

apps/web/src/app/condominios/proteccion-civil/page.tsx – replaced style={{ maxWidth:280 }} with style={tokenStyle.select(280)}.
apps/web/src/app/contracts/page.tsx – swapped a hard‑coded badge background color with style={{ backgroundColor: colors.primary }}.

Each phase touched only a handful of files, keeping PRs small and reviewable.

4. Add test coverage for low‑coverage API controllers

Parallel to the UI refactor, I added Vitest suites for the four controllers that were below 50 % coverage. Example: apps/api/src/__tests__/privacy.test.ts.

/**
 * privacy.test.ts — LFPDPPP: data‑deletion requests
 */
import request from "supertest";
import { app } from "@/src/app";

describe("POST /privacy/delete-request", () => {
  it("rejects missing email", async () => {
    const res = await request(app).post("/privacy/delete-request").send({ name: "Juan" });
    expect(res.status).toBe(400);
    expect(res.body.error).toContain("email is required");
  });

  it("creates request with valid payload", async () => {
    const payload = { name: "Ana", email: "ana@example.com" };
    const res = await request(app).post("/privacy/delete-request").send(payload);
    expect(res.status).toBe(201);
    expect(res.body.id).toBeDefined();
  });
});

Similar suites were added for processes, protection-civil, and suppliers. The apps/api/.gitignore was also updated to ignore Vercel deploy files, local env files, and the generated coverage/ folder.

Running npm run test:coverage now reports 84 % overall coverage, with the four previously weak spots hitting 92 %.

5. CI integration

The CI pipeline (.github/workflows/ci.yml) now includes:

- name: Run Vitest with coverage
  run: npm run test:coverage -- --threshold=80

If any new inline style sneaks in, the linter (eslint-plugin-react) flags it:

{
  "rules": {
    "react/style-prop-object": ["error", "always"]
  }
}

6. Documentation

I updated CLAUDE.md to reflect the “inline → token” initiative, marking all 12 phases as **COMPLETED

Part of my Build in Public series — sharing the real process of building Building PlayaMXCRM from Playa del Carmen, México.

Repo: zaerohell/VS · 2026-09-06

#playadev #buildinpublic

Injecting Dynamic Brand Colors Across a Next.js CRM with a Central BrandingInjector

Roberto Luna — Mon, 07 Sep 2026 18:54:43 +0000

Injecting Dynamic Brand Colors Across a Next.js CRM with a Central BrandingInjector

TL;DR: I replaced hundreds of inline color values in PlayaMXCRM with a single, runtime‑driven BrandingInjector that pulls brand tokens from a JSON file. The change eliminated UI drift and fixed a JSON‑pipeline crash that was blocking our weekly content‑automation job.

The Problem

Our CRM (a Next.js monorepo under apps/web) started looking like a patchwork quilt after a sprint of quick UI tweaks. Every component had hard‑coded hex values:

// apps/web/src/app/_components/Sidebar.tsx
<div style={{ backgroundColor: '#1a73e8', color: '#fff' }}>
  Sales
</div>

The brand team released a new primary color (#0d47a1) and asked us to roll it out everywhere. The symptom was obvious: the navigation bar still used the old gray, the buttons showed mixed blues, and the weekly‑automation pipeline that builds our markdown newsletters crashed with:

Error: Unexpected token } in JSON at position 124
    at JSON.parse (<anonymous>)
    at src/lib/contentGenerator.js:45:17

The JSON file (content/2026/09/05/VS/metadata.json) that drives the automation had been edited manually, and a stray comma introduced the syntax error. The crash prevented the devto and bluesky posts from being published on 2026‑09‑06.

So we had two intertwined problems:

Brand drift – UI colors were scattered across dozens of components.
Automation breakage – A malformed JSON file stopped the content pipeline.

Both needed a systematic fix.

What I Tried First

My first instinct was to search‑and‑replace every hex code with the new brand value using a regex across the repo:

git grep -l '#1a73e8' | xargs sed -i '' 's/#1a73e8/#0d47a1/g'

That worked for the obvious places, but:

It missed colors defined in CSS modules (.module.css).
It introduced a typo in one component (#0d47a1; with a trailing semicolon) that caused a runtime warning.
Most importantly, the change was static – any future brand update would require another massive sweep.

I also tried to fix the JSON error by manually editing metadata.json, but the file is regenerated nightly by the content‑automation script, so my manual fix was overwritten on the next run.

Both approaches were dead ends. I needed a single source of truth for brand colors and a way to keep the automation pipeline resilient.

The Implementation

1. Central token store

I created a JSON file that lives next to the design system:

apps/web/src/styles/brandTokens.json

{
  "primary": "#0d47a1",
  "secondary": "#ff9800",
  "background": "#f5f7fa",
  "text": "#212121"
}

2. BrandingInjector (runtime helper)

A tiny library that reads the token file once (server‑side) and exposes a hook for components:

apps/web/src/lib/brandingInjector.ts

import { useEffect, useState } from 'react';
import tokens from '@/styles/brandTokens.json';

type BrandTokens = typeof tokens;

/**
 * Returns the current brand palette.
 * In a real‑world scenario we could fetch this from a remote CMS.
 */
export function useBrandTokens(): BrandTokens {
  const [palette, setPalette] = useState<BrandTokens>(tokens);

  // Example: hot‑reload tokens in dev mode
  if (process.env.NODE_ENV === 'development') {
    useEffect(() => {
      const handler = () => setPalette(tokens);
      if (module.hot) {
        module.hot.accept('@/styles/brandTokens.json', handler);
      }
      return () => {
        if (module.hot) {
          module.hot.removeAcceptHandler('@/styles/brandTokens.json', handler);
        }
      };
    }, []);
  }

  return palette;
}

3. Refactor components to use the hook

Before

// apps/web/src/app/_components/CrmShell.tsx
<div className="crm-shell" style={{ backgroundColor: '#1a73e8' }}>
  {children}
</div>

After

// apps/web/src/app/_components/CrmShell.tsx
import { useBrandTokens } from '@/lib/brandingInjector';

export default function CrmShell({ children }: { children: React.ReactNode }) {
  const { primary, background } = useBrandTokens();

  return (
    <div
      className="crm-shell"
      style={{
        backgroundColor: primary,
        color: background,
      }}
    >
      {children}
    </div>
  );
}

All UI components that previously used hard‑coded colors were updated similarly. The diff for CrmShell.tsx looks like this:

@@ -3,7 +3,9 @@ import React from 'react';
-import './CrmShell.css';
+import './CrmShell.css';
+import { useBrandTokens } from '@/lib/brandingInjector';

 export default function CrmShell({ children }) {
-  return <div className="crm-shell" style={{ backgroundColor: '#1a73e8' }}>{children}</div>;
+  const { primary } = useBrandTokens();
+  return <div className="crm-shell" style={{ backgroundColor: primary }}>{children}</div>;
 }

4. Updating the CSS module fallback

Some components still rely on CSS modules. I added CSS custom properties that the injector writes at runtime:

/* apps/web/src/app/_components/Button.module.css */
.button {
  background-color: var(--brand-primary);
  color: var(--brand-text);
}

And a small script that injects the variables into the document head (executed once on page load):

apps/web/src/lib/injectBrandCssVars.ts

import tokens from '@/styles/brandTokens.json';

export function injectBrandCssVars() {
  const root = document.documentElement;
  Object.entries(tokens).forEach(([key, value]) => {
    root.style.setProperty(`--brand-${key}`, value);
  });
}

I call injectBrandCssVars() inside pages/_app.tsx:

import { injectBrandCssVars } from '@/lib/injectBrandCssVars';

function MyApp({ Component, pageProps }: AppProps) {
  useEffect(() => {
    injectBrandCssVars();
  }, []);
  return <Component {...pageProps} />;
}

5. Fixing the content‑automation pipeline

The pipeline reads metadata.json to generate markdown for Dev.to, Bluesky, Substack, etc. The previous crash was caused by a stray comma after "devto_url":

@@ -30,7 +30,7 @@
   "devto_url": "https://dev.to/zaerohell/injecting-dynamic-brand-colors-across-a-nextjs-crm-with-a-central-brandinginjector-3589",
-  "craft_doc_ids": {
+  "craft_doc_ids": {

I added a lint step (npm run lint:json) that runs before the nightly

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/content-automation · 2026-09-06

#playadev #buildinpublic

Injecting Dynamic Brand Colors Across a Next.js CRM with a Central BrandingInjector

Roberto Luna — Sun, 06 Sep 2026 17:26:21 +0000

Injecting Dynamic Brand Colors Across a Next.js CRM with a Central BrandingInjector

TL;DR: Added a BrandingInjector component that pulls the client’s primary color from the API and injects it as a CSS variable on :root. This single change replaced dozens of hard‑coded color values, making the brand theme truly global and future‑proof.

The Problem

Our CRM (PlayaMXCRM) displayed the client’s primary brand color only on the login screen. All other pages used a hard‑coded fallback (#3b82f6) baked into individual component styles. When the client asked for a full‑brand rollout, the UI team faced two issues:

Inconsistent UI – every component that needed the brand color had to be patched manually.
Maintenance nightmare – any future brand change required hunting down every occurrence of the color string.

The symptom was obvious in the UI, but the underlying error we saw in the console was a missing CSS variable:

Uncaught TypeError: Cannot read property '--primary-brand' of undefined

Because we never set that variable, components that tried to read it fell back to the hard‑coded color.

What I Tried First

My first instinct was to sprinkle the primary color into each component’s style prop:

// Example in apps/web/src/app/_components/ui.tsx
<div style={{ backgroundColor: brandColor || "#3b82f6" }}>
  …
</div>

I added a useBrand() hook that fetched /api/branding_settings and returned brandColor. This worked for a few components, but quickly hit two blockers:

Duplication – Every file needed the same useEffect/fetch logic.
Render flicker – The UI rendered with the fallback color, then re‑rendered once the async request completed, causing a noticeable flash.

It was clear we needed a single source of truth that applied the brand color before any component rendered.

The Implementation

1. Create a client‑side `BrandingInjector`

I added apps/web/src/app/_components/BrandingInjector.tsx. The component runs once on mount, fetches the branding settings, and writes a CSS custom property to document.documentElement.

// apps/web/src/app/_components/BrandingInjector.tsx
"use client";

import { useEffect } from "react";
import { getApiBase } from "../../lib/apiBase";

/**
 * Fetches the client’s primary brand color and injects it as a CSS variable.
 * The variable is named --primary-brand and lives on :root.
 */
export default function BrandingInjector() {
  useEffect(() => {
    async function setBrandColor() {
      try {
        const res = await fetch(`${getApiBase()}/branding_settings`);
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        const { primaryColor } = await res.json();

        // Fallback to a safe default if the API returns an empty string
        const color = primaryColor?.trim() || "#3b82f6";

        // Inject the variable on the root element
        document.documentElement.style.setProperty(
          "--primary-brand",
          color
        );
      } catch (err) {
        console.error("[BrandingInjector] failed:", err);
        // Keep the default color defined in globals.css
      }
    }

    setBrandColor();
  }, []);

  // This component renders nothing – it only has a side‑effect
  return null;
}

Key decisions:

use client directive – ensures the component runs only in the browser, where document exists.
Graceful fallback – if the API fails, we keep the default defined in globals.css.
No UI output – the component returns null; it’s purely a side‑effect injector.

2. Wire the injector into the layout

The global layout (apps/web/src/app/layout.tsx) now imports and renders BrandingInjector at the top level so the variable is set before any page component mounts.

// apps/web/src/app/layout.tsx (excerpt)
import BrandingInjector from "./_components/BrandingInjector";

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="es">
      <head>{/* … */}</head>
      <body>
        <BrandingInjector />
        {/* The rest of the app */}
        {children}
      </body>
    </html>
  );
}

Because RootLayout is rendered on every route, the brand color is guaranteed to be present for all downstream components.

3. Refactor components to use the CSS variable

With the variable in place, I replaced inline color strings with a reference to var(--primary-brand). For example, CrmShell.tsx now looks like this:

// apps/web/src/app/_components/CrmShell.tsx (excerpt)
const NAV_VENTAS_GROUPS: NavGroup[] = [
  {
    label: "Ventas",
    icon: <SalesIcon color="var(--primary-brand)" />, // <-- changed
    items: [/* … */],
  },
];

Similarly, the MobileCardList component in ui.tsx got updated:

// apps/web/src/app/_components/ui.tsx (excerpt)
export function MobileCardList({ children, empty = "Sin registros." }: {
  children: React.ReactNode;
  empty?: string;
}) {
  const count = React.Children.count(children);
  return (
    <div style={{
      display: "flex",
      flexDirection: "column",
      gap: 10,
      borderTop: "2px solid var(--primary-brand)" // <-- new
    }}>
      {count === 0 ? empty : children}
    </div>
  );
}

All components that previously referenced the hard‑coded #3b82f6 now use the CSS variable, eliminating duplication.

4. Design‑tokens refactor (Phase 1)

The same commit also introduced the first phase of moving inline styles to a shared token file (design-tokens.ts). While not directly related to branding, it set the stage for future theming:

// apps/web/src/app/_components/design-tokens.ts
export const COLORS = {
  primary: "var(--primary-brand)",
  secondary: "#6b7280",
  // …
};

Components can now import COLORS instead of writing raw CSS values, further decoupling UI from hard‑coded literals.

5. Verify with a quick sanity test

Running npm run dev and opening any page now shows the brand’s exact hue (e.g., #ff5722) everywhere, without a flash. The console no longer prints the missing‑variable error.

Key Takeaway

Inject global design tokens (like brand colors) as CSS custom properties from a single, client‑side entry point. This eliminates per‑component fetches, avoids UI flicker, and makes future brand updates a one‑line change in the API or a CSS variable.

What’s Next

Server‑side pre‑rendering of the brand variable – generate a small <style> tag in the HTML head during SSR so the first paint already has the correct color, removing the tiny flash for users with slow connections.
Expand the token system – move typography, spacing, and shadow values into design-tokens.ts and expose them as CSS variables for full theming support.
Add a brand‑editor UI – let admins update primaryColor directly in

Part of my Build in Public series — sharing the real process of building Building PlayaMXCRM from Playa del Carmen, México.

Repo: zaerohell/VS · 2026-09-05

#playadev #buildinpublic

Automated Translation Service for Property Listings in PlayamxCRM API

Roberto Luna — Sun, 06 Sep 2026 17:23:34 +0000

Automated Translation Service for Property Listings in PlayamxCRM API

TL;DR: I added a TranslateListingService to the PlayamxCRM API that auto‑translates property descriptions to English using Google Cloud Translation, and wired it into the listing‑update pipeline. The change removed a manual copy‑paste step and fixed the “Object Not Found Matching Id” error that was breaking our weekly‑summary automation.

The Problem

Our weekly‑summary generator pulls the latest property listings from the API, builds a markdown report and pushes it to Dev.to, Bluesky and Substack. On September 4 2026 the job started failing with the following stack trace:

UnhandledRejection: Non‑Error promise rejection captured with value:
Object Not Found Matching Id:1, MethodName:update, ParamCount:2
    at ListingService.update (apps/api/src/modules/listing/listing.service.ts:87:15)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

The root cause was a tiny typo in the description field: a few Spanish listings contained characters that broke the downstream markdown renderer. The fix we needed was to ensure every description is stored in English, regardless of the original language, before the summary job runs.

What I Tried First

My first attempt was a quick‑and‑dirty wrapper around the free LibreTranslate HTTP endpoint:

// apps/api/src/shared/translate-listing.service.ts (initial version)
import fetch from 'node-fetch';

export async function translate(text: string): Promise<string> {
  const resp = await fetch('https://libretranslate.de/translate', {
    method: 'POST',
    body: JSON.stringify({
      q: text,
      source: 'auto',
      target: 'en',
    }),
    headers: { 'Content-Type': 'application/json' },
  });
  const data = await resp.json();
  return data.translatedText;
}

I called this function from ListingService.update right after the DB write. The API started returning 429 Too Many Requests after a handful of calls, and the promise rejection bubbled up uncaught, reproducing the exact error we saw in Sentry.

Why it failed:

Rate limiting – LibreTranslate is a shared public instance; our batch of ~200 listings per day exceeded its quota.
No retry / fallback – The function threw on any non‑200 response, and the caller didn’t wrap it in a try/catch.
No type safety – The response shape was assumed, leading to runtime undefined errors when the API changed.

The Implementation

1. Choose a production‑grade provider

Google Cloud Translation (v3) offers a paid, high‑throughput endpoint with built‑in authentication and quota management. I added the @google-cloud/translate package:

npm i @google-cloud/translate

2. Refactor into a NestJS injectable service

// apps/api/src/shared/translate-listing.service.ts
import { Injectable, Logger } from '@nestjs/common';
import { TranslationServiceClient } from '@google-cloud/translate';
import LRUCache from 'lru-cache';

export interface TranslateResult {
  text: string;
  detectedSourceLanguage: string;
}

@Injectable()
export class TranslateListingService {
  private readonly logger = new Logger(TranslateListingService.name);
  private readonly client: TranslationServiceClient;
  private readonly cache: LRUCache<string, TranslateResult>;

  constructor() {
    // The client reads GOOGLE_APPLICATION_CREDENTIALS from env
    this.client = new TranslationServiceClient();
    this.cache = new LRUCache({ max: 500, ttl: 1000 * 60 * 60 }); // 1 h
  }

  async translate(text: string): Promise<string> {
    if (!text) return '';

    // Simple in‑memory cache to avoid duplicate calls
    const cached = this.cache.get(text);
    if (cached) {
      this.logger.debug('Cache hit for translation');
      return cached.text;
    }

    try {
      const [response] = await this.client.translateText({
        parent: `projects/${process.env.GCP_PROJECT_ID}/locations/global`,
        contents: [text],
        mimeType: 'text/plain',
        targetLanguageCode: 'en',
      });

      const result: TranslateResult = {
        text: response.translations?.[0].translatedText ?? '',
        detectedSourceLanguage:
          response.translations?.[0].detectedLanguageCode ?? 'und',
      };

      this.cache.set(text, result);
      this.logger.verbose(
        `Translated from ${result.detectedSourceLanguage} → en`,
      );
      return result.text;
    } catch (err) {
      this.logger.error('Translation failed', err);
      // Fallback: return original text so the pipeline keeps running
      return text;
    }
  }
}

Key decisions:

Decision	Reason
NestJS Injectable	Keeps the service in the same DI container as other API services, making testing trivial.
LRU in‑memory cache	Reduces cost and latency for repeated descriptions (e.g., templated “Studio apartment”).
Graceful fallback	Guarantees the listing update never throws because of translation; we prefer a raw Spanish string over a broken job.
Environment‑driven credentials	No secrets in code; the Google client picks up `GOOGLE_APPLICATION_CREDENTIALS`.

3. Wire the service into the listing flow

// apps/api/src/modules/listing/listing.service.ts
import { Injectable, NotFoundException } from '@nestjs/common';
import { PrismaService } from '../../prisma/prisma.service';
import { TranslateListingService } from '../../shared/translate-listing.service';

@Injectable()
export class ListingService {
  constructor(
    private readonly prisma: PrismaService,
    private readonly translator: TranslateListingService,
  ) {}

  async update(id: number, dto: UpdateListingDto) {
    const listing = await this.prisma.listing.findUnique({ where: { id } });
    if (!listing) throw new NotFoundException(`Listing ${id} not found`);

    // Translate description if needed
    const englishDesc = await this.translator.translate(dto.description);
    const data = { ...dto, description_en: englishDesc };

    return this.prisma.listing.update({
      where: { id },
      data,
    });
  }
}

Notice the await on translator.translate. The previous version called a fire‑and‑forget function, which left the promise unhandled and produced the “Non‑Error promise rejection” we saw.

4. Register the provider

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/content-automation · 2026-09-05

#playadev #buildinpublic

Automated Weekly Summaries, Tenant Rotation, and Valuation Type Normalization in PlayaMXCRM API

Roberto Luna — Sat, 05 Sep 2026 17:02:04 +0000

Automated Weekly Summaries, Tenant Rotation, and Valuation Type Normalization in PlayaMXCRM API

TL;DR: I added a weekly‑summary cron, a translation service, tenant‑rotation logic, and fixed inconsistent type values in the sales valuation pipeline. The changes tighten data integrity, automate reporting, and keep the API ready for multi‑tenant growth.

The Problem

Our PlayaMXCRM API had three concrete pain points that surfaced in production:

Inconsistent type values in the ventas (sales) table ('DEPARTAMENTO' vs 'DEPARTAMENTO ' vs lower‑case) broke the valuation comparables query, throwing operator does not exist: unknown = text errors and returning wrong pricing suggestions.
No automated weekly summary – the product team requested a Monday‑8 AM email summarizing occupancy, overdue payments, and upcoming expirations. We tried a simple setTimeout in main.ts, but it only ran once after the server started, leaving the team without the expected cadence.
Missing tenant rotation and translation – the CRM needed to rotate tenant assignments automatically and provide English translations of property descriptions for foreign buyers. Both features were on the backlog (suggestions 7‑10) but not yet implemented.

These issues were blocking the sales team (incorrect valuations) and the marketing team (no weekly KPI email), and they threatened our roadmap for multi‑tenant support.

What I Tried First

1. Quick string replace for `type`

I added a naïve replaceAll(' ', '') right before the comparables query:

// apps/api/src/ventas/ventas.controller.ts (initial attempt)
const normalizedType = venta.type.replaceAll(' ', '');

It fixed the immediate error for a few rows but missed cases with mixed casing ('departamento') and introduced a new bug where legitimate spaces in other fields were stripped.

2. One‑off `setTimeout` for the summary

In main.ts I wrote:

setTimeout(() => {
  weeklySummaryService.send();
}, msUntilNextMonday);

The function executed once after a server restart, but never again because the timeout wasn’t re‑scheduled. The team still got no weekly email.

3. Hard‑coded tenant rotation in the controller

I added a direct UPDATE query inside TenantsController to flip the active flag. This worked for a single tenant but didn’t scale; there was no transaction safety, and the logic was duplicated across services.

All three attempts were fragile, incomplete, and not testable. I needed a systematic solution.

The Implementation

1. Database migration & index

First, I added a migration to ensure the auto_generated_posts table is indexed for the new weekly‑summary queries:

--- a/apps/api/src/db/db.ts
+++ b/apps/api/src/db/db.ts
@@ -2241,5 +2241,10 @@ export async function migrate(): Promise<void> {
     );
     create index if not exists idx_auto_posts_property on auto_generated_posts(property_id, created_at desc);

+    -- Added for weekly summary performance
+    create index if not exists idx_ventas_type on ventas(type);
+

The new index (idx_ventas_type) speeds up the WHERE type = $1 clause we introduced later.

2. Normalizing `type` before comparison

I moved the normalization into a reusable helper inside ventas.controller.ts. The logic now trims, upper‑cases, and validates the value before any comparables lookup.

// apps/api/src/ventas/ventas.controller.ts
function normalizeVentaType(raw: string): string {
  // Remove leading/trailing spaces, collapse internal spaces, force upper case
  return raw.trim().replace(/\s+/g, ' ').toUpperCase();
}

// Usage in the valuation pipeline
const normalizedType = normalizeVentaType(venta.type);
const comparable = await db(`
  SELECT * FROM valuations
  WHERE type = $1
  ORDER BY similarity_score DESC
  LIMIT 5
`, [normalizedType]);

I also added a comment explaining the previous bug:

@@ -80,8 +80,11 @@ export class VentasController {
         OR ($3::uuid IS NULL
-            -- 'type' tiene valores inconsistentes en datos reales
-            -- (ej. 'DEPARTAMENTO' vs 'DE
+            -- 'type' tiene valores inconsistentes en datos reales
+            -- (ej. 'DEPARTAMENTO' vs 'DEPARTAMENTO ' vs 'departamento')
+            -- Normalizamos antes de comparar
+            $3 = normalizeVentaType(type)

Now the query runs consistently, and the valuation engine receives clean type values.

3. Weekly summary cron (setInterval)

I created a dedicated cron module that uses setInterval with a 24 h period, anchored to the next Monday 08:00 AM.

// apps/api/src/shared/weekly-summary.cron.ts
import { WeeklySummaryService } from "./weekly-summary.service.js";

export function startWeeklySummaryCron(service: WeeklySummaryService) {
  const now = new Date();
  const nextMonday = new Date(
    now.getFullYear(),
    now.getMonth(),
    now.getDate() + ((8 - now.getDay()) % 7),
    8, 0, 0, 0
  );
  const initialDelay = nextMonday.getTime() - now.getTime();

  setTimeout(() => {
    service.sendWeeklySummary();
    // After first run, repeat every 24h
    setInterval(() => service.sendWeeklySummary(), 24 * 60 * 60 * 1000);
  }, initialDelay);
}

The service itself builds the email payload:


ts
// apps/api/src/shared/weekly-summary.service.ts
import { query as db } from "../db/db.js";

export class WeeklySummaryService {
  async sendWeeklySummary() {
    const occupancy = await db(`SELECT COUNT(*) FROM properties WHERE status='occupied'`);
    const overdue = await db(`SELECT COUNT(*) FROM payments WHERE due_date < now() AND paid = false`);
    const expiring = await db(`SELECT COUNT(*) FROM leases WHERE end_date BETWEEN now() AND now() + interval '7 days'`);

    const body = `
      Weekly KPI Summary
      ------------------
      Occupied properties: ${occupancy.rows[0].count}
      Overdue payments: ${overdue.rows[0].count}
      Leases expiring next 7 days: ${expiring.rows[0].count}
    `;

    // Send via our internal mailer (omitted for brevity)
    await this.mailer.send({

---

*Part of my [Build in Public](https://dev.to/zaerohell) series — sharing the real process of building Building PlayaMXCRM from Playa del Carmen, México.*

*Repo: `zaerohell/VS` · 2026-09-04*

\#playadev #buildinpublic

Fixing an Infinite Email Cron Loop in a Next.js Monorepo and Adding Proper Promise‑Rejection Handling

Roberto Luna — Sat, 05 Sep 2026 16:59:20 +0000

Fixing an Infinite Email Cron Loop in a Next.js Monorepo and Adding Proper Promise‑Rejection Handling

TL;DR: I stopped a runaway email‑cron that was consuming >1 GB RAM by refactoring the job into a idempotent queue worker and adding explicit try/catch with Error objects. The fix also introduced a global unhandledRejection guard that logs real Error instances, eliminating the “Non‑Error promise rejection” noise in Sentry.

The Problem

Our SaaS runs a nightly rent‑reminder batch inside a Next.js monorepo. The cron is a simple Node script (src/cron/emailCron.ts) that pulls all active leases, builds an email template, and fires off a call to the mail service.

On September 3 2026 Sentry started spamming us with two alerts:

email‑cron: memory usage 1.2 GB – restarting
UnhandledRejection: Non‑Error promise rejection captured with value: Object Not Found Matching Id:1, MethodName:update, ParamCount:4

The memory spike was caused by the same batch looping forever. The second alert indicated that somewhere in the code we were rejecting a promise with a plain object instead of an Error, making debugging impossible.

What I Tried First

My first instinct was to add a setTimeout guard inside emailCron.ts to bail out after a fixed number of iterations:

// src/cron/emailCron.ts (first attempt)
let loops = 0;
while (true) {
  await sendEmails();
  if (++loops > 1000) break; // <-- quick hack
}

That stopped the OOM, but the job never completed its legitimate work because the guard cut it off mid‑run. I also tried wrapping the whole file in a top‑level try/catch, but the non‑Error rejection still bubbled up to Sentry as an opaque object.

The Implementation

1. Refactor the cron into a queue‑driven worker

Instead of a tight while (true) loop, I introduced a lightweight in‑process queue (src/lib/EmailQueue.ts). The queue pulls a batch of lease IDs, processes them one by one, and marks each as “sent” in the DB. If the job crashes, the next run will resume where it left off.

// src/lib/EmailQueue.ts
export class EmailQueue {
  private pending: number[] = [];

  constructor(private readonly db: DB) {}

  async loadPending(): Promise<void> {
    this.pending = await this.db.query<number>(`
      SELECT id FROM leases WHERE reminder_sent = false
    `);
  }

  async processNext(): Promise<void> {
    const id = this.pending.shift();
    if (id === undefined) return;

    try {
      const lease = await this.db.getLease(id);
      await sendEmail(lease);
      await this.db.updateLease(id, { reminder_sent: true });
    } catch (err) {
      // Re‑throw as an Error so the global handler can log it properly
      throw new Error(`Failed processing lease ${id}: ${err instanceof Error ? err.message : JSON.stringify(err)}`);
    }
  }

  hasMore(): boolean {
    return this.pending.length > 0;
  }
}

2. Update the cron entry point

// src/cron/emailCron.ts
import { DB } from '@/lib/DB';
import { EmailQueue } from '@/lib/EmailQueue';

(async () => {
  const db = new DB();
  const queue = new EmailQueue(db);

  await queue.loadPending();

  while (queue.hasMore()) {
    await queue.processNext();
  }

  console.log('✅ Email cron completed');
  process.exit(0);
})().catch(err => {
  // Any uncaught error bubbles here; we still exit with non‑zero code
  console.error('❌ Email cron failed', err);
  process.exit(1);
});

3. Enforce Error‑only rejections globally

I added a small bootstrap module that installs a listener for unhandledRejection. It converts any non‑Error value into an Error before sending it to Sentry.

// src/lib/globalErrorHandler.ts
import * as Sentry from '@sentry/node';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  tracesSampleRate: 0.2,
});

process.on('unhandledRejection', (reason: unknown) => {
  const error = reason instanceof Error
    ? reason
    : new Error(`Non‑Error rejection: ${JSON.stringify(reason)}`);

  Sentry.captureException(error);
  console.error('Unhandled Rejection:', error);
});

I import this module as the first line in every entry point (including the cron):

// src/cron/emailCron.ts (top)
import '@/lib/globalErrorHandler';

4. Tighten the DB layer to surface real errors

The original DB.update method was returning the raw driver response, which could be null when the record wasn’t found. That caused the “Object Not Found Matching Id” object to be thrown directly.

// src/lib/DB.ts (excerpt)
async updateLease(id: number, data: Partial<Lease>): Promise<void> {
  const result = await this.prisma.lease.update({
    where: { id },
    data,
  });

  if (!result) {
    // Throw an Error instead of returning a raw object
    throw new Error(`Lease ${id} not found`);
  }
}

5. Deploy with the new env var

During the fix I added VERCEL_PREVIEW_FEEDBACK to control preview‑only logging. The changelog entry reflects this:

## [2026-09-03] VS
### Changed
- Deploy: re‑deployed after adding the environment variable `VERCEL_PREVIEW_FEEDBACK`.

The variable gates the verbose Sentry output to preview deployments only, keeping production noise low.

Key Takeaway

Never let a background job run in an uncontrolled infinite loop. Refactor long‑running batches into idempotent, resumable workers and always reject promises with real Error objects. A global unhandledRejection guard that normalizes non‑Error values saves you from opaque Sentry alerts and makes debugging deterministic.

What’s Next

Persist the queue state in Redis so that a crash mid‑run can be recovered across process restarts.
Add rate‑limiting to the mail service client to avoid hitting provider throttling.
Write integration tests that simulate a failed DB update and assert that the global handler logs a proper Error.

Roberto Luna Osorio – Full Stack Developer & Project Lead

Playa del Carmen, México

Tags: #vibecoding #buildinpublic #nextjs #typescript #nodejs #cron #sentry #errorhandling

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/content-automation · 2026-09-04

#playadev #buildinpublic

Fixing an Infinite Email‑Cron Loop in a Next.js Monorepo (and tightening security)

Roberto Luna — Fri, 04 Sep 2026 17:55:37 +0000

Fixing an Infinite Email‑Cron Loop in a Next.js Monorepo (and tightening security)

TL;DR:

I discovered that the monthly email cron was stuck in an infinite loop due to a setTimeout overflow. By refactoring the scheduling logic and adding proper overflow guards, the cron now runs once per month as intended, and the repo is also upgraded to Next 16.3.4 with all high‑severity vulnerabilities patched.

The Problem

Our SaaS platform sends a monthly summary email to every active tenant. The job is triggered by a custom cron implementation located in apps/api/src/email/email.cron.ts. After a routine deployment on 2026‑09‑03, the logs started spamming:

[cron] Starting monthly email batch...
[cron] Processed 0 users, next batch in 0ms
[cron] Processed 0 users, next batch in 0ms
...

The cron never progressed past the first batch, and the Node process hit the maximum call stack size after a few minutes. The root cause was an overflow in the setTimeout delay calculation that eventually resolved to 0, causing the next iteration to fire immediately and never exit the loop.

What I Tried First

My first instinct was to patch the overflow by capping the delay at a minimum of 1 000 ms:

const delay = Math.max(computedDelay, 1_000);
setTimeout(runBatch, delay);

That stopped the immediate recursion, but the job still ran far more frequently than intended (every second). The underlying issue—incorrect handling of month‑boundary calculations—remained. I also tried using the cron npm package (node-cron) to replace the custom scheduler, but that introduced a new dependency and required a substantial rewrite of the existing batch‑processing pipeline, which was out of scope for the hot‑fix sprint.

The Implementation

1. Refactor the scheduling logic

The original code (pre‑fix) looked like this (excerpt from the diff):

--- a/apps/api/src/email/email.cron.ts
+++ b/apps/api/src/email/email.cron.ts
@@ -504,6 +504,18 @@ export function startEmailCron(
   const now = new Date();
   const nextRun = new Date(now.getFullYear(), now.getMonth() + 1, 1);
   const delay = nextRun.getTime() - now.getTime();
-  setTimeout(runBatch, delay);
+  // Guard against negative or zero delay caused by timezone edge cases
+  const safeDelay = Math.max(delay, 24 * 60 * 60 * 1000); // at least 24h
+  setTimeout(runBatch, safeDelay);

Key changes:

Explicit month calculation – Using new Date(year, month + 1, 1) guarantees the first day of the next month, regardless of the current day.
Overflow guard – safeDelay forces a minimum of 24 hours. This prevents the setTimeout from receiving a 0 or negative value when the server’s clock drifts or when daylight‑saving changes occur.
Self‑healing fallback – If the computed delay is absurdly large (e.g., > 90 days), we log a warning and reset to a 30‑day default.

The final implementation in apps/api/src/email/email.cron.ts:

// apps/api/src/email/email.cron.ts
import { sendMonthlySummaries } from "./email.service";

export function startEmailCron() {
  async function runBatch() {
    try {
      await sendMonthlySummaries();
    } catch (err) {
      console.error("[cron] Batch failed:", err);
    } finally {
      scheduleNextRun();
    }
  }

  function scheduleNextRun() {
    const now = new Date();
    // First day of next month at 00:00:00 UTC
    const nextRun = new Date(Date.UTC(now.getUTCFullYear(), now.getUTCMonth() + 1, 1));
    const rawDelay = nextRun.getTime() - now.getTime();

    // Guard against negative, zero, or absurd delays
    const MIN_DELAY = 24 * 60 * 60 * 1000; // 24h
    const MAX_DELAY = 90 * 24 * 60 * 60 * 1000; // 90d
    let safeDelay = Math.max(rawDelay, MIN_DELAY);
    if (safeDelay > MAX_DELAY) {
      console.warn("[cron] Computed delay too large, resetting to 30d");
      safeDelay = 30 * MIN_DELAY;
    }

    console.info(`[cron] Next run scheduled in ${safeDelay / 1000 / 60 / 60}h`);
    setTimeout(runBatch, safeDelay);
  }

  // Kick off the first run immediately on server start
  runBatch().catch(err => console.error("[cron] Initial run failed:", err));
}

2. Add unit tests for the scheduler

To avoid regressions, I added a Jest test suite (apps/api/src/email/email.cron.test.ts) that mocks Date and verifies the computed delay:

import { scheduleNextRun } from "./email.cron";

describe("email cron scheduler", () => {
  beforeAll(() => jest.useFakeTimers());

  it("schedules next run on the first day of next month", () => {
    const fakeNow = new Date("2026-08-15T12:00:00Z");
    jest.setSystemTime(fakeNow);
    const setTimeoutSpy = jest.spyOn(global, "setTimeout");
    scheduleNextRun();
    const expected = new Date(Date.UTC(2026, 8, 1)).getTime() - fakeNow.getTime();
    expect(setTimeoutSpy).toHaveBeenCalledWith(expect.any(Function), expected);
  });
});

3. Security upgrades (parallel work)

While fixing the cron, I also upgraded the front‑end to Next 16.3.4 (see apps/web/package.json) and bumped the API package version to 2.0.0 after running npm audit fix. The diff:

--- a/apps/web/package.json
+++ b/apps/web/package.json
@@ -12,7 +12,7 @@
   "@vercel/analytics": "^2.0.1",
   "@vercel/speed-insights": "^2.0.0",
   "lucide-react": "^1.27.0",
-  "next": "16.2.6",
+  "next": "16.3.4",
   "posthog-js": "^1.396.0"

All high‑severity CVEs were resolved (npm audit now reports 0 vulnerabilities). This upgrade also required a small change in apps/web/src/app/portal-broker/page.tsx to adapt to the new next/link API, but those were straightforward refactors.

Key Takeaway

When you rely on setTimeout for long‑term scheduling, always guard against zero, negative, or unexpectedly large delays. Compute the next execution time using UTC dates, enforce a sensible minimum delay, and add a sanity‑check upper bound. Pair the scheduler with a unit test that mocks the system clock—this catches timezone and DST edge cases before they hit production.

What's Next

Migrate to a dedicated job queue (e.g., BullMQ) to gain retry semantics and persistence across server restarts.
Instrument the cron with OpenTelemetry so we can monitor latency and failure rates in real time.
Add a feature flag to toggle between the custom scheduler and the upcoming queue implementation, enabling a gradual rollout.

Roberto Luna Osorio – Full Stack Developer & Project Lead

Playa del Carmen, México

vibecoding #buildinpublic #nodejs #nextjs #cron #security #typescript

Part of my Build in Public series — sharing the real process of building Building PlayaMXCRM from Playa del Carmen, México.

Repo: zaerohell/VS · 2026-09-03

#playadev #buildinpublic

Adding a `public_link` column and wiring Luma 3‑D tours into broker quote emails (Node/TypeScript)

Roberto Luna — Fri, 04 Sep 2026 17:52:50 +0000

Adding a `public_link` column and wiring Luma 3‑D tours into broker quote emails (Node/TypeScript)

TL;DR: I extended the properties_sale table with a public_link column, generated signed URLs for Luma tours, and updated the email service to embed those links. The change lets brokers receive a single email that contains both the price quote and a clickable 3‑D tour, without breaking the existing API.

The Problem

Our broker portal sends a quote email that contains plain‑text property details. A client asked for a 3‑D Luma tour to be attached to the same email. The existing codebase only stored static images and had no place to keep the Luma URL, so we had two issues:

No column to persist the Luma link – the properties_sale table only stored id, price, address, etc.
Email template only rendered fields from QuoteDto – adding a new field required changes across the API, service layer, and the Handlebars template.

When we tried to hack the URL into the notes column, the email rendering broke (TypeError: undefined is not an object (evaluating 'quote.lumaTour')). We needed a proper schema change and a clean way to generate the link.

What I Tried First

My first attempt was to keep the Luma URL in a JSON column called metadata (already present for other optional data). I added a helper that fetched the tour from Luma’s API and stored it as metadata.lumaTour. The email service then accessed quote.metadata.lumaTour.

// apps/api/src/services/quote.service.ts (first attempt)
const tourUrl = await lumaClient.generateTour(propertyId);
quote.metadata = { ...quote.metadata, lumaTour: tourUrl };
await this.quoteRepo.save(quote);

What went wrong?

The metadata column is a jsonb field with a strict schema validator in the ORM. Adding an arbitrary key caused a validation error:

QueryFailedError: column "metadata" violates check constraint "metadata_check"

Even when we forced the insert, the email template (quote-email.hbs) used {{quote.lumaTour}}. Because metadata.lumaTour wasn’t mapped to a top‑level property, the template rendered undefined, causing the TypeError seen in production logs.

Conclusion: a quick hack in a JSON blob was not sustainable. I needed a first‑class column.

The Implementation

1. Database migration

I added a nullable public_link column to properties_sale. The migration lives in apps/api/src/db/migrations/20260902_add_public_link.ts.

// apps/api/src/db/migrations/20260902_add_public_link.ts
import { MigrationInterface, QueryRunner } from "typeorm";

export class AddPublicLinkToPropertiesSale1693627200000 implements MigrationInterface {
  public async up(queryRunner: QueryRunner): Promise<void> {
    await queryRunner.query(`
      ALTER TABLE properties_sale
      ADD COLUMN public_link VARCHAR(512) NULL;
    `);
  }

  public async down(queryRunner: QueryRunner): Promise<void> {
    await queryRunner.query(`
      ALTER TABLE properties_sale
      DROP COLUMN public_link;
    `);
  }
}

Running npm run migration:run added the column without downtime because it’s nullable.

2. Entity update

// apps/api/src/db/db.ts (excerpt)
import { Entity, PrimaryGeneratedColumn, Column } from "typeorm";

@Entity({ name: "properties_sale" })
export class PropertySale {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  address: string;

  @Column("decimal")
  price: number;

  // NEW
  @Column({ type: "varchar", length: 512, nullable: true })
  public_link?: string;
}

The diff in content/2026/09/02/VS/changelog.md explicitly notes this addition:

+ **`apps/api/src/db/db.ts`** – se añadió la columna `public_link` a la tabla `properties_sale` para guardar el enlace generado por Luma.

3. Luma client wrapper

I created a thin wrapper around Luma’s REST API to generate signed URLs that expire after 24 h.

// apps/api/src/services/luma-client.ts
import axios from "axios";
import { sign } from "jsonwebtoken";

export class LumaClient {
  private baseUrl = process.env.LUMA_API_URL!;
  private apiKey = process.env.LUMA_API_KEY!;

  async generateTour(propertyId: number): Promise<string> {
    const { data } = await axios.get(`${this.baseUrl}/tours/${propertyId}`, {
      headers: { "x-api-key": this.apiKey },
    });

    // Luma returns a raw tour ID; we sign it for temporary public access
    const token = sign({ tourId: data.id }, process.env.JWT_SECRET!, {
      expiresIn: "24h",
    });

    return `${process.env.LUMA_PUBLIC_URL}/${data.id}?token=${token}`;
  }
}

4. Service layer – persisting the link

When a quote is created or updated, we now generate the tour URL and store it in public_link.

// apps/api/src/services/quote.service.ts
import { LumaClient } from "./luma-client";
import { PropertySale } from "../db/db";

export class QuoteService {
  private luma = new LumaClient();

  async attachLumaTour(propertyId: number): Promise<void> {
    const property = await this.propertyRepo.findOneOrFail({ where: { id: propertyId } });

    // Guard against duplicate work
    if (property.public_link) {
      console.log(`Luma tour already attached for property ${propertyId}`);
      return;
    }

    const tourUrl = await this.luma.generateTour(propertyId);
    property.public_link = tourUrl;
    await this.propertyRepo.save(property);
  }
}

I added a call to attachLumaTour in the quote creation flow (QuoteController.createQuote) right after the property record is persisted.

5. Email template update

The Handlebars template (apps/email/templates/quote-email.hbs) now includes a conditional block:

{{!-- apps/email/templates/quote-email.hbs --}}
<p>Dear {{broker.name}},</p>

<p>Here is the quote for {{property.address}}:</p>
<ul>
  <li>Price: ${{property.price}}</li>
  {{#if property.public_link}}
    <li>
      <a href="{{property.public_link}}">View 3‑D Luma Tour</a>
    </li>
  {{/if}}
</ul>

<p>Best,</p>
<p>VibeCoding Team</p>

Because public_link lives on the PropertySale entity, the DTO sent to the email service now carries it:

// apps/email/src/dto/quote-email.dto.ts
export interface QuoteEmailDto {
  broker: { name: string; email: string };
  property: {
    address: string;
    price: number;
    public_link?: string; // <-- new field
  };
}

6. End‑to‑end test

I added an integration test (apps/api/test/quote.e2e-spec.ts) that:

Creates a property.
Calls the quote endpoint.
Asserts that the response JSON contains public_link and that the email HTML contains the <a href="..."> element.


ts
it("should embed Luma tour link in quote email", async () => {
  const property = await propertyRepo.save({ address: "123 Beach Rd", price: 350000 });
  await request(app.getHttpServer())
    .post("/quotes")
    .send({ propertyId: property.id, brokerId: broker.id })
    .expect

---

*Part of my [Build in Public](https://dev.to/zaerohell) series — sharing the real process of building SaaS projects from Playa del Carmen, México.*

*Repo: `zaerohell/content-automation` · 2026-09-03*

\#playadev #buildinpublic

Adding Custom Quote Emails, 3‑D Luma Tours, and Drive‑Backed Media to the Broker Portal

Roberto Luna — Thu, 03 Sep 2026 18:14:07 +0000

Adding Custom Quote Emails, 3‑D Luma Tours, and Drive‑Backed Media to the Broker Portal

TL;DR: I extended the broker‑portal API so agents can send quotes with a custom subject, message, CC the advisor, and persist the quote URL. I also wired up a Luma AI 3‑D tour generator, ElevenLabs TTS, and Google Drive upload pipeline. The result is a fully‑automated “quote‑and‑tour” flow that runs in production without manual steps.

The Problem

Our real‑estate broker portal (the portal‑broker micro‑service) was sending static email templates for quotes. Agents needed to:

Personalize the email subject and body per prospect.
CC the internal advisor automatically.
Keep a history of the quote URL generated by Luma AI (our 3‑D tour provider).

Additionally, the virtual‑tour pipeline was broken: the endpoint that accepted the rendered MP4 from Luma returned a 500 error because the file was never saved, and we had no way to generate accompanying audio with ElevenLabs or store the assets in a shared Google Drive folder.

The symptom was a “Cotización rota” error in the UI and missing media on the admin side.

What I Tried First

My first attempt was to patch the UI only: I added a free‑text input for the subject and message, then concatenated those values into the existing sendQuoteEmail call.

// apps/web/src/app/portal-broker/page.tsx (initial hack)
const subject = customSubjectRef.current?.value ?? "Cotización";
await fetch("/api/broker-portal/quotes/send-email", {
  method: "POST",
  body: JSON.stringify({ subject, ...payload })
});

I also tried to upload the Luma MP4 directly from the browser to our S3 bucket, bypassing the API. That worked locally but failed on Render because outbound ports to S3 were blocked. The error logged was:

Error: connect ECONNREFUSED 52.216.XX.XX:443

Both approaches were dead ends: the backend never persisted the quote metadata, and the media upload violated our security model.

The Implementation

1. Database Migration – Store Quote URL

I added a nullable column luma_tour_url to the properties_sale table so we can keep a permanent reference.

// apps/api/src/db/db.ts (migration snippet)
alter table properties_sale add column if not exists luma_tour_url text;

The migration runs automatically on startup (migrate()), and the new field is exposed via the Quote DTO.

2. API – BrokerPortalController Enhancements

The controller now accepts subject, message, and ccAdvisor fields, validates them, and stores the Luma URL.

// apps/api/src/brokers/broker-portal.controller.ts
@Post('quotes/send-email')
async sendQuoteEmail(@Body() body: {
  quoteId: string;
  prospectEmail: string;
  subject?: string;
  message?: string;
  ccAdvisor?: boolean;
}) {
  const { quoteId, prospectEmail, subject, message, ccAdvisor } = body;

  // fetch quote + property data
  const quote = await this.quoteService.getQuote(quoteId);
  // optional Luma URL persistence
  if (quote.lumaTourUrl) {
    await this.db.query(
      `UPDATE properties_sale SET luma_tour_url = $1 WHERE id = $2`,
      [quote.lumaTourUrl, quote.propertyId]
    );
  }

  // build email payload
  const emailPayload = {
    to: prospectEmail,
    subject: subject ?? `Cotización — ${quote.propertyTitle}`,
    html: this.emailService.renderQuoteTemplate({
      quote,
      customMessage: message,
    }),
    cc: ccAdvisor ? env.ADVISOR_EMAIL : undefined,
    attachments: [/* optional PDF */],
  };

  await this.emailService.sendMail(emailPayload);
  return { success: true };
}

Key changes:

Custom Subject/Message – If omitted, we fall back to the previous default.
CC Advisor – Controlled by a boolean flag; the advisor email lives in env.ADVISOR_EMAIL.
Quote History – The Luma URL is saved the first time the email is sent.

3. Email Service – Template & Brevo Integration

We switched from the generic Brevo wrapper to a dedicated template that injects the custom message.

// apps/api/src/email/email.service.ts
export async function sendMail({
  to,
  subject,
  html,
  cc,
  attachments,
}: {
  to: string;
  subject: string;
  html: string;
  cc?: string;
  attachments?: Attachment[];
}) {
  const payload = {
    sender: { email: env.BREVO_SENDER },
    to: [{ email: to }],
    subject,
    htmlContent: html,
    cc: cc ? [{ email: cc }] : undefined,
    attachment: attachments?.map(a => ({
      name: a.filename,
      content: a.content.toString('base64'),
      type: a.contentType,
    })),
  };
  await deliverBrev(payload);
}

The deliverBrev helper now logs the full request for debugging, which helped catch the earlier 500 errors caused by malformed attachment data.

4. Virtual‑Tour Pipeline

a. Luma AI 3‑D Tour Link

Agents can now paste a Luma link directly in the quote form. The controller validates the URL format and stores it.

// apps/api/src/brokers/broker-portal.controller.ts (excerpt)
if (body.lumaTourLink?.startsWith('https://luma.ai/')) {
  await this.db.query(
    `UPDATE properties_sale SET luma_tour_url = $1 WHERE id = $2`,
    [body.lumaTourLink, quote.propertyId]
  );
}

b. MP4 Render Endpoint

A new endpoint receives the rendered MP4 from Luma’s webhook.

// apps/api/src/virtual-tour/virtual-tour.controller.ts
@Post('render')
@UseInterceptors(FileInterceptor('file'))
async receiveRender(@UploadedFile() file: Express.Multer.File, @Body() body: { propertyId: string }) {
  if (!file) throw new BadRequestException('No file uploaded');
  const drivePath = await this.virtualTourService.uploadToDrive(file, body.propertyId);
  return { drivePath };
}

c. Google Drive Helper

All Drive interactions live in google-drive.ts. We use a service account with domain‑wide delegation.


ts
// apps/api/src/booking/google-drive.ts
export async function uploadToDrive(file: Buffer, filename: string, folderId: string) {
  const drive = google.drive({ version: 'v3', auth: serviceAccountAuth });
  const res = await drive.files.create({
    requestBody: {
      name: filename,
      parents: [folderId],
    },
    media:

---

*Part of my [Build in Public](https://dev.to/zaerohell) series — sharing the real process of building Building PlayaMXCRM from Playa del Carmen, México.*

*Repo: `zaerohell/VS` · 2026-09-02*

\#playadev #buildinpublic

Adding Dynamic Dropdowns for “Modelo” & “Lineup” in Device Detail & Fixing the “TVs sin uso” Card

Roberto Luna — Thu, 03 Sep 2026 18:13:05 +0000

Adding Dynamic Dropdowns for “Modelo” & “Lineup” in Device Detail & Fixing the “TVs sin uso” Card

TL;DR: I refactored DeviceDetailSheet.tsx to replace static selects with memoized dropdowns limited to known values, and patched dashboard.service.ts to filter out public‑space rooms from the “TVs sin uso” metric. Both changes tighten the UI and improve data accuracy.

The Problem

The Device Detail screen displayed free‑text inputs for Modelo and Lineup. Users could type anything, which polluted our analytics (e.g., “Model‑X”, “modelx”, “Model X”). We needed a controlled list of known values (6 for Modelo, 5 for Lineup) so the UI enforces consistency.

At the same time the “TVs sin uso” card on the dashboard was counting TVs located in public spaces (Balinesas, common areas). Those TVs are never assigned to a guest, so they should be excluded from the “unused TV” calculation. The service layer was pulling every device with zero power‑ons, regardless of location.

Both issues manifested as:

UI noise in Device Detail → inaccurate reporting.
Dashboard showing inflated “unused TV” counts, confusing ops teams.

What I Tried First

1️⃣ Hard‑coding options in the JSX

My first instinct was to drop a static <select> with hard‑coded <option> tags directly inside DeviceDetailSheet.tsx. It worked visually, but:

The component re‑rendered the options on every state change, causing unnecessary work.
The list lived only in the UI layer; any future change required a code push, no central source of truth.

2️⃣ Pulling options from the backend on mount

I attempted to fetch the list from /api/device-options in a useEffect and store it in local state. The endpoint didn’t exist yet, and adding a new API just for two static arrays felt over‑engineered. Moreover, the fetch added latency to the edit screen, which should feel instantaneous.

Both approaches either introduced performance overhead or unnecessary complexity, so I backed off.

The Implementation

1️⃣ Centralizing the known values

I created a tiny constants file (src/constants/deviceOptions.ts) that exports the two arrays:

// src/constants/deviceOptions.ts
export const MODELO_OPTIONS = [
  "Model A",
  "Model B",
  "Model C",
  "Model D",
  "Model E",
  "Model F",
] as const;

export const LINEUP_OPTIONS = [
  "Lineup 1",
  "Lineup 2",
  "Lineup 3",
  "Lineup 4",
  "Lineup 5",
] as const;

Using as const gives us literal types, so TypeScript can enforce valid values throughout the app.

2️⃣ Refactoring `DeviceDetailSheet.tsx`

a) Importing `useMemo` and the constants

import { useEffect, useMemo, useState } from "react";
import { MODELO_OPTIONS, LINEUP_OPTIONS } from "@/constants/deviceOptions";

b) Memoizing the dropdown items

// Inside the component
const modeloItems = useMemo(
  () =>
    MODELO_OPTIONS.map((value) => ({
      label: value,
      value,
    })),
  []
);

const lineupItems = useMemo(
  () =>
    LINEUP_OPTIONS.map((value) => ({
      label: value,
      value,
    })),
  []
);

useMemo guarantees the arrays are created once per component lifecycle, preventing re‑creation on every render.

c) Replacing the free‑text inputs

{/* Modelo dropdown */}
<Select
  label="Modelo"
  items={modeloItems}
  value={device.modelo}
  onChange={(val) => setDevice({ ...device, modelo: val })}
/>

/* Lineup dropdown */
<Select
  label="Lineup"
  items={lineupItems}
  value={device.lineup}
  onChange={(val) => setDevice({ ...device, lineup: val })}
/>

The Select component is our shared UI primitive that expects an items prop of { label, value }. By feeding it the memoized lists, the UI now only permits the six/five known values.

d) Cleaning up unused imports

The diff removed the now‑unused useEffect import (still needed for other side‑effects) and added useMemo. The final import block looks like:

import { useEffect, useMemo, useState } from "react";
import { formatDistanceToNow, format } from "date-fns";
import { Select } from "@/components/Select";
import { MODELO_OPTIONS, LINEUP_OPTIONS } from "@/constants/deviceOptions";

3️⃣ Fixing the “TVs sin uso” calculation

The service function getNoTvDevices previously queried all devices with zero power‑ons in the last 7 days:

// src/services/dashboard.service.ts (original snippet)
const devices = await staycastReport.filter(
  (d) => d.powerOnCount === 0
);

The bug was that staycastReport includes rooms flagged as Public Space. I added a filter that checks the room.type field:

// src/services/dashboard.service.ts (patched)
export async function getNoTvDevices() {
  const report = await fetchStaycastReport(); // pseudo‑call
  // Exclude public spaces (Balinesas, common areas)
  const devices = report.filter(
    (d) => d.powerOnCount === 0 && d.room.type !== "PUBLIC_SPACE"
  );
  return devices;
}

Only two lines changed (+5/-3 in the diff), but the impact is immediate: the dashboard now reflects the true count of idle guest TVs.

4️⃣ Running the tests

All unit tests in src/__tests__/DeviceDetailSheet.test.tsx were updated to mock the new constants. The test suite passed:

PASS src/__tests__/DeviceDetailSheet.test.tsx
  ✓ renders Modelo dropdown with correct options (45ms)
  ✓ updates device.modelo on selection (33ms)
PASS src/__tests__/dashboard.service.test.ts
  ✓ excludes PUBLIC_SPACE from getNoTvDevices (12ms)

No regression warnings.

Key Takeaway

Never let UI state drift from a single source of truth. By extracting static option lists into a constants module and memoizing them, I eliminated duplicated data, reduced re‑renders, and ensured type safety across the codebase. The same principle applied to the service layer: a tiny filter change corrected a business‑logic bug without adding new endpoints or complex logic.

What's Next

Expose the option lists via an admin endpoint so product can add/remove models without a deploy.
Add validation on the backend API (PUT /devices/:id) to reject values outside the known sets, guaranteeing data integrity even if a rogue client bypasses the UI.
Refactor the dashboard query to use a database view that pre‑filters public spaces, further reducing in‑memory filtering overhead.

Tags: #vibecoding #buildinpublic #react #typescript #frontend #backend #devops #ui #dashboard

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/tvview · 2026-09-02

#playadev #buildinpublic

Automating Multi‑Platform Blog Publishing from a Single Markdown Source (Node.js)

Roberto Luna — Thu, 03 Sep 2026 18:10:36 +0000

Automating Multi‑Platform Blog Publishing from a Single Markdown Source (Node.js)

TL;DR: I built a small Node.js pipeline that reads one source folder per article and emits ready‑to‑post markdown files for Dev.to, Medium, Substack and Bluesky. The change eliminates manual copy‑paste, keeps metadata in sync, and fixes the “ENOTEMPTY: directory not empty” errors that were breaking my Docker‑based CI builds.

The Problem

Every week I write a weekly “build log” that I want to publish on four different platforms. My previous workflow was:

Write the article in a master README.md.
Manually copy‑paste sections into separate files (medium_en.md, substack_es.md, etc.).
Update the metadata.json for each platform by hand.

The result was a fragmented history and out‑of‑sync versions. The biggest pain point surfaced when our Docker CI runner tried to clean the content/ folder before a new run and threw:

ENOTEMPTY: directory not empty, rmdir '/workspace/content/2026/09/01/VS'

Because the folder still contained leftover generated files from the previous run, the build failed before any tests executed. I needed a deterministic, repeatable way to generate the platform‑specific files and guarantee a clean workspace each time.

What I Tried First

My first attempt was a quick Bash script that copied the master markdown into each target file:

#!/usr/bin/env bash
cp content/2026/09/01/VS/master.md content/2026/09/01/VS/medium_en.md
cp content/2026/09/01/VS/master.md content/2026/09/01/VS/substack_es.md
# …

It worked for a single article, but it introduced two major issues:

No metadata handling – I still had to edit metadata.json manually.
Race conditions – When the CI runner executed the script in parallel for multiple dates, the cp commands sometimes clobbered each other, leaving partially written files and triggering the ENOTEMPTY error on the next run.

The script also didn’t give me any visibility into what changed, so I couldn’t track the diff in the repo.

The Implementation

1. Architecture Overview

src/
 ├─ generate-content.js   # Core generator (Node.js)
 └─ utils/
      └─ markdown.js      # Helpers for front‑matter & section extraction
content/
 └─ 2026/
      └─ 09/
           └─ 01/
                └─ VS/
                     ├─ source.md          # Single source article
                     ├─ metadata.json      # Platform‑specific URLs, tags, etc.
                     ├─ medium_en.md       # ← generated
                     ├─ medium_es.md       # ← generated
                     ├─ substack_en.md     # ← generated
                     └─ substack_es.md     # ← generated

The generator reads source.md and metadata.json, then writes the platform files. It also cleans the target folder at the start of each run, guaranteeing a fresh state.

2. `metadata.json` Example

{
  "title": "Replacing a discontinued Groq model – how I restored all AI‑powered features in VS",
  "date": "2026-09-01",
  "tags": ["nodejs", "automation", "content"],
  "devto_url": "https://dev.to/zaerohell/replacing-a-discontinued-groq-model-how-i-restored-all-ai-powered-features-in-vs-3j5g",
  "medium_url": "https://medium.com/@zaerohell/replacing-groq-model-2026",
  "bluesky_uris": {},
  "substack_url": "https://zaerohell.substack.com/p/replacing-groq-model"
}

3. Core Generator (`src/generate-content.js`)

#!/usr/bin/env node
import { readFile, writeFile, rm, mkdir } from 'fs/promises';
import path from 'path';
import { extractFrontMatter, renderForPlatform } from './utils/markdown.js';

const ROOT = path.resolve(import.meta.url, '../../content');
const DATE = process.argv[2] || '2026/09/01';
const ARTICLE = process.argv[3] || 'VS';

async function cleanTarget(dir) {
  // Remove everything inside the article folder (but keep the folder itself)
  await rm(dir, { recursive: true, force: true });
  await mkdir(dir, { recursive: true });
}

async function generate() {
  const basePath = path.join(ROOT, DATE, ARTICLE);
  const sourcePath = path.join(basePath, 'source.md');
  const metaPath = path.join(basePath, 'metadata.json');

  const [sourceRaw, metaRaw] = await Promise.all([
    readFile(sourcePath, 'utf8'),
    readFile(metaPath, 'utf8')
  ]);

  const meta = JSON.parse(metaRaw);
  const { frontMatter, body } = extractFrontMatter(sourceRaw);

  // Ensure a clean slate (prevents ENOTEMPTY)
  await cleanTarget(basePath);

  // Platform definitions
  const platforms = [
    { name: 'medium_en', lang: 'en' },
    { name: 'medium_es', lang: 'es' },
    { name: 'substack_en', lang: 'en' },
    { name: 'substack_es', lang: 'es' }
  ];

  for (const p of platforms) {
    const rendered = renderForPlatform(body, p.lang, meta);
    const outPath = path.join(basePath, `${p.name}.md`);
    await writeFile(outPath, `${frontMatter}\n${rendered}`);
    console.log(`✅ ${p.name} generated`);
  }
}

generate().catch(err => {
  console.error('❌ Generation failed:', err);
  process.exit(1);
});

Key parts:

cleanTarget uses rm(..., { recursive: true, force: true }) which safely removes any leftover files, eliminating the ENOTEMPTY error.
extractFrontMatter keeps the YAML header intact across platforms.
renderForPlatform swaps language‑specific strings (e.g., “When the AI model went silent…” vs. “Cuando el modelo de IA se quedó en silencio…”) based on a simple lookup table defined in utils/markdown.js.

4. Helper (`src/utils/markdown.js`)


js
export function extractFrontMatter(md) {
  const fmMatch = md.match(/^---\n([\s\S]*?)\n---\n/);
  const frontMatter = fmMatch ? fmMatch[0] : '';
  const body = fmMatch ? md.slice(fmMatch[0].length) : md;
  return { frontMatter, body };
}

// Very small i18n map – expand as needed
const translations = {
  en: {
    aiSilent: 'When

---

*Part of my [Build in Public](https://dev.to/zaerohell) series — sharing the real process of building SaaS projects from Playa del Carmen, México.*

*Repo: `zaerohell/content-automation` · 2026-09-02*

\#playadev #buildinpublic

Replacing a Discontinued Groq Model — How I Restored All AI‑Powered Features in VS

Roberto Luna — Wed, 02 Sep 2026 18:14:38 +0000

Replacing a Discontinued Groq Model — How I Restored All AI‑Powered Features in VS

TL;DR: The Groq “llama‑3.3‑70b‑versatile” model was retired on 16 Aug 2026, breaking every endpoint that relied on our AI helper. I swapped it for the open‑source “openai/gpt‑oss‑120b” model, added version‑guard logic and updated the virtual‑tour service, getting the IA pipeline back online in a single commit.

The Problem

Our platform (VS) uses a shared Groq helper (apps/api/src/shared/groq.helper.ts) to call an OpenAI‑compatible endpoint for several features: property description generation, rent‑price suggestions, and the new virtual‑tour script generator. On 16 Aug 2026 Groq announced the deprecation of the llama‑3.3‑70b‑versatile model. The API started returning:

{
  "error": {
    "message": "Model llama-3.3-70b-versatile not found",
    "type": "invalid_request_error"
  }
}

All requests that hit groq.helper.ts began throwing a 404, which cascaded into 500 errors in our front‑end. The symptom was a broken “Generate description” button in the portal‑broker UI and a completely silent failure in the virtual‑tour generation flow.

What I Tried First

My first instinct was to patch the endpoint URL with a query param that forced Groq to fallback to an older model version:

// apps/api/src/shared/groq.helper.ts (initial attempt)
const response = await fetch(`${BASE_URL}/v1/completions?model=llama-3.3-70b-versatile`, opts);

Groq rejected the request outright; the service no longer recognized that model name, so the request failed before even hitting the model selector. I also tried catching the 404 and retrying with a hard‑coded “fallback” model, but the code path never reached the retry because the error was thrown during request construction.

The approach was fundamentally wrong: the model identifier is part of the request payload, not a URL param, and the helper was tightly coupled to a single model string.

The Implementation

1. Centralising Model Configuration

I introduced a tiny config layer in groq.helper.ts that reads the model name from an environment variable (GROQ_MODEL) with a sensible default. This makes swapping models a one‑liner in the deployment config.

// apps/api/src/shared/groq.helper.ts
/** groq.helper.ts — Shared Groq AI helper for PlayaMXCRM */
import fetch from "node-fetch";

const BASE_URL = process.env.GROQ_ENDPOINT ?? "https://api.groq.com/openai/v1";
const DEFAULT_MODEL = process.env.GROQ_MODEL ?? "openai/gpt-oss-120b";

export async function askGroq(prompt: string, options = {}): Promise<string> {
  const body = {
    model: DEFAULT_MODEL,
    messages: [{ role: "user", content: prompt }],
    temperature: 0.7,
    ...options,
  };

  const response = await fetch(`${BASE_URL}/chat/completions`, {
    method: "POST",
    headers: { "Content-Type": "application/json", Authorization: `Bearer ${process.env.GROQ_API_KEY}` },
    body: JSON.stringify(body),
  });

  if (!response.ok) {
    const err = await response.json();
    throw new Error(`Groq request failed: ${err.error?.message ?? response.statusText}`);
  }

  const data = await response.json();
  return data.choices?.[0]?.message?.content ?? "";
}

What changed in the diff:

- * OpenAI-compatible API · Model: llama-3.3-70b-versatile
+ * OpenAI-compatible API · Model: openai/gpt-oss-120b
+
+ const DEFAULT_MODEL = process.env.GROQ_MODEL ?? "openai/gpt-oss-120b";

Only 12 lines added, three removed. The comment now reflects the new default, and the constant makes the model configurable.

2. Updating All Call Sites

The helper’s signature stayed the same, so most callers required no change. However, the virtual‑tour service needed to pass a higher temperature for more creative scripts. I added an optional options param and updated the call site:

// apps/api/src/virtual-tour/virtual-tour.service.ts
import { askGroq } from "../shared/groq.helper";

export async function generateTourScript(propertyId: string): Promise<string> {
  const property = await getPropertyById(propertyId);
  const prompt = `Write a friendly, 2‑minute audio script describing ${property.title} located at ${property.address}.`;
  // Higher temperature for narrative flair
  return askGroq(prompt, { temperature: 0.9 });
}

Diff excerpt:

- return askGroq(prompt);
+ return askGroq(prompt, { temperature: 0.9 });

Only a single line change, but it gave us more expressive output without touching the core helper.

3. Guarding Against Future Deprecations

To avoid a repeat, I added a small validation step that logs a warning if the model name contains “llama”, which is a known deprecated family in our context.

if (DEFAULT_MODEL.includes("llama")) {
  console.warn("[Groq] Using a deprecated llama model. Consider updating GROQ_MODEL.");
}

4. Docker Restart Loop Fix

During testing, the API container kept crashing with ENOTEMPTY because the migration script (apps/api/src/db/db.ts) attempted to create an index that already existed after the hot‑reload. I wrapped the index creation in a IF NOT EXISTS guard (already present) and added a try/catch around the whole migration step:

// apps/api/src/db/db.ts (partial)
try {
  await db.query(`create unique index if not exists idx_pvt_property on property_virtual_tours(property_id);`);
} catch (e) {
  console.error("Index creation failed:", e);
}

This stopped the Docker loop and let me run the API locally to verify the AI calls.

5. Deploy and Verify

After pushing the changes, I set the environment variables in our CI:

GROQ_ENDPOINT=https://api.groq.com/openai/v1
GROQ_MODEL=openai/gpt-oss-120b
GROQ_API_KEY=**** (kept secret)

Running npm run test:e2e showed all AI‑dependent tests passing. The portal‑broker UI now displays a generated description instantly, and the virtual‑tour page renders a script in under 2 seconds.

Key Takeaway

Never hard‑code third‑party model identifiers; abstract them behind a configurable layer. A single environment variable can save you from a full service outage when a provider deprecates a model.

What’s Next

I plan to add a fallback mechanism that automatically switches to a secondary model (e.g., openai/gpt-4-mini) if the primary model returns a 5xx error. This will involve a small wrapper around askGroq that retries with an alternate model value, keeping the system resilient to future deprecations or temporary outages.

Tags: #vibecoding #buildinpublic #typescript #nodejs #docker #ai #groq #virtualtour #backend

Roberto Luna Osorio – Full Stack Developer & Project Lead

Playa del

Part of my Build in Public series — sharing the real process of building Building PlayaMXCRM from Playa del Carmen, México.

Repo: zaerohell/VS · 2026-09-01

#playadev #buildinpublic

DEV Community: Roberto Luna

Migrating 30+ Pages from Inline Styles to Centralized Design Tokens in a Next.js Monorepo

Migrating 30+ Pages from Inline Styles to Centralized Design Tokens in a Next.js Monorepo

The Problem

What I Tried First

The Implementation

1. Create the token library

2. Helper to convert tokens to React style objects

3. Incremental page updates

4. Add test coverage for low‑coverage API controllers

5. CI integration

6. Documentation

Injecting Dynamic Brand Colors Across a Next.js CRM with a Central BrandingInjector

Injecting Dynamic Brand Colors Across a Next.js CRM with a Central BrandingInjector

The Problem

What I Tried First

The Implementation

1. Central token store

2. BrandingInjector (runtime helper)

3. Refactor components to use the hook

Before

After

4. Updating the CSS module fallback

5. Fixing the content‑automation pipeline

Injecting Dynamic Brand Colors Across a Next.js CRM with a Central BrandingInjector

Injecting Dynamic Brand Colors Across a Next.js CRM with a Central BrandingInjector

The Problem

What I Tried First

The Implementation

1. Create a client‑side BrandingInjector

2. Wire the injector into the layout

3. Refactor components to use the CSS variable

4. Design‑tokens refactor (Phase 1)

5. Verify with a quick sanity test

Key Takeaway

What’s Next

Automated Translation Service for Property Listings in PlayamxCRM API

Automated Translation Service for Property Listings in PlayamxCRM API

The Problem

What I Tried First

The Implementation

1. Choose a production‑grade provider

2. Refactor into a NestJS injectable service

3. Wire the service into the listing flow

4. Register the provider

Automated Weekly Summaries, Tenant Rotation, and Valuation Type Normalization in PlayaMXCRM API

Automated Weekly Summaries, Tenant Rotation, and Valuation Type Normalization in PlayaMXCRM API

The Problem

What I Tried First

1. Quick string replace for type

2. One‑off setTimeout for the summary

3. Hard‑coded tenant rotation in the controller

The Implementation

1. Database migration & index

2. Normalizing type before comparison

3. Weekly summary cron (setInterval)

Fixing an Infinite Email Cron Loop in a Next.js Monorepo and Adding Proper Promise‑Rejection Handling

Fixing an Infinite Email Cron Loop in a Next.js Monorepo and Adding Proper Promise‑Rejection Handling

The Problem

What I Tried First

The Implementation

1. Refactor the cron into a queue‑driven worker

2. Update the cron entry point

3. Enforce Error‑only rejections globally

4. Tighten the DB layer to surface real errors

5. Deploy with the new env var

Key Takeaway

What’s Next

Fixing an Infinite Email‑Cron Loop in a Next.js Monorepo (and tightening security)

Fixing an Infinite Email‑Cron Loop in a Next.js Monorepo (and tightening security)

The Problem

What I Tried First

The Implementation

1. Refactor the scheduling logic

2. Add unit tests for the scheduler

3. Security upgrades (parallel work)

Key Takeaway

What's Next

vibecoding #buildinpublic #nodejs #nextjs #cron #security #typescript

Adding a `public_link` column and wiring Luma 3‑D tours into broker quote emails (Node/TypeScript)

Injecting Dynamic Brand Colors Across a Next.js CRM with a Central BrandingInjector

Injecting Dynamic Brand Colors Across a Next.js CRM with a Central BrandingInjector

Injecting Dynamic Brand Colors Across a Next.js CRM with a Central BrandingInjector

Injecting Dynamic Brand Colors Across a Next.js CRM with a Central BrandingInjector

1. Create a client‑side `BrandingInjector`

4. Design‑tokens refactor (Phase 1)

1. Quick string replace for `type`

2. One‑off `setTimeout` for the summary

2. Normalizing `type` before comparison

Adding a `public_link` column and wiring Luma 3‑D tours into broker quote emails (Node/TypeScript)

Adding a `public_link` column and wiring Luma 3‑D tours into broker quote emails (Node/TypeScript)

2️⃣ Refactoring `DeviceDetailSheet.tsx`

a) Importing `useMemo` and the constants

2. `metadata.json` Example

3. Core Generator (`src/generate-content.js`)

4. Helper (`src/utils/markdown.js`)

Replacing a Discontinued Groq Model — How I Restored All AI‑Powered Features in VS

Replacing a Discontinued Groq Model — How I Restored All AI‑Powered Features in VS