Custom manufacturing software development, built beside the ERP you keep
Custom manufacturing software development means building the piece the ERP does not have, against data the plant already produces. A module reads the exports, applies a rule a person can read, and stops at someone who approves it. This page walks through what that looks like at a manufacturer and at a machine shop, beside the ERP each one keeps.
Lire cette page en français : logiciel sur mesure
What custom manufacturing software development means
A plant runs a packaged ERP and a set of methods the ERP was never shaped around. Custom development covers one of those methods. A module sits beside the ERP, reads the plant's own records, and does one job the way the shop already does it. AI for manufacturing work covers six functions: quoting, costing, scheduling, order entry, purchasing and forecasting. Each one is a separate build.
Top Shops, the top fifth of North American machining operations in the industry's annual survey, turns a quote around in a day. The same group books 19 percent more of what it quotes (Modern Machine Shop, Top Shops 2025). Across manufacturers and distributors with 100 or more staff, 71 percent say a quote takes at least a day (2025 Built to Sell Report, 200 respondents). On-time delivery among metal fabricators averages 84 percent, against better than 90 percent in the top quartile (Fabricators and Manufacturers Association, cited by Infor).
When a module is the right unit
A module covers one function at one desk, under a rule the person at that desk can read. That scope is what makes it checkable by the person doing the job today. A packaged tool holds the general case, and a shop that prices from its own history needs its method written down as a rule.
What a manufacturing software development company leaves in place
The ERP stays the system of record. The module reads its exports, applies the rule, and writes drafts back into it. A buyer is hiring someone to build around that system and leave it in place. When the ERP is upgraded, the module reads the same exports from the new version, so the connection gets re-pointed.
What the module reads before it writes anything
Underneath every module is a data warehouse built from the systems the plant already runs. The ERP exports go in. So do the mailbox, the drawing vault, the shared drive and the spreadsheets one person maintains on a laptop. The warehouse reconciles them, so a part number means the same thing in every source. Every value keeps a line back to the record it came from. A system with no export file is read through its API instead, and the warehouse holds the rows the same way either side. An API connection sets how often the rows arrive.
Without that line back, the desk cannot audit a derived cost when a customer challenges a price.
The same part can carry three costs depending on which system you open. The ERP holds a standard set years earlier. A spreadsheet holds the estimator's working figure. The last purchase order holds what the raw material cost that month. The warehouse shows all three with the source on each, and the rule decides which one the cost uses.
Reconciling against the shop's own arithmetic
Nobody trusts a derived number until it reproduces figures the plant already has. On the costing build below, the engine reproduces the client's own cached arithmetic exactly before it suggests anything. The code grammar that reads the shop's part numbering names every code it cannot parse, so nobody rounds it away.
A refusal instead of a zero
When the warehouse cannot answer, the module says so and names what is missing. A silent zero on a cost line is worse than a blank, because it prices the job and nobody notices. A named refusal sends the question back to the person who can answer it.
The rule that produces the number
A module earns its place when it can be read as arithmetic. Cost per part is written once, as a recipe applied to every line:
- Material at the price the shop actually paid, read from recent purchase lines rather than a list price.
- Time from the shop's own records, per job, at the load the controller uses.
- The ERP's reference cost carried alongside the result and labelled, so the desk reads both figures on the same line.
Both figures stay on screen, and a gap between them tells the desk where the ERP and the recipe disagree. This is the recipe the costing software for manufacturing module is built on.
Take one line of the recipe, the raw material on a machined part. The module reads the bar stock the routing calls for and takes the most recent purchased price for that code. It writes the basis on the line, so the desk sees the figure and the purchase behind it. With no recent purchase, the line refuses.
One method per client
The rule is written once and applied to every line. Two estimators pricing the same part land on the same number. A price that departs from the rule reads as a disagreement rather than a preference. The desk can still override the figure, and the override is recorded with the reason typed in.
Name the system it would sit beside
Tell us which system holds the numbers today and what the desk does by hand around it. One or two sentences is enough.
Start a conversationThe approval step
Nothing commits on its own. The module writes a draft estimate into the accounting system and a draft reply into the mailbox, and stops there. A named person approves every quote, message and write-back before it leaves the building.
The shop owns the relationship and the number, so the send belongs to a person at the shop. An unapproved send is what ends a deployment.
Two builds, described
Both run on real data inside real companies. Neither is named, and each carries a line saying what has not happened yet.
A manufacturer: costing and quoting
The plant runs an on-premise ERP that exports its tables cleanly, and its reporting does not answer cost per part. The build reads the ERP’s CSV exports into raw tables, and those tables are the warehouse the costing module sits on. A source registry records two things about every table on separate axes: how old the values are, and how far they are trusted. A fresh value the shop does not trust needs a different answer from an old value it does.
Every term in the cost carries its basis, so a line reads back to the export and the row it came from. When a term has no basis, the engine refuses the line.
The build runs on the client's own exports. Several price families still refuse, because the records behind them have not been supplied yet.
A machine shop: from the mailbox to a draft quote
A request arrives as an email with drawings attached, which is how most of them arrive. The module pulls dimensions off the title block and prices the metal off recent invoices. It anchors the suggested price on comparable parts the shop has already quoted. The CAD model opens in the browser, so nobody launches CAD to spin a part. The module writes the estimate and the reply as drafts, and stops. That is the shape manufacturing quoting software takes.
The module is deployed and running on real data. The end-to-end run-through with the owner has not happened yet.
Where the build runs and where the data sits
Each client gets one dedicated server in Canada, reached through a tunnel. The identity layer does not change, so access stays governed by the permissions the plant already runs.
Your data stays at rest on that server. Inference runs one of two ways, and you pick. It runs on the same server with an open-weight model, so nothing about a quote leaves the building. Or it runs through a frontier model under a written zero-data-retention control, with the model tier named in the contract. Zero retention is not available for every tier, which is why the tier is written down.
We describe that control and put it in writing. What it means for your own obligations is a conclusion for your counsel.
What to check before you commission a build
Four answers set the size of a build before anyone scopes it. Get them from the people who run the systems.
- Does the ERP export tables, or only print reports. A module reads a file of rows without argument. A printed report has to be parsed back into rows first, and that work lands before the module's own work starts.
- Is time recorded per job, or per day. Per job gives a cost per part the shop can defend to a customer. Per day gives an average, and an average cannot tell a hard part from an easy one.
- Does one person own the answer when two systems disagree. A warehouse forces those disagreements into the open on day one. Without someone who decides, the build stalls at the first contradiction it surfaces.
- Can the data leave the building, and who decides that. The answer sets where the module runs and which model reads it. Settling it early is cheaper than settling it halfway through.
A no on the first two does not stop a build. It moves work to the front, and the scope should say so. An unanswered third or fourth stops one, because nobody can settle a contradiction or say where the data may run.
This page is also en français.