Dev Vite Now, Prod Dist on a Trigger

"Don't build the production pipeline for a second user you don't have yet."

One User, One Consumer, No Reason to Build

Bonfire's engine and UI run as one always-on command, and the UI is served by the dev Vite server, not a production static build. That looks sloppy until you see the situation honestly: right now Bonfire is a single-user app under active development on one machine. The UI has exactly one consumer — itself — and the same person both builds it and uses it. In that situation a production dist buys nothing and costs a rebuild on every single change. Dev Vite reflects each edit instantly through HMR. The 'sloppy' choice is actually the correct one.

The Premature-Dist Cautionary Tale

Bonfire first copied a prod-static-dist always-on setup from a sibling engine — and it backfired. Restarting the server never reflected code changes, because nothing rebuilt the dist. That's the signature of premature generalization: you stand up production-serving infrastructure before there's a production situation, and it quietly does the wrong thing. The fix wasn't more infrastructure; it was less — drop to dev Vite and let HMR do its job.

The Trigger to Flip

This isn't 'never ship a prod build.' It's 'flip when the situation actually changes.' The trigger is concrete: the moment an external client consumes the engine API, or Bonfire deploys to the server as a stable prod engine, switch to a prod static build (npm run build → frontend/dist, served by a StaticFiles mount that already sits dormant, mounted last so the API always wins). Until one of those is true, dev Vite is correct. Concrete-first: build the prod path when there's a prod reason, not in anticipation of one.

Code

Dev Vite until a concrete trigger flips it·text

Now (single user, active dev):
  dev Vite (:5175, HMR, no build step) -> every edit reflects instantly

Flip to prod static dist WHEN (either is true):
  - an external client consumes the engine API, OR
  - Bonfire deploys to the server as a stable prod engine
Then: npm run build -> frontend/dist
      (StaticFiles mount already dormant, mounted LAST so /api wins)

# Premature dist backfired once: restarts never reflected code,
# because nothing rebuilt the dist. Less infra was the fix.

Exercise

Find a piece of 'production' infrastructure in a project (a build step, a cache, a queue, a CDN) and ask: how many consumers does it actually serve today? If the answer is one — and that one is you, mid-development — ask whether the simpler dev-time path would be correct until a real second consumer arrives.

Hint

The tell of premature infra is a production mechanism guarding a non-production situation. One consumer who is also the author rarely needs a prod pipeline — that's a future need wearing a present-day costume.