30 days, 386 commits, non-dev: building a factory's production system with Claude Code. What am I missing?
\*\*TL;DR:\*\* I'm not a developer. On September 4th I started building a production management web app for the furniture plant where I work, with Claude Code. One month later it's the tool the office and the shop floor use every day. Sharing what worked, and looking for people who've gone down the same road.
\---
\*\*A bit about me\*\*
I work at a furniture manufacturer, on the operations / planning side (Director). My days are spent in the gap between the ERP, the accounting system, a pile of Excel workbooks, an old in-house tracker the floor depends on, and what's actually happening in the shop. I'm not a programmer, and I'm still a beginner with the terminal and Git. I manage the systems, with an IT guy + looking for a full stack developer at the moment.
\*\*What we built\*\*
It started as "one page per department showing what to build this week". It grew into:
\- Production schedules per department (wood, upholstery, sewing, metal, finishing, shipping), with kanban cards and project closures
\- Lot planning: building lots, closing them, and exporting back to the ERP
\- Purchasing follow-up: open POs, supplier reminders, freight and overseas shipments
\- A capacity simulator, inventory counts, shop reports, a supervisor dashboard, even a small internal chat
\- Read-only connections to the ERP, the accounting system, Access databases and network spreadsheets
Scale, just to give an idea (I know lines of code aren't a quality metric): 386 commits, currently v2.54, \~175k lines of Python and vanilla JS, \~2,100 tests, \~580 API routes, \~280 SQLite tables. The stack is boring on purpose: FastAPI + SQLite + plain HTML/JS with Tailwind, no build step, running on a Windows machine on site. Everything, UI and code, is in French.
\*\*What made it work for me\*\*
\- \*\*A short CLAUDE.md + one doc per module.\*\* CLAUDE.md only holds what applies to every session. Each module (37 of them) has its own doc that Claude reads before touching it. When something breaks, the lesson becomes a rule in the right doc.
\- \*\*Memory for project state.\*\* A new session knows where each project stands and which questions are still waiting on me.
\- \*\*Questions before code.\*\* Every new screen starts as a mockup, and Claude asks me questions first. Some features started with 40+ questions. Honestly, that's where a lot of the value is: it forced me to write down business rules nobody had ever written down.
\- \*\*Every external system is read-only.\*\* The old tracker can literally stop production if it gets locked, so only one read at a time, behind a lock. And a guard blocks any network access, subprocess or file write during the test suite.
\- \*\*One git worktree per feature.\*\* Never code in the folder the live app serves.
\- \*\*A release skill.\*\* A checklist for version number, registries, tests, commit and deploy.
\- \*\*Cost as a constraint.\*\* 4 to 8 targeted tests per change, no swarms of agents.
\*\*Where I'd love your experience\*\*
\*\*Bus factor.\*\* I can read the docs and the tests, but I couldn't rewrite most of this code myself. If you've been there: when did you bring in a real developer, and how did the hand-off go?
\*\*Docs that rot.\*\* With \~40 module docs and a growing list of rules, how do you keep CLAUDE.md and the docs from contradicting each other?
\*\*Tests written by the same model that wrote the code.\*\* How do you check they test the right things?
\*\*Adoption.\*\* The floor doesn't care about the tech; it cares that the numbers are right Monday at 6 a.m. How do you ship this fast without burning trust?
\*\*Manufacturing / ERP folks:\*\* anyone else doing this? What blew up on you?
I'll stay a bit vague about the company and the systems, hope you understand. Happy to go deeper on the workflow in the comments.
\*(And yes, Claude helped with the English. I'm a French speaker.)\*