Case study

MakerCogs

Shop-floor software for the small manufacturers that enterprise MES vendors ignored — and Excel is no longer enough for.

Visit MakerCogs →

The problem

The shop-floor software market is bifurcated. At one end, enterprise MES (Manufacturing Execution Systems) like SAP, Plex, or Epicor cost six figures, take a year to implement, and require dedicated IT teams. At the other end, small manufacturers — makers with 1 to 50 employees, contract shops, custom fabricators, prototyping houses — track jobs in Excel, write process specs in Google Docs, and run their inventory off a clipboard hung next to the bandsaw. There is nothing in the middle that fits the way these shops actually work.

MakerCogs was built to be that middle layer. A modern web platform for managing inventory, scheduling jobs, tracking work orders through the shop, and capturing the workflow knowledge that lives in the head of the shop owner. Cheap enough that a 5-person shop can afford it, simple enough that it does not require IT to deploy, but capable enough that it scales with the business as it grows.

Our approach

The early product decisions were driven by talking to actual shop owners. The first observation: Excel works because it is forgiving. People can put what they need in a cell, the boss can scan it, and corrections are easy. Any replacement has to feel as forgiving as Excel — strict schemas and rigid forms get rejected by users on day one. We built MakerCogs around flexible inventory schemas, optional fields, and a UI that treats shop reality (one-off jobs, custom requests, missing data) as the norm rather than the exception.

The second observation: small shops do not have IT support. The platform had to be deployable in minutes and operable by someone whose primary job is operating a CNC machine. That meant SaaS-only deployment, mobile-first UIs for the shop floor, no admin console with 200 settings, and reasonable defaults for everything.

The third observation: shop-floor work has natural async patterns. A job runs across multiple workstations, gets paused for material delays, gets reopened when QA finds an issue, and bounces between people who are not at desks. We modeled the platform around state machines per work order, with explicit transitions and timestamped history — so the state of a job is always recoverable, and the shop owner can see exactly where work is stuck without asking.

Stack

Backend

  • Go
  • PostgreSQL
  • sqlc

Web

  • TypeScript
  • React + Next.js
  • Tailwind CSS
  • Mobile-first responsive design

Workflows

  • State machines per work order
  • Timestamped audit trail
  • Optional approval flows

Integrations

  • QuickBooks (planned)
  • Shopify export
  • CSV import/export

Infrastructure

  • Kubernetes
  • PostgreSQL backups
  • CDN for static assets

Mobile

  • Progressive Web App
  • Offline-tolerant for shop-floor scanning
  • Barcode scanner integration

Outcome

MakerCogs serves small manufacturers that fall into the gap between "Excel" and "enterprise MES." The platform scales down to 1-person shops and up to mid-size contract manufacturers without a step-change in pricing or complexity.

The flexibility-first design philosophy has held up. Shops can model their inventory and workflows without bending to the platform's schema, and the platform stays usable even when shop reality (missing data, one-off custom jobs, bouncing work orders) breaks the assumptions enterprise MES tools impose.

Most importantly, MakerCogs is operationally cheap to run. Same Go-and-Postgres pattern as SysWard, same Kubernetes deployment, same operational standards. New features add incremental complexity, not architectural complexity.

What we learned

  • For SMB software, flexibility beats correctness. Excel works because it is forgiving; any replacement has to be too.
  • Shop-floor users do not have IT. SaaS deployment, mobile-first UI, no admin console with hundreds of settings.
  • State machines are the right model for any workflow that can pause, resume, or reverse. Bake the state machine in early; do not bolt it on.
  • The pricing structure of your replacement matters as much as the features. SMBs cannot afford enterprise MES; that is a feature gap that justifies a whole product.
  • Talking to actual users in their actual environment is irreplaceable. We built a list of "things Excel does well" before designing replacements for it.

Have a project that needs the same standards?

Email us a paragraph about what you are building. We respond within one business day.

[email protected]