How I built a store with a real-time catalog and automatic rebuilds: the Los Luises case

The problem: a catalog that changes daily, on a site generated once

Los Luises is a sublimation and printing workshop with more than 26 years of history. Its catalog changes often: prices, offers, stock and new products. The site, though, is a Next.js static export: HTML generated once at build time, with no server behind it. If every price change needed a full build, the catalog would never be current.

Why I separated real-time reads from the rebuild

Instead of forcing everything through one path, I split the problem in two. For data that changes often (price, stock, offers), the browser listens to Firestore directly. For changes that need a new page or touch the sitemap (a new product, for example), the whole site gets regenerated.

The hook that does the real-time read is simple: it subscribes to the products collection with onSnapshot and updates state whenever something changes in Firestore, with no page reload needed.

export function useProducts() {
  const [products, setProducts] = useState<Product[]>([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    const unsubscribe = onSnapshot(
      collection(db, "products"),
      (snapshot) => {
        setProducts(snapshot.docs.map((doc) => doc.data() as Product));
        setLoading(false);
      },
      (err) => {
        setError(err);
        setLoading(false);
      }
    );
    return unsubscribe;
  }, []);

  return { products, loading, error };
}

How the rebuild triggers itself

The other half of the system is a Cloud Function that listens to any write on products/{productId}. When it detects a change, it calls the Cloud Build API directly to start a new build, with no person needing to run anything.

exports.rebuildOnProductChange = onDocumentWritten(
  { document: "products/{productId}", region: "us-central1", memory: "256MiB" },
  async (event) => {
    const auth = new GoogleAuth({
      scopes: ["https://www.googleapis.com/auth/cloud-platform"],
    });
    const client = await auth.getClient();
    const projectId = await auth.getProjectId();

    const body = {
      source: { storageSource: { bucket, object } },
      steps: buildSteps(),
      timeout: "1200s",
    };

    await client.request({
      url: `https://cloudbuild.googleapis.com/v1/projects/${projectId}/builds`,
      method: "POST",
      data: body,
    });
  }
);

// Debe reflejar los mismos steps que cloudbuild.yaml en la raíz del repo.
// Si cambiás cloudbuild.yaml, actualizá esto también.

That comment in the code is, literally, a note I left myself: the build steps (buildSteps()) have to match the ones in cloudbuild.yaml at the repo root, and if I change one I have to remember to change the other by hand. I come back to this in the technical debt section.

How I validated this architecture

I actually ran npm run build against the repository (Next.js 16.2.12, Turbopack, with the project's real .env.local) and measured the result instead of describing it from memory. The build finished in 18.8 seconds and generated 74 static routes, including 54 product pages (38 customizable and 16 stock) and a sitemap.xml with 62 URLs, matching what the production site actually returns.

const nextConfig: NextConfig = {
  output: "export",
  images: {
    unoptimized: true,
  },
};

Measurable results

I measured the following on October 18, 2026, with Lighthouse (lab data, simulated throttling) against the production site, and with a real local build.

An 18.3 second LCP is the highest of every project I measured for this series. My hypothesis, without deep browser profiling, is that two costs stack up: images.unoptimized: true (same as other static-export projects) and the product list depending on onSnapshot receiving its first Firestore snapshot before it can render anything. That's a reasonable hypothesis from the code, not a cause confirmed with profiling.

Layered security: what these rules allow, and what they don't

The products collection can be read with no authentication (it's catalog data, not sensitive) but can only be written to with a signed-in session. These are the project's real rules, not summarized or softened.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /products/{productId} {
      allow read: if true;
      allow write: if request.auth != null;
    }
  }
}

This protects against anonymous writes to the database. It says nothing about the security of the /admin panel itself (login, session handling) or other parts of the system: it's one piece of the security, not all of it.

Separating what changes constantly from what needs a new page isn't an optimization, it's the right question to ask before choosing the architecture.

My part in this project

My part in Los Luises Sublimación included the complete architecture design, full-stack development (frontend, admin panel and Cloud Function), the Firebase and Google Cloud infrastructure, and technical SEO, as part of my work at MANYA Digital.

What I'd do differently: a warning I found in my own code

Reviewing the repository for this article, I found two things I didn't remember precisely. First: the build pipeline's steps are written twice, once in the Cloud Function and once in cloudbuild.yaml, and the code itself has a comment asking for both to be updated together. That's exactly the kind of duplication that drifts out of sync over time if no one notices.

Second: the Cloud Function's runtime is pinned to Node 20, while the Cloud Build steps run on Node 22 images. Nothing breaks today, but that's two Node versions coexisting in the same pipeline, undocumented anywhere until this article.

Neither point affects the production site right now. I leave them documented because they're the kind of detail worth knowing before touching the pipeline, not after something breaks from an update made in only one place.

What I'd test next

I'd unify the pipeline definition into a single file (having the Cloud Function read cloudbuild.yaml instead of duplicating its steps in JavaScript), align the Node version between the function and the Cloud Build images, and optimize the catalog's images to bring down the measured 18.3s LCP, probably the change with the biggest real impact of the three.

Until then, the system delivers what it promises: instant price and stock, new pages with no one running a manual deploy, and a warning in the code that, now, is written down somewhere it won't get lost.