I Built a Local-First ERP for Makers Using Only LLMs (BUS Core v1.0)
BUS Core v1.0 just shipped.
It’s a local-first ERP for small manufacturing shops and makers — inventory, costing, manufacturing runs, vendors, and shop journals.
Everything runs locally.
No accounts. No SaaS. No telemetry.
But the interesting part isn’t the product.
It’s how it was built.
The Background
I’m not a software engineer.
My background is maintenance (military). I run small shop workflows and constantly ran into the same problem:
Once a shop grows beyond spreadsheets, the options become:
SaaS tools that rent your own data back to you
ERPs built for companies doing $20M+
Frankenstein spreadsheets that slowly rot
None of that felt right.
So I decided to try building something myself.
The Constraint
I didn’t want to spend years learning to code before shipping something useful.
Instead I experimented with a different approach:
Treat LLMs like junior developers.
Not magic.
Not autopilot.
Just fast typists that know a lot of patterns.
But they needed discipline.
The Loop
The entire project ran on one loop:
Define the next change
Update a Source of Truth document
Ask an LLM to implement the change
Run a smoke test
Commit
Repeat
Over and over.
Hundreds of iterations.
The important rule was:
The model was not allowed to write code until the Source of Truth was updated first.
That sounds bureaucratic but it solved the biggest AI coding problem:
drift.
Without a canonical spec, every session becomes a different project.
The “Source of Truth” Trick
Most AI coding projects fail because the model slowly forgets what the system actually is.
So I created a living document describing:
entities
endpoints
DB structures
flows
naming conventions
Before any code change, the model had to update the spec first.
Then the implementation followed.
It forced every session to re-read the system before touching it.
The Other Hard Rule
Every change had to pass a smoke test.
The smoke test did things like:
start the app
hit core endpoints
verify database behavior
ensure key flows still worked
If smoke failed, the iteration didn’t exist.
This turned out to be crucial.
Because LLMs will happily generate code that looks right but breaks something subtle.
Smoke tests made regressions visible immediately.
The Stack (Nothing Exotic)
BUS Core is intentionally boring:
Python backend
SQLite database
local-first file structure
browser UI hitting a local API
The goal wasn’t technical novelty.
The goal was operational reliability for small shops.
What BUS Core Actually Does
Today it handles:
Items and vendors
Manufacturing recipes
Production runs
Inventory movements
Cost tracking
Shop journals
Local analytics events
It’s basically the operational layer between:
raw materials
finished products
sales channels
For a one-to-five person shop.
Why Local-First Matters
Most small manufacturers don’t need cloud infrastructure.
They need something that:
starts instantly
works offline
doesn’t charge per user
doesn’t lock their data away
Local-first software gives them that.
The cloud can still exist around it — backups, integrations, automation — but the core system shouldn’t disappear if a subscription lapses.
Cost to Build
Total direct cost:
Two months of:
ChatGPT Pro
Grok Pro
That’s it.
No bootcamp.
No courses.
No hiring developers.
Just time spent iterating.
What Surprised Me
Three things stood out.
1. LLMs work best when constrained
Treat them like a prediction engine, not a teammate.
Clear scope → good results.
Vague scope → hallucinated architecture.
2. Most friction in software development is process
When the loop is tight, progress compounds quickly.
3. The real product became the method
The Source-of-Truth + smoke-test loop turned out to be more valuable than any individual feature.
Current Status
BUS Core v1.0 is now public.
https://buscore.ca/
GitHub:
https://github.com/True-Good-Craft/TGC-BUS-Core
Right now I’m mostly looking for feedback from people running:
print farms
laser shops
small manufacturing setups
Etsy-scale operations
Because those environments tend to hit operational chaos first.
A Question for Indie Hackers
If you’ve run a physical product business:
What breaks first operationally?
Inventory accuracy?
Costing?
Purchasing?
Production scheduling?
I’m curious what the real pain points are beyond my own experience.
Thanks for reading.
Happy to answer any questions about the build process or the local-first approach.
If anyone wants I can also write up the exact Source-of-Truth prompt system I used. It ended up being the key to making LLM coding stable.