DEV Community

Jamie W.
Jamie W.

Posted on

When Spreadsheets Stop Working: The Awkward Middle Between Sheets and ERP

Most small manufacturing shops start on spreadsheets because that is the obvious move.

They are fast, flexible, familiar, and free. If you are building a small operation and just trying to keep materials, runs, and costs in one place, a spreadsheet works well enough for a while.

Then the operation gets a little more real.

Not massive. Not enterprise. Just real.

A few more SKUs. A few more materials. More repeat runs. More stock moving in and out. More chances for numbers to drift. That is usually where the spreadsheet stops being a system and starts becoming a pile of assumptions.

What breaks first

The first problem is authority.

A spreadsheet is not authoritative. Anybody can change anything, anytime, and after enough edits the numbers stop feeling solid. You get stock mismatches. Costing formulas that were “good enough” six months ago are now wrong. Batch history gets muddy. Someone adds another tab. Then another. Eventually you are staring at something like:

inventory v4 FINAL USE THIS ONE

That is usually not a sign of operational excellence.

Inventory drift is usually the first hard symptom. The file says one thing, the shelf says another, and now you are making purchasing and production decisions off numbers you do not trust.

Costing follows. Material prices move. Processes change. Waste shows up. The spreadsheet does not really push back when your assumptions get stale. It just keeps producing numbers.

Then production history starts disappearing into overwritten cells, reused tabs, and human memory.

Why ERP is usually the wrong answer

At this point, people often say: “Sounds like you need an ERP.”

Sometimes that is technically true. It is just usually the wrong scale of solution.

Most small shops do not need implementation partners, admin overhead, per-user billing, layered setup, or a months-long rollout just to track stock, runs, and costs. They need a system that can keep reality straight without becoming a project in its own right.

That is the awkward middle.

Not spreadsheets anymore. Not enterprise software either.

Just real operations with real materials, repeatable runs, and actual money on the line.

That gap is what I built for

I have been building BUS Core, a local-first operational system for small manufacturing work.

The point is not to be a giant all-in-one business platform. The point is to handle the part spreadsheets stop handling well:

inventory

repeatable production definitions

actual manufacturing runs

cost tracking from real inputs

clean run history

BUS Core is local-first. It runs on your own machine. Data stays local in SQLite. No cloud dependency, no account required, no subscription stack hanging over it.

The core loop is intentionally simple:

inventory tracks what you actually have

Blueprints define what a run should consume and produce

Manufacturing Runs record what actually happened

the Production Ledger keeps the history

That is it.

Narrow on purpose.

Why I think this matters

There are a lot of small operators living in the gap between “good luck with Sheets” and “go buy enterprise software.”

I think that gap is bigger than most software people admit.

A lot of real businesses are not large enough for heavyweight systems, but they are already too real for loose spreadsheet ops.

That is the problem space I care about.

What I’m trying to learn

For people who have worked with small manufacturing, workshop, maker, or physical-product operations:

What broke first when spreadsheets stopped being enough?

inventory accuracy

costing

batch/run history

purchasing

something else

I’d also be interested in hearing what people tried before moving to something more structured.

Top comments (0)