BUS Core
Inventory + manufacturing ledger with invariant enforcement.
I’m building BUS Core, a local-first business operations tool for small shops, makers, repair shops, laser/3D print businesses, and other people who still end up running real work out of spreadsheets.
The original problem was simple:
I was tired of tracking materials, product costs, inventory movement, jobs, notes, and business records across memory, spreadsheets, notebooks, and whatever system happened to be nearby.
So I started building the tool I wanted: something small shops can run locally, without becoming dependent on another SaaS dashboard.
Today I shipped v1.3.0, and the main new feature is a local Invoice Truth MVP.
It now supports:
draft invoices
invoice lines
issuing invoices
browser print / save-to-PDF
marking invoices paid
void rules
job-to-invoice flow
invoice-linked finance records
The key boundary: this is not cloud billing. No payment processor. No customer portal. No telemetry. No forced account system. The invoice records live inside the local app.
I also added selectable UI themes, but the real milestone is invoices. This moves BUS Core closer to being a practical local system of record for small operators, not just an inventory/manufacturing tracker.
The project is still early, rough in places, and very much being shaped by feedback from real shop workflows.
Link:
https://buscore.ca/?src=indiehackers_v130
I’d be interested in feedback from anyone who has built, run, or sold into small business operations software:
Is local-first still a meaningful differentiator for this kind of tool?
Would tiny shops actually care about owning invoice/job/inventory records locally?
What would you expect before something like this could become paid?
Should the first paid path be support/setup, hosted Pro features, or workflow customization?
I’m trying to avoid building “ERP cosplay” and stay focused on the boring operational pain that actually costs small shops time and money.
I’ve been digging into a pattern I keep seeing in small manufacturing shops.
They don’t go from spreadsheets to ERP.
They get stuck in between.
What actually happens is pretty consistent:
spreadsheets stop matching reality
inventory starts drifting
job tracking gets fuzzy
people stop trusting the system
but ERP still feels too heavy or wrong for the stage
So you end up with:
ERP (or some core system)
spreadsheets acting as a patch layer
and human memory filling the gaps
Which means there’s no real source of truth.
I’m starting to think this isn’t just “bad tooling,” but an actual operational stage that a lot of small shops hit.
I wrote up a breakdown of that middle here:
https://buscore.ca/blog/the-awkward-middle-between-spreadsheets-and-erp/
Curious if others have run into this.
What actually broke first for you?
I think a lot of “AI-built app” talk collapses because people are really talking about one of two bad extremes:
prompt-gambling until something vaguely works
rejecting the whole thing because most of the output is unstable junk
What worked for me was neither.
I’ve been building BUS Core, a local-first ERP / workshop OS for small makers and micro-shops. Think: the point where a spreadsheet used to be enough, but now inventory, receiving, manufacturing runs, and costing start drifting apart.
The useful part is not “I used AI.”
The useful part is the control system I had to build around it.
What actually worked
I treated the LLM like a junior dev, not an oracle.
That meant a few hard rules:
Source of Truth first
The model was not allowed to just spit out code. It had to update the living SoT first so naming, structure, and intent stayed coherent.Smoke test over feelings
If the app booted, hit the endpoints, and basic flows stayed green, the iteration lived. If smoke was red, nothing else mattered.Small passes, constantly
No giant rewrites. No “perfect architecture.” Just additive changes that survived the next pass.Code is fact
If the code and docs disagreed, code won. Then the SoT got fixed.
That sounds obvious in hindsight, but it is not how most people use these tools.
Most AI-assisted projects fail from drift.
Not because the models are useless.
Because the process is loose.
What I think people miss
The model is not the intelligence.
The human is.
The model is the typing pool with a giant library behind it. Good when constrained. Bad when left to improvise architecture while everyone pretends it’s magic.
That shift mattered a lot.
Once I stopped asking for brilliance and started demanding obedience to a real process, the whole thing got more reliable.
What I’m building toward
BUS Core is aimed at shops that are too real for toy tools and too small to want enterprise ERP baggage.
The thesis is simple:
local-first
boring on purpose
useful before pretty
no rent-seeking cloud dependency
honest operator workflows
What I’m seeing now
The early traction is still small, but it’s real enough to respect:
people are finding it
some are downloading it
update checks are happening
the quiet signal is stronger than the social signal
That actually fits the product.
Nobody gets excited to publicly gush about shop software.
They just test it if it might stop their stock from lying to them.
My current takeaway
AI didn’t remove the need for process.
It made process more important.
If you want these tools to build something real, the question is not “which model is best?”
It’s:
What rails do you force it to stay inside?
For me, the rails were:
Source of Truth
smoke tests
small iterations
code as ground truth
no hidden assumptions
That’s the part I think is portable to other products, not just BUS Core.
If you’ve built with AI and managed to avoid the usual spaghetti explosion, I’m curious what your equivalent rails were.
-
1
I do consistently see people with the same issues trying to utilise these methods. How have you made it work?
Shipped BUS Core 1.0.3 today.
BUS Core is a local-first manufacturing / workshop system I’m building for makers and small shops that are too real for spreadsheets, but don’t want to jump straight into expensive SaaS ERP.
This release was less about flashy new features and more about making the product sturdier and better to live in:
hardening
visual cleanup
improving day-to-day usability
continuing to tighten the overall surface
What I’m finding is that these “less sexy” releases matter more than the big splashy ones.
If the app looks cleaner, behaves more predictably, and feels more trustworthy, that does more for adoption than adding one more shiny feature.
One unusual part of the build:
I’m using a Source-of-Truth-first workflow with LLMs. The model does not get to invent the system from vibes — the design/state has to be written down first, then changes get validated against that. That has been a huge part of keeping the project coherent as it grows. # BUS Core – Method Process So… # BUS Core – Method Process So…
Current question:
for those of you selling software into small operations, what got you the first serious users:
content, communities, direct outreach, or narrow niche demos?
Yesterday I shipped v1.0 of BUS Core.
It’s a local-first ERP/workshop OS for very small manufacturing shops: inventory, vendors, runs, costing, journals, that kind of thing.
The product matters, but the more useful part for other builders is probably what I learned while building it.
I’m not a traditional software engineer, so a lot of this was learned the hard way.
1. “Clever scripts” are usually a trap
I started by trying to glue GPT prompts and scripts together to manage the problem.
That worked right up until it didn’t.
At some point the scripts became convoluted enough that I no longer trusted them as a foundation. That was the moment I stopped pretending I was building a shortcut and started building a real app instead.
2. AI without a Source of Truth becomes a loose hose
The biggest failure mode wasn’t bad code. It was drift.
One session would invent a structure. Another would rename something. Another would partially rewrite a flow and leave dead assumptions behind.
The fix was a living Source of Truth document.
Not a vision doc. Not a wishlist. A mirror of what the system actually is.
3. Update the spec before the code
This was probably the highest-leverage rule in the whole project:
the model was not allowed to output code until the SoT was updated first.
That sounds bureaucratic, but it solved a real problem: it forced the model to reread the system before touching it. It massively reduced hallucinated structure and naming drift.
4. Smoke tests beat confidence
I stopped trusting “this looks right.”
Every change had to survive smoke: app boots, endpoints respond, persistence works, core flow still runs.
That sounds obvious, but with AI-assisted development it matters even more. Models are very good at producing code that feels plausible. Smoke is what tells you whether it’s real.
5. Treat LLMs like junior devs, not architects
The most useful mental model I found was:
LLMs are not the intelligence. They’re the typing pool attached to a giant library.
They are prediction engines. They do much better under tight constraints than open-ended vibes.
Once I stopped treating them like wise collaborators and started treating them like fast executors that need rails, the results got a lot better.
6. Additive iterations beat heroic rewrites
Most of the progress came from boring layered passes, not giant redesigns.
Small change. Update truth. Run smoke. Commit. Repeat.
That loop is not glamorous, but it compounds. And more importantly, each pass stays survivable by the next one.
7. Distribution works better after the product is visually honest
One lesson I learned late enough to matter:
Don’t market abstractions.
A decent home UI, honest screenshots, a short working demo, and one clear download button did more for credibility than trying to talk people into the idea. Concrete product beats theory.
That also changed how I think about launch. Distribution is part of the system, but it should follow working flows, not replace them.
None of this is “secret sauce.”
It’s mostly process discipline:
one living truth source
no hidden assumptions
smoke over feelings
small iterations
AI under constraint
That’s what got me to v1.0.
Curious how other people here keep AI-assisted projects coherent over long stretches.
What ended up being your real anti-drift mechanism?
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.
-
1
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.
I just launched BUS Core — a deterministic microkernel ledger for inventory + manufacturing in small shops.
Core philosophy: no guessing. Explicit authority boundaries, invariant enforcement, fail-fast behavior. If the data can’t be trusted, nothing else matters.
I’m looking for sharp real-world input: what’s the single most painful inventory/manufacturing workflow you deal with today? (receiving, adjustments, BOMs, partial builds, scrap, costing, etc.)
Comment