Modular_OS

Context

Modular construction factories build houses the way a plant builds cars — stages, stations, WIP. But the floor often runs on a mix of spreadsheets, whiteboards, and WeChat-style group chats. The real pain isn’t data entry; it’s that blockers, rework, and dispatch readiness aren’t visible until someone walks the floor.

Modular_OS is the production console I started building to make those things first-class objects instead of side effects. It’s scoped for a small shop: one factory, a handful of units on the floor at any time, and a team that needs to see state change in seconds, not at tomorrow’s standup.

Approach

Domain model

Four production stages, modeled explicitly instead of as string enums:

1. Framing
2. MEP (mechanical / electrical / plumbing)
3. Interior finish
4. Dispatch readiness

Each unit is a node that moves between stages. WIP limits, blockers, rework, and dispatch readiness are first-class domain entities — you can open a blocker on a unit, attach it to a stage, and the console shows where the floor is stuck without anyone paging anyone.

Runtime shape

• Frontend — React + TypeScript, Vite dev server, designed for floor tablets first.
• Backend — Express + Prisma + SQLite. SQLite is the right call at this scale: one factory, one source of truth, durable, no DB admin.
• Realtime — Socket.IO. When a unit advances a stage, every connected tablet updates under a second.
• Desktop — Electron wrapper for a stable always-on console view on a shop-floor PC.

Two-repo structure

• Private source — the actual application.
• Public showcase repo — architecture notes, screenshots, UX philosophy. Allows portfolio visibility without exposing IP.

Results & What I Learned

Active development; not yet generally shipped. The showcase repo is public; the source is private by design.

What the project is teaching me — all of this is the unglamorous part of “shipping to a real factory”:

• Latency tolerance on a shop floor is zero. If the console is 2 seconds behind reality, people stop trusting it. That’s why realtime is a product decision, not a technical one.
• Blockers are more important than progress. The most useful screen in the app turned out to be the blockers view, not the kanban. That wasn’t obvious at design time.
• Offline behavior is a feature. Tablets in a plant lose Wi-Fi. The next iteration adds optimistic writes + reconcile, not because users asked, but because without it the console is brittle in exactly the environment it’s built for.

Tech Stack & Links

Stack: React · TypeScript · Vite · Express · Prisma · SQLite · Socket.IO · Electron

Links: Public showcase repo (source is private)