How I built a live customizer and then simplified it into an iframe: the Ciudad del Láser case

The problem: quoting with no counter, for a shop that lives on WhatsApp

Ciudad del Láser has no counter service: every quote goes through WhatsApp or email. The previous site didn't explain how to prepare a cutting file, and the client couldn't update content without depending on a developer.

What I built first: a live customizer with real validation

For custom mate cups and plaques, I built a customizer in React that used the browser's Canvas to measure the text the client typed, instead of depending on an external library.

let measureCanvas;
function measureTextWidth(text, family, sizePx) {
  if (typeof document === 'undefined') return 0;
  if (!measureCanvas) measureCanvas = document.createElement('canvas');
  const ctx = measureCanvas.getContext('2d');
  ctx.font = `${sizePx}px ${family}`;
  return (text || '').split('\n')
    .reduce((max, line) => Math.max(max, ctx.measureText(line).width), 0);
}

With that measurement, the customizer compared the text against a fixed printable area and flagged when the design went past the margins, on top of detecting characters unsafe for laser engraving.

const { width: textWidth, lineCount } = useTextMeasurement(
  d.text, d.font.family, d.fontSize
);
const textHeight = lineCount * d.fontSize * 1.2;

const overflowsPrintableArea =
  textWidth > PRINTABLE_BOX.width || textHeight > PRINTABLE_BOX.height;

const unsafeChars = findUnsafeCharacters(d.text);

What's in production today: an iframe to a tool that already existed

At some point, that custom customizer was replaced with an <iframe> embedding an already-existing external PHP tool (ember.com.ar/virolas). The change is documented in commit d1b954f, whose message literally says it simplifies the Personalizador by removing the mate and plaque customizers.

I won't invent a reason that isn't written in the commit. What I can say is that, in engineering terms, it's a reasonable call: an external tool that already solved the problem avoids maintaining an equivalent piece of custom software, at the cost of fine control over the experience.

The 5 mm margin rule and the line colors (cutting, marking, engraving) still exist, but as content in a «How to prepare your file» guide, not as validation running in the client's browser.

How the sitemap stays current without depending on a build

Content (services, blog) lives in Sanity. Instead of regenerating the sitemap only on each build, a Cloud Function assembles it on the fly, querying Sanity with GROQ every time someone requests it.

export const sitemap = onRequest({ cors: false }, async (req, res) => {
  const [services, posts] = await Promise.all([
    sanityClient.fetch(`*[_type == "service"]{ "slug": slug.current }`),
    sanityClient.fetch(`*[_type == "blogPost"]{ "slug": slug.current }`),
  ]);
  const entries = [
    ...STATIC_URLS.map((s) => urlEntry(s.loc, s.priority)),
    ...services.map((s) => urlEntry(`/${s.slug}`, '0.9')),
    ...posts.map((p) => urlEntry(`/blog/${p.slug}`, '0.5')),
  ];
  const xml = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${entries.join('\n')}
</urlset>`;
  res.set('Content-Type', 'application/xml');
  res.set('Cache-Control', 'public, max-age=300, s-maxage=3600');
  res.status(200).send(xml);
});

This means that if a new service is published in Sanity, it shows up in the sitemap without waiting for the site's next build, even though the HTML pages still need that build to exist.

How the form builds the WhatsApp message

function handleSubmit(e) {
  e.preventDefault();
  const message = [
    `Hola! Quiero cotizar: ${serviceName}.`,
    `Nombre: ${form.nombre}`,
    form.telefono && `Teléfono: ${form.telefono}`,
    form.detalle && `Detalle: ${form.detalle}`,
  ].filter(Boolean).join('\n');
  window.open(buildWhatsappLink(message), '_blank', 'noreferrer');
}

How I validated this architecture

I ran the repository's real build process (vite build plus the SSR step and the prerender script) with no secret environment variables, since Sanity is consumed in public mode (useCdn: true).

Simplifying custom code that already works is as valid a decision as building it, as long as it stays documented.

My part in this project

My part in Ciudad del Láser included frontend development, integrating Sanity as the CMS, the sitemap Cloud Function and technical SEO, as part of my work at MANYA Digital.

What I'd do differently: orphaned code with no explicit decision

The original customizer wasn't deleted, it was just stopped being used. Today it lives in the repository alongside the rest of the code, with no note saying whether it's a future reference or just something nobody got around to cleaning up. That ambiguity is the real problem, not the code itself.

What I'd test next

I'd explicitly decide the fate of the customizer's orphaned code: document it as a reference for a future custom version, or remove it outright. I'd also evaluate whether it's worth bringing the live customizer back now that the tested validation logic already exists, instead of depending on an external tool outside my control.