Wicket — an open source ERP, because the software is pricing shops out

A thirty-person machine shop in the United States pays somewhere between twenty and fifty-five thousand dollars a year for the software that keeps track of its own work. Not the machines. Not the material. The paperwork.

I have been building Wicket ↗, an open source ERP for discrete manufacturing, because that number is the wrong number and because nothing open source fills the gap for a shop that has to prove what it made.

It is early. There is no release yet, and this post is an invitation rather than an announcement.

What an ERP actually does

Strip the acronym away and an ERP is the shop's memory. It is the one system that knows what you have, what you promised, what you built, and what it cost.

Concretely, on a day you are actually working:

• A bar of titanium arrives. Somebody records the heat number and the quantity, and from that moment the material has an identity that follows it.
• The bar sits in quarantine until inspection clears it. It cannot be issued until then, and the system is what enforces that rather than a person remembering.
• A work order opens. The bar is issued to it, and the quantity on hand drops by what was taken, not by what somebody typed into a spreadsheet.
• Parts come off the machine as a finished lot with its own number, consuming the bar it came from.
• Eighteen months later a customer calls about serial number 4471. The system answers which bar it came from, which heat, which operator, which gage, and which inspection results, in one query.

That last one is the whole product. Every other feature is support structure for the day somebody asks a question about a part that shipped a year and a half ago.

For a regulated shop — medical devices, aerospace — the answer has to survive an auditor, which means an audit trail nobody can quietly edit and an electronic signature that means something. That is a different requirement from "we wrote it down."

What they cost

Here is the part nobody puts on a pricing page. The figures below come from counted contracts rather than list prices, because most vendors in this space do not publish one.

For a thirty-person medical device contract manufacturer:

• Shop ERP with quality built in — $30k to $60k in year one, then $20k to $45k a year.
• Shop ERP plus a separate quality system — $65k to $95k in year one, then $50k to $60k a year.
• Shop ERP plus Arena for the quality side — $45k to $75k in year one, then $30k to $55k a year.

The figure that research will defend is thirty to seventy-five thousand dollars in year one, settling to twenty to fifty-five thousand a year. Arena's median across thirty counted contracts is $48,683 a year. Greenlight Guru's median is $43,989.

Two costs shops routinely under-budget. The first is escalation: most software contracts in this category contain no cap on annual price increases, so the number you sign is a floor. The second is your own people's time validating the system, which is real labor that no quote includes.

And the middle row is the cruel one. Buying two systems — an ERP for the shop floor and a separate quality system for the paperwork — is the common answer, costs the most, and still leaves gaps at the seam, because the ERP knows a work order was completed and the quality system knows an operator was trained, and neither one knows whether the operator who ran that order was trained on that operation on that date. Somebody maintains a spreadsheet to answer that. That spreadsheet is where compliance goes to die.

Why this matters beyond one shop

Reshoring manufacturing is a stated goal in this country, and there is real money behind it. Far less attention goes to the fact that a small shop's fixed overhead now includes a five-figure annual software bill before it cuts a single chip.

For a shop doing two million a year in revenue, fifty thousand in software is a meaningful share of the margin. It is also a barrier to entry. If you want to open a precision shop and take on regulated work, the compliance software is a real part of the cost of admission, and it is priced for companies several times your size.

That has consequences the public eventually pays for:

• Fewer small suppliers means less competition and higher prices on the things those shops make, including medical devices.
• Small shops that cannot afford the tooling take on less regulated work, so critical supply chains concentrate into fewer, larger firms.
• Every dollar spent on subscription software is a dollar not spent on a machine, an apprentice, or a wage.

None of that is solved by one open source project. But the software layer is the part that has no good reason to cost what it costs, because it is the same problem solved over and over behind a login.

What makes this one different

Three choices, and they are the whole design:

Compliance lives in the foundation, not in a module you buy. The audit trail, the electronic signature, record immutability and lot genealogy are properties of the core. They apply to every part of the system automatically, including parts nobody has written yet. That is the one thing that genuinely cannot be bolted on later, which is why most open source ERPs do not have it and cannot easily add it.

A shop that is not regulated never sees any of it. The same binary runs with the regulated modules switched off. A job shop making motorcycle brackets gets a clean system and never encounters a quality screen it does not need.

It installs next to a database your machine already has. One binary. No container runtime, no database administrator, no hosting bill. You self-host it, and your quality records stay yours — no vendor can hold them hostage during a contract dispute.

There is a fourth choice that matters if you run any kind of automation: every single function has to be reachable through a documented API, and the system has to be legible enough that an AI agent can both extend it and help run it. That is written down as a binding project goal rather than a nice idea, and it is currently unmet and honestly labeled as such.

Where it actually stands

Pre-alpha. There is no release, and I will not pretend otherwise.

What exists is the kernel: the append-only ledger where quantity on hand is calculated from postings rather than stored in a column somebody can edit, the audit trigger, lot and serial tracking, genealogy, minimal production, electronic signatures, controlled documents. There is an HTTP API and a test suite that drives a real order through the system end to end, under both the regulated and the plain profiles.

What does not exist: a user interface worth using, purchasing, sales, scheduling, a bill of materials module, and a migration path off whatever you run today. The roadmap says so in those words.

How to help

The repository is public: github.com/BlinkingSun/wicket-erp ↗

It is AGPL-3.0, contributions under the Developer Certificate of Origin. No contributor license agreement, which means nobody — including me — can take the project proprietary later without every contributor agreeing.

Start with GOALS.md. It is short, it is binding, and its last section is an honest table of what is not built. CONTRIBUTING.md is the rules. TODO.md is the sequenced backlog, and its first stage is deliberately made of small, self-contained work. AGENTS.md is there if you point an AI coding agent at it.

The scarcest thing this project needs is not code. It is people who actually run manufacturing describing one honest workflow. How lots are named on your receiving dock. What "complete" means on a work order in your shop. What your quarantine rule really is when the inspector is out sick. Every abstract layer diagram is worth less than one of those. If you run a shop and you are willing to write down how you actually do something, open an issue. That is a real contribution and it is the one I cannot do alone.

If you do write code: the hard parts are documented, the decisions are written down with their costs, and there is a list of work that explicitly cannot touch anything dangerous while you learn the codebase.

---

This is a long project and I would rather it be a slow correct one than a fast wrong one. If it works, a shop that today writes a fifty thousand dollar check every year writes none, and keeps its own records on its own hardware. That seems worth building.